前回は、表示処理、SQL呼び出しおよび「重要な処理」に伴う脆弱性対策についてまとめた。ここでは、セッション管理の不備、リダイレクト処理、クッキー出力による脆弱性対策についてまとめる。
１ セッション管理の不備
セッションハイジャックの原因と影響
セッションハイジャックとは、第三者がセッションIDを悪用してなりすますことである。セッションハイジャックが行われる原因は、以下の3種類に分類される。
- セッションIDの推測：自作セッション管理機構の脆弱性など
- セッションIDの盗み出し：URL埋め込みのセッションID、クッキーのセキュア属性不備など
- セッションIDの強制：セッションIDの固定化脆弱性
セッションハイジャックが行われた場合、以下の影響があり得る。
- 利用者の重要情報（個人情報、メールなど）の閲覧
- 利用者の持つ権限での操作（送金、物品購入など）
- 利用者のIDによるメール、ブログなどへの投稿、設定の変更など
ここでは、セッションIDを発行する箇所で発生する脆弱性（推測可能なセッションID、URL埋め込みのセッションID、セッションIDの固定化）について説明する。
推測可能なセッションID
概要
推測可能なセッションIDによる脆弱性とは、Webアプリケーションに用いられるセッションIDの生成規則に問題がある場合に発生する。
- 発生箇所：セッションIDを生成している箇所
- 影響箇所：セッション管理を利用しているページすべて。特に秘密情報の表示や重要な処理をするページは影響が大きい
- 影響の種類：なりすまし
- 影響の度合い：大
- 利用者関与の度合い：不要
- 対策の概要：自作のセッション管理機構ではなく、実績のあるWebアプリケーション開発ツールの提供するセッション管理機構を利用する
攻撃手法と影響
推測可能なセッションIDに対する攻撃は、次の3ステップで行われる。
- 対象アプリケーションからセッションIDを集める
- セッションIDの規則性の仮説を立てる
- 推測したセッションIDを対象アプリケーションで試す
- ありがちなセッションID生成方法：ユーザIDやメールアドレス、リモートIPアドレス、日時（UNIXタイムの数値あるいは年月日時分秒の文字列）、乱数
- 推測したセッションIDでなりすましを試行する
- なりすましの影響：重要情報の閲覧、データや文書の投稿・更新・削除などを利用者の権限によりすべて利用できる
脆弱性が生まれる原因
アプリケーション側でセッション管理機構を自作していること。
対策
Webアプリケーション開発ツールが備えるセッション管理機構を利用すること。何らかの事情でどうしてもセッション管理機構を自作しなければならない場合は、暗号論的擬似乱数生成器をもとに、十分な桁数のセッションIDを生成する。
- PHPのセッションIDのランダム性を改善する方法：リモートIPアドレス、現在時刻、乱数の組み合わせにMD5ハッシュ関数を通す
URL埋め込みのセッションID
概要
URL埋め込みのセッションIDによる脆弱性とは、Refererヘッダを経由してセッションIDが外部に漏洩し、なりすましの原因になることである。
- 発生箇所：セッションIDを生成している箇所
- 影響箇所：セッション管理を利用しているページすべて。特に認証を必要とするページで、秘密情報の表示や重要な処理をするページは影響が大きい
- 影響の種類：被害者の権限で「重要な処理」が実行させられる。物品購入、掲示板への書き込み、パスワード変更など
- 影響の度合い：中〜大
- 利用者関与の度合い：必要。リンクのクリック、メール添付のURL閲覧
- 対策の概要：URL埋め込みのセッションIDを禁止する設定あるいはプログラミング
攻撃手法と影響
攻撃手法には、事故として漏れるケースと、意図的な攻撃として脆弱性が狙われるケースがある。影響は、セッションハイジャックで説明した内容と同じ。
- セッションIDがURL埋め込みになる条件：php.iniの設定項目session.use_cookies、session.use_only_cookiesがデフォルト設定の場合など
- RefererによりセッションIDが漏洩する条件：1)URL埋め込みのセッションIDを使える。2)外部サイトへのリンクがある。あるいはリンクを利用者が作成できる
- 攻撃のシナリオ：事故として漏れるケースと、意図的な攻撃として脆弱性が狙われるケースがある。外部から意図的に攻撃を仕掛けることができるのは、利用者がリンクを作成できる場合に限られる（例えばWebメール、掲示板など）
- 事故としてセッションIDが漏洩するケース：外部サイトへのリンククリックなど
脆弱性が生まれる原因
不適切な設定あるいはプログラミングである。意図的なケースと不注意による設定のケースの2つが考えられる。前者の理由としては、クッキー有害論（プライバシーの問題）とNTTドコモのクッキー未対応（現在は対応）がある。
対策
クッキーにセッションIDを保存するよう設定すること。各言語の設定やプログラミングの方法は以下の通り。
- PHP：session.use_cookies = 1、session.use_only_cookies = 1にする
- Java Servlet(J2EE)：デフォルト設定
- ASP.NET：デフォルト設定
セッションIDの固定化
概要
セッションIDの固定化による脆弱性とは、セッションIDを外部から強制する方法（セッションIDの固定化攻撃）のことである。以下の手順で行われる。
- セッションIDを入手する
- 被害者に対して1.で入手したセッションIDを強制する
- 被害者は標的アプリケーションにログインする
- 攻撃者は被害者に強制したセッションIDを使って標的アプリケーションに入る
- 発生箇所：ログイン処理を行う箇所
- 影響箇所：セッション管理を利用しているページすべて。特に認証を必要とするページで、秘密情報の表示や重要な処理をするページは影響が大きい
- 影響の種類：なりすまし
- 影響の度合い：中
- 利用者関与の度合い：大。罠URLの閲覧、本番サイトでの認証
- 対策の概要：ログイン時にセッションIDを変更する
攻撃手法と影響
ログイン後とログイン前のページにおけるセッションIDの固定化攻撃がある。前者は、罠のURLにより表示されたログイン画面からログインすることによって起こり、後者は、認証を必要としないページでセッション変数を利用していることによって生じる。影響は、当該利用者としてできる操作や情報閲覧はすべて可能となる。
- セッションアダプション（Session Adoption）：未知のセッションIDを受け入れるという特性のこと。PHPやASP.NETなどが持つ。セッションの固定化攻撃が少ない手順で可能になる
脆弱性が生まれる原因
セッションIDを外部から強制できる箇所。
対策
認証が成功した際にセッションIDを変更すること。セッションIDをURL埋め込みにしないことや、クッキーモンスター問題のあるブラウザを使わないなどといった対策があるが、現実的には難しいため。PHPでは、session_regenerate_id関数が利用できる。
- セッションIDの変更ができない場合はトークンにより対策する
- ログイン前のセッションIDの固定化攻撃の対策：ログイン前のセッション変数には秘密情報を格納しない、URL埋め込みのセッションIDを使わない、地域型ドメインを使わない
２ リダイレクト処理による脆弱性
Webアプリケーションには、外部から指定したURLにリダイレクトするものがある。例えば、ログインページのパラメータにURLを指定しておき、ログイン成功後にそのURLにリダイレクトするサイトである（Googleなど）。リダイレクト処理によって発生する代表的な脆弱性には、オープンリダイレクタ脆弱性とHTTPヘッダ・インジェクション脆弱性の2つがある。どちらも受動的攻撃につながる脆弱性につながる。
オープンリダイレクタ脆弱性
概要
オープンリダイレクタ脆弱性とは、任意のドメインにリダイレクトできる機能において起こる脆弱性である。利用者が知らないうちに別ドメインに遷移する場合、フィッシングという詐欺に悪用される可能性がある。フィッシング（phishing）とは、著名なWebサイトなどを偽装したサイトに利用者を誘導して、個人情報などを入力させる手口である。
- 発生箇所：外部から指定したURLにリダイレクト可能な箇所
- 影響箇所：Webアプリケーションの特定のページが影響を受けるわけではなく、フィッシング手法により重要情報を盗まれることで、Webアプリケーションの利用者が被害を受ける
- 影響の種類：フィッシングサイトに誘導され重要情報を入力させられる。デバイスドライバやパッチと称してマルウェアを配布される
- 影響の度合い：中〜大
- 利用者関与の度合い：大。リンクのクリックおよび情報の入力
- 対策の概要：リダイレクト先を固定にする。あらかじめ許可されたドメインにのみリダイレクトするよう制限する
攻撃手法と影響
罠のサイトに遷移するように細工したURLを利用者に実行させ、 IDやパスワードを入力してログインするときにデータを収集する。影響は、そのときに盗まれた情報から発生することすべて。
脆弱性が生まれる原因
以下の2つの条件が両方当てはまる場合に発生する。
- リダイレクト先のURLを外部から指定できる
- リダイレクト先のドメインのチェックがない
オープンリダイレクタが差し支えない場合は、もともと外部のドメインに遷移する仕様であることと、利用者にとって外部ドメインに遷移することが自明であるときには、脆弱性ではない（バナー広告など）。
対策
以下の3つのいずれかを実施することである。
- リダイレクト先のURLを固定にする
- リダイレクト先のURLを直接指定せず番号指定にする（ページ番号指定）
- リダイレクト先のドメインをチェックする
HTTPヘッダ・インジェクション
概要
HTTPヘッダ・インジェクション脆弱性とは、リダイレクト処理やクッキー出力など、外部からのパラメータをもとにHTTPレスポンスヘッダを出力する際に発生する脆弱性である。レスポンスヘッダを出力する際のパラメータ中に改行を挿入する攻撃によって、被害者のブラウザ上で任意のレスポンスヘッダの追加かレスポンスボディの偽造のどちらか、あるいは両方が引き起こされる。
- 発生箇所：リダイレクトやクッキー生成など、外部から指定したパラメータに基づいてHTTPレスポンスヘッダを出力している箇所
- 影響箇所：直接的には脆弱性のあるページが影響を受けるが、任意のJavaScript実行によってなりすましされ、最終的にはアプリケーションのすべてのページが影響を受ける
- 影響の種類：なりすまし、偽ページの表示、キャッシュ汚染
- 影響の度合い：中〜大
- 利用者関与の度合い：必要。罠ページの閲覧、メール添付のURLの閲覧など
- 対策の概要：外部からのパラメータをHTTPレスポンスヘッダとして出力しない。リダイレクトやクッキー生成の専用ライブラリあるいはAPIを使用し、パラメータ中の改行コードをチェックする
攻撃手法と影響
- 外部ドメインへのリダイレクト：パラメータに改行を挿入することにより、新たなHTTPレスポンスヘッダを追加する（HTTPヘッダ・インジェクション攻撃）
- 任意のクッキー生成
- 偽画面の表示：任意のJavaScript実行によるXSSと同様の被害にもつながる
脆弱性が生まれる原因
リダイレクト先URLやクッキー値として設定されるパラメータ中に改行を挿入した場合、改行がそのままレスポンスとして出力されること。HTTPレスポンスヘッダはテキスト形式で1行に1つのヘッダが定義できる。このヘッダとヘッダが改行で区切られる性質を悪用する。
対策
- 外部からのパラメータをHTTPレスポンスヘッダとして出力しない：リダイレクト先をURLとして直接指定するのではなく、固定にするか番号などで指定する。Webアプリケーション開発ツールの提供するセッション変数を使ってURLを受け渡す
- リダイレクトやクッキー生成を専用APIにまかせ、ヘッダ生成するパラメータの改行文字をチェックする：URL中の改行はエラーにする。クッキー値の改行はパーセントエンコードする
３ クッキー出力による脆弱性
クッキーの不適切な利用
- クッキーに保存すべきでない情報：書き換えられると困る情報（例えばユーザIDや権限情報など）
- クッキーとセッション変数の比較：クッキーで実現できてセッション変数で実現できない項目は、情報の寿命の制御と異なるサーバーとの情報共有のみ。そのため、この2点以外はセッション変数を利用すべき
クッキーのセキュア属性不備
概要
セキュア（Secure）属性とは、SSLの場合のみクッキーを送信するもので、これを指定したクッキーはHTTPSの場合のみブラウザからサーバーに送信される。しかし、アプリケーションがHTTPS通信を利用していても、セキュア属性のついていないクッキーは平文で送信される場合があり、盗聴される可能性がある。
- 発生箇所：セッションIDを含めてクッキーを発行している箇所すべて
- 影響箇所：HTTPS通信を利用し、かつ認証のあるページすべて
- 影響の種類：なりすまし
- 影響の度合い：中
- 利用者関与の度合い：HTTPSのみのサイトの場合は必要（リンクのクリックなど）。HTTPとHTTPS混在のサイトでは不要
- 対策の概要：クッキーにセキュア属性をつけるか、セッションIDとは別にセキュア属性つきのクッキーとしてトークンを発行し、ページごとにトークンを確認する
攻撃手法と影響
1)罠を用意。2)罠を閲覧。3)HTMLが返る。4)リクエストを発行。5)HTTPリクエスト中のクッキーを盗聴という経路をたどる。
- パケットキャプチャ手法に関する注意：プロキシ経由で通信するか否かで観測条件が変わる
脆弱性が生まれる原因
セキュア属性をつけないこと。その原因は、開発者がセキュア属性について知らない、セキュア属性をつけるとアプリケーションが動かなくなる、の2つがある。後者の例は、ショッピングサイトである。多くのショッピングサイトではHTTPとHTTPSの両方を使っているため、セッションIDを保持するクッキーにセキュア属性を設定することが困難である。その際はトークンを用いた対策が有効である（後述）。
対策
- セッションIDのクッキーにセキュア属性をつける：PHPの場合、php.iniで「session.cookie_secure = On」という設定をする
- トークンを用いた対策：トークンを保持するクッキーにセキュア属性をつけることによって、HTTPのページとHTTPSのページでセッションを共有しつつ、仮にセッションIDを盗聴された場合でもHTTPSのページはセッションハイジャックを防止できる
- トークンにより安全性が確保できる理由：トークンがサーバーとブラウザの双方向で確実に暗号化され、HTTPSのページを閲覧するには第三者の知り得ないトークンが必要だから
セキュア属性以外の属性値に関する注意
- Domain属性：デフォルト状態が最も安全
- Path属性：デフォルト状態（path=/）でよい
- Expires属性：通常つけない
- HttpOnly属性：通常つける（JavaScriptから参照できなくなる）
最後に
セッション管理不備の対策は、セッション管理機構を自作せずWebアプリケーション開発ツールのものを使う、クッキーにセッションIDを保存する、認証成功時にセッションIDを変更する、認証前にはセッション変数に秘密情報を格納しないことである。リダイレクト処理による脆弱性対策は、できるだけ専用のAPI（ライブラリ関数）を使用する、リダイレクト先は固定にするか、外部から指定するリダイレクト先のURLの文字種とドメイン名をチェックすることである。クッキー出力による脆弱性対策は、原則としてクッキーはセッションIDのみに用いること、HTTPS通信を用いるアプリケーションのクッキーにはセキュア属性を指定することが重要である。
次回は、メール送信、ファイルアクセス、OSコマンド呼び出しの際に発生する脆弱性対策についてまとめる。
 |
