Study Blog

学習のアウトプットや感じた事を発信していきます

セッション管理の不備

書籍を読んで

www.amazon.co.jp

こちらの書籍を読んでWebアプリケーションを作る際に重要な要点を自分用としてアウトプットします。

 

セッション管理の不備

Webアプリケーションでは、認証結果など現在の状態を記憶する手段として、セッション管理機構が用いられている

現在主流のセッション管理機構は、クッキーなどのセッションIDという識別子を記憶させ、このセッションIDをキーとしてサーバー側で情報を記憶する方法がとられている

セッション管理そのものや、その使い方に起因する脆弱性の種類を見ていきましょう

 

セッションハイジャック

概要

ある利用者のセッションIDが第三者に渡り、そのセッションIDを悪用して成りすますことをセッションハイジャックと呼ぶ

三者がセッションIDを知る手段

  • セッションIDの推測
  • セッションIDの盗み出し
  • セッションIDの強制

セッションIDの推測

  • セッションIDの生成方法が不適切な場合に推測されやすくなる
    • 連番になっているセッションID
    • 日時やユーザIDを元にして生成しているセッションID

セッションIDの盗み出し

  • クッキーの生成の際の属性の不備により漏洩する
  • ネットワーク的にセッションIDが盗聴される
  • XSSなどアプリケーションの脆弱性により漏洩する
  • PHPやブラウザなどプラットフォームの脆弱性により漏洩する
  • セッションIDをURLに保持している場合はRefererヘッダから漏洩する
セッションIDの盗み出しに悪用可能なアプリケーション脆弱性の例
  • クロスサイト・スクリプティング
  • HTTPヘッダ・インジェクション
  • URLに埋め込まれたセッションID

セッションIDの強制

セッションIDを盗み出す代わりに、セッションIDを利用者のブラウザに設定することができれば、攻撃者は利用者のセッションIDを「知っている」状態になり、セッションハイジャックが可能になる

--> セッションIDの固定化攻撃 と呼ばれる

セッションIDを発行する箇所で発生する脆弱性
  • 推測可能なセッションID
  • URL埋め込みのセッションID
  • セッションIDの固定化
セッションハイジャックの影響

成りすましが行われる

  • 利用者の重要情報の閲覧
  • 利用者の持つ権限での操作
  • 利用者のIDによるメール、ブログなどへの投稿、設定の変更など

 

推測可能なセッションID

概要

推測可能なセッションIDによる脆弱性を作り込まないためには、セッション管理機構を自作せず、実績のある言語や見るミドルウェア(PHP, Java/J2EE, ASP.NETなど)が提供するセッション管理機構を使用すること

攻撃手法と影響

推測可能なセッションIDに対する攻撃は、次の3ステップで行わる

  • 対象アプリケーションからセッションIDを集める
  • セッションIDの規則性の仮説を立てる
  • 推測したセッションIDを対象アプリケーションで試す
ありがちなセッションID生成方法
  • ユーザIDやメールアドレス
  • リモートIPアドレス
  • 日時
  • 乱数

ユーザIDや日時は外部から推測可能な元データなので、脆弱性の原因になる

推測可能なセッションIDに対する攻撃
  1. 推測可能な情報を元にセッションIDが生成されていないか仮説を立てる
  2. 収集したセッションIDを「あちがちなセッションID生成方法」のモデルに当てはめて、仮説と矛盾がないか検証することを繰り返す
  3. 推測で得たセッションIDをターゲットのアプリケーションで試す
  4. 攻撃が成功すればセッションが有効な状態になるので、攻撃が成功したと判別できる
  5. 成りすましに成功した状態で、利用者権限で可能なありとあらゆる事が可能になる(重要情報の閲覧や送金からデータや文書の投稿、削除など)

※ただし、セッションハイジャックではパスワードまでは分からないため、パスワードの再入力が必要なページについては悪用出来ない

このため、重要な処理の前にパスワードを再入力を要求すると、セッションハイジャックに対する保険的な対策になる

脆弱性が生まれる原因

推測可能な情報を元にセッションIDを生成していること

すなわち、アプリケーション側でセッション管理機構を自作していること

  • 主要なWebアプリケーション開発ツールはセッション管理機構を備えている
  • 安全なセッションIDを生成プログラムを開発することは技術的難易度が高い

上記の2点から、わざわざセッションIDの生成プログラムを開発する意味がなく、通常の用途であればWebアプリケーション開発ツールの提供するセッション管理機構を利用するべきである

対策

もっとも現実的で効果的な対策は、Webアプリケーション開発ツールが備えるセッション管理機構を利用すること

※自作しなくてはいけない場合は暗号論的疑似乱数生成器を元に、十分な桁数のセッションIDを生成すること

 

URL埋め込みのセッションID

概要

セッションIDをクッキーに保存せず、URLに埋め込ませる場合がある

PHP, Javaなどは、セッションIDをURLをに埋め込む機能をサポートしている

セッションIDををURLに埋め込んでいると、Refererヘッダを経由してセッションIDが外部に漏洩し、成りすましの原因になる場合がある

URL埋め込みのセッションIDによる成りすましへの対策は、URL埋め込みのセッションIDを禁止する設定あるいはプログラミングをすること

攻撃手法と影響

セッションIDがURL埋め込みになる条件

PHPの場合

php.iniのセッションID設定を変更し、自動埋め込みをOffにするなどの対処が必要

RefererによりセッションIDが漏洩する条件
  • URL埋め込みのセッションIDを使える
  • 外部サイトへのリンクがある。あるいはリンクを利用者が作成できる

攻撃のシナリオ

RefererからのセッションIDの漏洩

  • 事故として漏れるケース
  • 意図的な攻撃として脆弱性が狙われるケース

外部から意図的に攻撃が仕掛けることが出来るのは、利用者がリンクを作成できる場合に限られる

Webメール掲示板、ブログなどがこの条件に該当する

Webメールからの攻撃の場合
  1. 攻撃者は、ターゲットアプリケーションの利用者に対して、URLつきのメールを送信する
    1. メールの文面には「私のホームページを見てください」などの言葉
  2. 上記のメールで攻撃者のサイトに誘導する
  3. メールに添付してあるリンク付きURLから攻撃者のサイトを閲覧する
  4. WebメールのうRLに埋め込まれていたセッションIDが、攻撃者のサイトにRefererとして漏洩する
  5. 攻撃者は、受け取ったRefererを元に、利用者への成りすましが可能になる
攻撃ではなく事故としてセッションIDが漏洩するケース

利用者がセッションID付きのURLを自らSNSのなどに投稿したり、なんらかのきっかけでセッションID付きのURLが検索サイトに登録され、情報漏洩事故となった事例も複数報告されている

影響

URL埋め込みのセッションIDがRefererから漏洩した場合の影響は「セッションハイジャックの影響」で説明した内容と同じ

脆弱性が生まれる原因

セッションIDがURLに埋め込まれる直接の原因は、不適切な設定あるいはプログラミングによるもの

不適切な設定に該当するケースは、意図的に設定しているケースと不注意による設定のケース

意図的にセッションIDをURLに埋め込む理由としては

  • 「クッキー有害論」によりクッキーを避けようという機運が一部にあった
  • NTTドコモ社の携帯電話ブラウザがクッキーに対応してなかった為、現在も携帯電話向けWebアプリケーションはURL埋め込みセッションIDが主流

通常はセッションIDをクッキーに保存する方法がもっとも安全なので、クッキーを嫌う結果としてセッションIDをURLIDに埋め込むことは、かえって個人情報の漏洩などにつながりやすい状態である

対策

URL埋め込みのセッションIDを使わない為には、クッキーにセッションIDを保存するよう設定すること

 

セッションIDの固定化

セッションIDを外部から強制する方法があり、セッションIDの固定化攻撃と呼ばれる

セッションIDの固定化攻撃は、以下の手順で行われる

  1. セッションIDを入手する
  2. 被害者に対して①で入手したセッションIDを強制する
  3. 被害者は標的アプリケーションにログインする
  4. 攻撃者は、被害者に強制したセッションIDを使って標的アプリケーションにアクセスする
セッションIDの固定化攻撃による影響
  • 成りすましによる情報漏洩
  • 被害者の権限によるアプリケーション機能の悪用
  • データの投稿・変更・削除など
セッションIDの固定化攻撃への対策

ログイン時にセッションIDを変更すること

上記手順②を防ぐことは難しい為、ログイン後のセッションIDを攻撃者に分からなくする

攻撃手法と影響

セッション固定化攻撃の流れ
  1. 利用者が罠URLをうっかりクリック
  2. ログイン画面が表示される
  3. 利用者がユーザIDを入力し、ログインボタンをクリックする
  4. セッションIDが固定化される
  5. この状態でセッションIDが有効となり、利用者情報はこのセッションに蓄積される
  6. 攻撃者が罠に引っかかった利用者がログインしたタイミングを見計らって、URLにより被害者の個人情報を閲覧する
  7. 閲覧画面 --> 個人情報としてユーザIDが表示される
ログイン前のセッションIDの固定化攻撃

ログイン前のページ(認証を必要としないページ)であっても、セッション変数を使用しているとセッションIDの固定化攻撃が成立する場合がある

  1. 攻撃者が利用者に罠サイトのURLにアクセスさせる
    1. 個人情報などを入力するような誘導ページ
  2. 罠に引っかかった利用者が自分自身の個人情報を入力する
  3. 一方、攻撃者は先のURLページを定期的に監視する
  4. 利用者が個人情報を入力した時点で、攻撃者のブラウザにも個人情報が表示される

この場合は、利用者のログイン状態に成りすまししておらず、利用者の権限を悪用出来るわけではないことから、攻撃による影響は、利用者が入力した情報の漏洩に限定される

セッションアダプション
  • PHPには未知のセッションIDを受け入れるという特性がある
  • この特性はセッションアダプションと呼ばれる
  • PHPASP.NETでも見られる性質
  • 上記以外のTomcatなどではセッションアダプションがないので、勝手に作成したセッションIDは無視される
  • セッションアダプションの有り無しに関わらずセッションIDの固定化攻撃自体は可能だが、セッションアダプションがあるとセッションIDの固定化攻撃が少ない手順で可能になる
クッキーのみにセッションIDを保存するサイトのセッションIDの固定化

URLにセッションIDを保持出来るアプリケーションの方がセッションIDの固定化攻撃が容易なだけで、クッキーにセッションIDを保持している場合でも、セッションIDの固定化が可能になる場合がある

クッキーのセッションIDを外部から設定することは容易ではないが、ブラウザやWebアプリケーションに脆弱性があれば、可能になる

クッキーを第三者が設定できる脆弱性の例

サイト全体がHTTPSで暗号化されている場合でも、平文のHTTPでクッキーを設定すれば、そのクッキーはHTTPSでも有効。すなわち、通信路上に攻撃者が存在する場合、クッキーの改変を防ぐ方法がない。

セッションIDの固定化攻撃による影響

セッションIDをの固定化攻撃が成立すると、攻撃者は罠に引っかかった利用者としてログインしている状態なので、当該利用者として操作や情報閲覧は全て可能になってしまう

脆弱性が生まれる原因

セッションIDの固定化に対する脆弱性が生まれる第一の原因は、

セッションIDを外部から強制できるところにある

以下のを全て実施することが本質的な対策になる

現実的に上記全てを満たすことは不可能

(IEクッキーモンスターバグがあり、Window8.1が残る事など)

このため、セッションIDが外部から強制される事は許容し、セッションIDの固定化攻撃が行われても、セッションハイジャックは防ぐように対策することが一般的である

対策

セッションIDを外部から固定化する方法が多様であり、ブラウザのバグ(脆弱性)が悪用される場合もあるため、Webアプリケーション側でセッションIDの固定化攻撃に対策する方法は

  • 認証後にセッションIDを変更する
セッションIDの変更ができない場合は、トークンにより対策する
  • ログイン時に乱数文字列(トークン)を生成し、クッキーとセッション変数の両方に記憶させる方法であり、各ページの認証確認時にクッキー上のトークンとセッション変数のトークンの値を比較し、同一である場合のみ認証されていると認識する。同一でない場合は認証エラーと処理される。
  • トークンが外部に出力されるタイミングはログイン時のクッキー生成のみなので、トークンは攻撃者にとっては未知の情報であり、知る手段がない為、トークンによりセッションIDの固定化攻撃を防ぐことが出来る
  • トークンには予測困難性(現実的な時間内に予測することが困難であることが保証されていること)が要求されるため、暗号論的疑似乱数生成器を用いて生成すべきである
ログイン前のセッションIDの固定化攻撃の対策
  • ログイン前にセッション変数を使っていると、セッションIDの固定化攻撃に完全に対策することは困難であるため、ログイン前にはセッション管理機構を使わず、hiddenパラメータで値を引き回す事が、現実的で効果的な対策になる
  • ショッピングカート機能のあるECサイトなどで、やむを得ずログイン前にセッション変数を使う場合には、秘密情報をセッション変数にセットするページで毎回セッションIDを変更することで対策となる
    • しかし、セッションIDを変更したレスポンスをブラウザが受信できなかった場合に、セッションが維持できなくなるという副作用がある

 

セッション管理の不備の対策

  • セッション管理機構を自作せず、Webアプリケーション開発ツールのものを使う
  • クッキーにセッションIDを保持する
  • 認証成功時にセッションIDを変更する
  • 認証前にはセッション変数に秘密情報を保存しない

※設計段階から計画的に対策することが推奨される