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

» 2006年08月01日 00時00分公開

[安西真人，三井物産セキュアディレクション株式会社]

前のページへ 1|2|3 　　　　　　

ログイン前とログイン後でセッション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アプリケーションを作成する際の注意点を、検査業務の中で検出されることの多い問題を中心に解説してきた。

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