検索
連載

安全なセッション管理を実現するためにStrutsで作るセキュアWebアプリケーション(4)(3/3 ページ)

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

ログイン前とログイン後でセッションIDが変化しない

 セッション固定攻撃が成立する最後の条件はログイン前とログイン後でセッションIDが変化しないことだ。セッションIDを変化させるためには明示的な実装が必要となるから、意識して実装されていない限り条件が成立する可能性は高いといえるだろう。

 ほかの条件については、独自に機能拡張されたアプリケーションサーバやフレームワークを使用するなど、複雑な対策が必要となるが、最後の条件だけは、容易な実装で対策することが可能である。

対策:

・ログイン成功時にセッションIDを再発行する

 セッションIDを変化させるには、ログインが成功したらセッションIDを再発行させればよい。再発行の時点でセッションIDは攻撃者にとって未知の値となるため、セッション固定攻撃は成功しなくなる。具体的には以下のような実装となる。

/** ログイン処理を実行して成功したらセッションを再発行 */
if (login(userId, password)) {
  request.getSession(true).invalidate();
  HttpSession session = request.getSession(true);
  // sessionにログイン情報をセット
}

・認証Cookieを別途用意して、セッション情報と関連付ける

 ショッピングサイトなどにおいては、ログイン前に選択した商品購入情報をセッション変数に格納し、ログイン後にも継続して使いたいという要件もあるだろう。この場合、ログイン時にセッション情報をクリアすることはできない。

 このような問題は、セッション管理用のCookieのほかに、認証用のCookieを別途用意することで柔軟に解決することが可能である。具体的には、下の実装のように、ログイン成功の段階で認証用のCookieを別途発行し、セッション情報と関連付けるようにすればよい。

/** ログイン処理を実行して成功したら認証Cookieを発行 */
if (login(userId, password)) {
  HttpSession session = request.getSession(true);
  // 充分な強度を持つ認証IDを生成する
  String authId = 認証ID生成処理;
  Cookie authCookie = new Cookie(“Auth”, authId);
  // 認証Cookieをセッションに結びつける
  session.setAttribute(“AuthId”, authId);
  response.addCookie(authCookie);
}

/** 認証状態のチェック処理 */
Cookie[] cookies = request.getCookies();
Cookie authCookie = null;
String authId = null;
for (int i = 0; i < cookies.length; i++) {
   if (cookies[i].getName().equals("Auth")) {
     authCookie = cookies[i];
     authId = authCookie.getValue();
   }
}
HttpSession session = request.getSession(true);
if (authId != null && authId.equals(session.getAttribute("AuthId"))) {
 // 認証チェック成功
} else {
 // 認証チェック失敗
}

 いずれかの対策を取っていれば、セッション固定攻撃が成功することはなくなる。

 攻撃者がセッション固定攻撃のわなをしかける際には、攻撃者が知り得るセッションIDを正規ユーザーに使用させなければならない。WebサイトやWebブラウザにセキュリティホールが存在しない限り、ほかのユーザーのCookie値を操作することはできないが、任意のURLへのリクエストを発行させることは容易である。

 URLによってセッションIDの指定が可能なStrutsでは任意のセッションIDを付加したリクエスト発行のわなを仕掛けられる可能性が高い。問題が起こり得る実装となっている場合、対策することを検討していただきたい。


 以上、4回にわたってStrutsでWebアプリケーションを作成する際の注意点を、検査業務の中で検出されることの多い問題を中心に解説してきた。

 本連載で取り上げた問題以外にも、ロジックの実装手法によって発生し得る問題はまだまだ残されている。「すべてのパラメータは書き換え可能であり、意図しない画面遷移を実行される可能性がある」ということを認識し、細心の注意を払って安全なアプリケーションを開発してもらいたい。

Profile

安西 真人(あんざい まさと)

三井物産セキュアディレクション株式会社
テクニカルサービス事業部 技術グループ Webセキュリティチーム
エンジニア

Webアプリケーションのシステム開発経験を生かし、セキュリティコンサルタントとして主にWebアプリケーションのセキュリティガイドライン策定業務などに従事している。大手保険会社、出版社などへの導入実績を持つ。


Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       

Security & Trust 記事ランキング

  1. 「SMSは認証に使わないで」 米CISA、モバイル通信を保護する8つのベストプラクティスを公開
  2. 経営層の約7割が「セキュリティ対策は十分」一方で6割以上がインシデントを経験、1位の要因は?
  3. Google Cloud、2025年のサイバーセキュリティ予測を発表 AIがサイバー攻撃にもたらす影響とは?
  4. 2025年に押さえるべきセキュリティの重要論点をガートナーが発表 新しいリスク、脅威、環境の変化、法規制などの動きを把握する指標に使える
  5. “ゼロトラスト”とトラスト(信頼性)ゼロを分かつものとは――情報セキュリティ啓発アニメ「こうしす!」監督が中小企業目線で語る
  6. 終わらせましょう。複雑過ぎるKubernetes/クラウドネイティブが生む心理的安全性の低下を――無料でクラウドセキュリティの勘所が分かる130ページの電子書籍
  7. よく聞く「複雑化するサイバー攻撃」は具体的にどう複雑なのか? 一例を医療系企業のランサム事例とともに解説
  8. 3割程度のSaaS事業者が標準的なセキュリティ対策をしていない アシュアードがSaaS事業者を調査
  9. 「このままゼロトラストへ進んでいいの?」と迷う企業やこれから入門する企業も必見、ゼロトラストの本質、始め方/進め方が分かる無料の電子書籍
  10. 増える標的型ランサムウェア被害、現場支援から見えてきた実態と、脆弱性対応が「限界」の理由
ページトップに戻る