参考情報
「1.4 セッション管理の不備」に記載があります。
安全なウェブサイトの作り方：IPA 独立行政法人 情報処理推進機構
産業技術総合研究所 高木浩光： 「CSRF」と「Session Fixation」の諸問題について
どちらの版でも「4.6 セッション管理の不備」に記載があります。
「3.1 HTTPとセッション管理」
私は第1版しか持っていないのでそちらを参照しました。
体系的に学ぶ 安全なWebアプリケーションの作り方
体系的に学ぶ 安全なWebアプリケーションの作り方 第2版
セッション管理の不備とは
セッション管理に不備があるために、セッションIDを悪用して成りすまされてしまう可能性があります。
このような攻撃手法をセッションハイジャックと呼びます。
- セッションハイジャックの分類
- セッションIDの推測
- セッションIDの盗み出し
- セッションIDの強制/固定化
セッションハイジャックの原因となる脆弱性は、アプリケーション、ネットワーク、ミドルウェアと多岐に渡ります。
セッション管理とは
IPA セキュア・プログラミング講座：IPA 独立行政法人 情報処理推進機構
もともとHTTPはステートレスなプロトコルです。
しかし、アプリケーションでは状態を保持したいことがあります(ex. ECサイトのカート、認証結果)。
そこで、セッション管理というステートフルな仕組みが使われるようになりました。
『セキュア・プログラミング講座(Web アプリケーション編)』ブートアップセミナー資
料 ※PDF
P38～
セッション管理とは、HTTPリクエストの送信元クライアントを区別するために、リクエストに「しるし＝セッションID」を含ませることで見分ける仕組みです。
このセッションIDをやり取りする手段として次の3つが用いられます。
1. Cookie
2. POSTのhiddenパラメータ
3. URLパラメータ
対策
対策は「推測」「奪取」「操作」への対抗の3種類に大別できます。
※「推測」「奪取」の分類は[link-6]に記載があります
※推測、奪取された後の被害を抑える意味で「操作」の分類を追加しました
推測への対抗
セッション ID を固定値にしない。
ユーザーIDだけで生成すると、ログインをし直しても同じセッションIDを使うことになります。
この場合、一度セッションIDが盗まれるといつでもセッションハイジャックされることになります。
ログインごとに新しく発行されるようなパラメータを使って生成するようにします。
セッション ID を推測が困難なものにする。
連番やユーザーID、日時など外部から推測可能なものだけで生成すると、脆弱性の原因となります。
乱数も、安全でない(暗号論的疑似乱数生成系でない)場合は、安全な乱数へ変更することで改善できます。
奪取への対抗
セッション ID を URL パラメータに格納しない。
ガラケーではcookieに対応していないブラウザが多かったため、URLパラメータに格納せざるを得なかったらしいです。
確かに、昔保守していたガラケーサイトではURLにセッションIDがついていました。
URLパラメータにセッションIDが含まれる場合、そのURLを公開してしまったり、攻撃者のサイトへのリンクを踏むことでrefererから漏洩する可能性があります。
HTTPS 通信で利用する Cookie には secure 属性を加える。
通信中に読み取られにくくするために、非SSL/TLSのときにはセッションIDをやり取りしないようにするべきです。
secure モードでない通常のクッキーは、SSL/TLS による経路のセキュリティ保護を受けることができない
経路のセキュリティと同時にセキュアなセッション管理を
ログイン成功後に、新しくセッションを開始する。
ログイン前後で同じセッションIDを用いると、セッションIDの固定化攻撃を受ける危険性があります。
ログイン後に新しいセッションIDを発行することで対策ができます。
また、トークンを発行することでも同様の対策ができます。
認証時にトークンを生成し、cookie(クライアント側)とセッション変数(サーバー側)とでそれぞれ保持し、突き合わせることで検証できます。
攻撃されにくいブラウザ、ドメインを使う
ブラウザによっては「クッキーモンスター」と呼ばれる、xxx.co.jpからco.jpドメインのcookieをつくれてしまう問題があり、cookieに書き込まれるセッションIDを上書き(セッションIDの固定化)される可能性があります。
ただ、Windows10では解消されたようです。
IEのクッキーモンスターバグはWindows 10で解消されていた | 徳丸浩の日記
セッション ID を Cookie にセットする場合、有効期限を短くする
Cookieの有効期限が長いと、ブラウザの脆弱性を悪用して盗まれる可能性のある期間が長くなることになります。
そのため適切な期間を設定し、適宜破棄するようにすべきです。
ログイン成功後に、既存のセッション ID とは別に秘密情報を発行し、ページの遷移ごとにその値を確認する。
もしセッションIDを奪取されても、別の秘密情報を検証することでただしいセッションかどうかを判断できます。
クライアント側ではcookieなど、サーバー側ではセッション情報に値を保持することになります。
操作への対抗
操作に再認証を必要とする
セッションハイジャックでは、パスワードを盗むわけではないため、再認証が必要な操作については悪用を防ぐことができます。
すべての操作で再認証を必要にしてしまうと利便性が低下するため、重要な情報の参照や変更時に限るなど適宜対応することになります。
ex.) 以下のようなフローとなっている場合は、影響範囲が広がります。
1. セッションハイジャックでセッションを盗む
2. 再認証なしでメールアドレスを変更する
3. ログイン前の画面からパスワード再設定をする
4. 2で設定したメールにパスワード再設定URLが届く
5. 4のURLからパスワード再設定する
6. セッションハイジャックなしに、ログインできるようになる
感想
そもそもセッション管理のことを分かっていないまま使っていたのだと思いました。