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

概要

セッションが URI に埋め込まれることがある。

PHP,Java,ASP.NET などはサポートしている。

http://example.jp/mail/123?SESSIONID=XXXXXXX

課題点：

Referer ヘッダーにより、サーバーは人々がどこから訪問しに来たかを識別し、分析、ログ、キャッシュの最適化などに利用することができます。

対策：

  • URL 埋め込みセッションそのものを禁止する

攻撃手法と影響

攻撃の流れ：

  • スタートページ（別ページに遷移）

  • 外部リンクが貼られたページ（パラメータに SESSIONID が付与されている）

  • 外部のページ（referer ヘッダから SESSIONID を取得）

    1.URL 埋め込みセッションを使えるするように設定ファイルを変更

    2.外部サイトへのリンクがある or リンクを攻撃者が作成できる（メール、掲示板、ブログ、SNS でやられる）

影響：

セッションハイジャックを同じ

脆弱性が生まれる原因

  • 2000 年前後の「クッキー有害論」が生じたため

    -> アクセス履歴を追跡できるのってプライバシーの観点からどうよ？って問題に

  • ドコモのガラケーのブラウザは過去にクッキー対応していなくその影響

    —>今はクッキーに保存するほうが安全とされている？

対策

セッション ID をクッキーにのみ保存してねとすれば OK

セッション ID の固定化

概要

セッションハイジャックを起こす攻撃の中に、セッション ID を外部から強制するセッション ID の**固定化攻撃（Session Fixiation Attack）**がある。

攻撃の流れ：

  • セッション ID を入手

  • ターゲットに奪ったセッション ID でのアクセスを強制

  • ターゲットが標的のアプリにログイン

  • 攻撃者は強制したセッション ID を使ってターゲットのアプリにログイン

対策：

  • ログイン時にセッション ID を変更

ログイン後のセッション ID 攻撃

  • 罠サイトをクリック
  • SESSIONID=ABCが埋め込まれた URL でログインページに遷移
  • ユーザー名などを入れてそのままログイン
  • 攻撃者がSESSIONID=ABCを使ってログイン

ログイン前のセッション ID 攻撃

  • 罠サイトをクリック
  • SESSIONID=ABCが埋め込まれた URL で個人情報を入力
  • この段階で攻撃者のブラウザにも個人情報が表示

POINT: 認証の必要のないページでセッション変数を使用しているセッション ID 攻撃の可能性がある。

未知のセッション受け入れる「セッションアダプション」

PHP や ASP.NET は道のセッションを受け入れることができるのでSESSIONID=ABCを許容する

セッションアダプションがないミドルウェアで動作するアプリへの攻撃は、 ターゲットアプリケーションを閲覧して、有効なセッション ID を取得してこのセッションを使用する

つまり、セッションアダプションがなくてもログイン前のセッション ID 攻撃は可能

クッキーのみにセッション ID を保存するサイトのセッションの固定化攻撃 ブラウザの脆弱性などを使用するとクッキーの保存されているセッション ID に対しても固定化有効

  • クッキーモンスターバグ
  • クロスサイトスクリプティング
  • HTTP ヘッダ・インジェクション

通信経路上に攻撃者が存在する場合は、OWAP ZAP のようなプロキシツールでクッキーが改変可能 HTTPS でも平文の HTTP でクッキーを設定すればそのクッキーは HTTPS でも有効 -> つまり、クッキーの改変を防ぐ方法はありません！ HTTPS を使っても Cookie の改変は防げないことを実験で試してみた

影響 ログインしてできることすべて

脆弱性が生まれる原因

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

対策

  • セッション ID を URL に埋め込まない
  • クッキーモンスターバグのあるブラウザを使わない
  • クッキーモンスターバグの発生しやすい都道府県型 JP ドメインと地域型 JP ドメイン名を使用しない
  • クロスサイトスクリプト脆弱性をなくす
  • HTTP ヘッダ・インジェクション脆弱性をなくす
  • その他、クッキーを書き換えられる脆弱性をなくす

これを全部対策するのは不可能 ->外部からセッション ID を強制されることは許容して固定化攻撃が行われてもセッションハイジャックを防ぐように対策するのが一般的 認証が成功した際にセッション ID を変更することが有効

ログイン後のセッション ID 固定化攻撃対策

  • 認証後にセッションを変更
  • セッションを変更できない場合はトークンによる対策 -> ログイン時にトークンを生成 クッキー上のトークンとセッション変数のトークンの値を比較して同一である場合のみ認証 OK トークン生成には暗号論的疑似乱数生成器を使用しよう

ログイン前のセッション ID 固定化攻撃対策

  • ログイン前にはセッション管理機構を使わずに hidden パラメータで値を引き回すことが効果的

まとめ

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