体系的に学ぶ 安全なWebアプリケーションの作り方の読書メモ 第2回 セッション管理のまとめ

前回は、かなり大ざっぱなまとめだったので、今回は気になったポイントをまとめてみる。その中でもセッション管理はWebシステムの根幹であるのでまずはそれをまとめてみた。と、いうメモである。まとめなのにまとまっていないというツッコミはご遠慮願いたい。

• セッション管理で大切なこと
• セッション管理機構を自作せずWebアプリケーション開発ツールのものを使う
• セッション情報はIDのみをクッキーに保存、クッキーはセキュア指定が基本
• 認証成功時にセッションIDを変更する
• 認証前にはセッション変数に秘密情報を保持しない→hiddenパラメータを用いる

セッション管理を自作しちゃ駄目な理由

自作する場合、次の要件を満たすようなIDを発行し管理する必要がある。

1. 第三者がセッションIDを推測出来ないこと
• 理由：推測可能な情報（ユーザIDや日時）を元に作成しているとなりすましが簡単（数字をずらす等）
2. 第三者からセッションIDが強制されないこと
• 理由；セッションIDの固定化攻撃を招くため
3. 第三者にセッションIDが漏洩しないこと

以上を満たすものを実装し、テストして検証するぐらいなら開発ツールが提供するものを使った方が楽だし確実。

セッション管理の基本

• セッションとはアプリケーションの状態を覚えておくこと
• セッション管理はセッションIDの管理
• セッション情報そのもの（ユーザ情報など）はサーバで管理する
• クライント側ではIDのみを管理する→Cookieで保存

Cookie保存時の注意点

• Domain属性は原則として設定しない
• 必ずSecure指定を付ける
• 可能ならばHttpOnlyを付ける

URL埋め込みのセッションIDが駄目な理由

• 外部サイトへのリンク埋め込みが可能だと、外部サイトを通じて漏洩する
• Webメール等で、URLリンク付きのメールを受け取り、それを踏むとRefererヘッダからセッションIDが漏洩する
• リンク先が悪意あるサイトだと、そのサイト主にWebメールのセッションIDが漏れる

補足メモ

• 推測不可能なセッションIDの払い出し方法
• 暗号論的擬似乱数（現実的な時間内に乱数値を予測することができないことが理論的に保証されている乱数のこと）生成器を元に作成する。
• 乱数発生器 Linux：/dev/urandom　Windows:Windows Random API

• セッションIDの固定化攻撃方法
• 発生箇所：ログイン処理を行うところ
• 手順
1. 攻撃者がセッションID を入手する
2. 被害者に対して、1 で入手したセッションID を強制する（偽装したサイト経由で被害者をログインさせる）
3. 被害者は標的アプリケーションにログインする
4. 攻撃者は、被害者に強制したセッションIDを使って標的アプリケーションにアクセスする
• 対策
• ログイン成功時に新たなセッションIDを発行する
• トークンを使用する
• ログイン時に乱数文字列（トークン）を生成し、クッキーとセッション変数の両方に記憶させる
• 認証時にトークンが一致しないとエラー

• セキュリティ上重要なCookie属性
• Domain：ブラウザがCookie値を送信するサーバのドメイン
• 異なるドメインに対してはCookieを発行出来ないように制限されている
• 指定しない場合は、Cookieを生成したサーバのみ送信される
• Secure：SSLの場合のみCookieを送信
• Secureがついていない場合は常に送信
• CookieのSSL通信を行うことを保証する
• HttpOnly：JavaScriptからはアクセス不可

• Refererヘッダはいつ付く？
• form要素による送信
• a要素によるリンク
• img要素による画像参照

参考文献

体系的に学ぶ 安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践