SOC Report

Size: px

Start display at page:

Download "SOC Report"

そよみしま
4 years ago
Views:

1 Session Adoption in Session Fixation N T T コミュニケーションズ株式会社 IT マネジメントサービス事業部セキュリティオペレーションセンタ 2010 年 03 月 09 日 Ver. 1.0

2 1. 調査概要 SESSIONID による HTTP セッション管理とは SESSION HIJACK (HTTP セッションに対しての攻撃 ) SESSION FIXATION 攻撃有効なSESSIONIDを収集する有効なSESSIONIDを犠牲者に使わせる SESSION ADOPTION 問題 PHP の SESSION ADOPTION 問題検証環境 PHPのSESSION ADOPTION 問題について検証結果 ( 機能の確認 ) より具体的なPHPのSESSION ADOPTION 問題 SESSION ADOPTION 問題とPLACEFOLDERのUNDEFINED 問題 SESSION MORFING(SESSION MODIFICATION) SESSION SURROGATE (SESSIONサロゲート) SESSION HIJACK の現実的な脅威まとめ {PHP の SESSION FIXATION 対策 (SESSION ADOPTION 対策 )} 検証作業者参考履歴最新版の公開 URL 本レポートに関する問合せ先

3 1. 調査概要現在の Web アプリケーションのほとんどは ID(SessionID と呼ばれる識別子 ) を用いた HTTP セッション管理を行っている通常 SessionID は Web アプリケーション側で決定するがクライアント (Web ブラウザ ) 側で決定した任意の値を SessionID として使える場合がある PHP はその代表例といえるがこのような脆弱性は Session Adoption 問題と呼ばれている Session Adoption 問題は Session Fixation 問題の一部と考えることができるまた Session Adoption 問題がどのような現象であるかの概要程度の記述はインターネット上にも散見されるが実際のセキュリティ上の脅威としてはどの程度であるかといった検証レポートが見つからなかった本文書では Session Adoption 問題がどのように Session Fixation 問題さらには Session Hijack 問題と関係していくのかまた Web アプリケーションでどの程度の脅威となるのかを検討したさらに防御方法特に Web アプリケーションのプログラミング方法についても検討した 2. SessionID による HTTP セッション管理とは現在の一般的な Web アプリケーションでは SessionID と呼ばれる一意でかつ推測困難な値を Web ブラウザ上に保持 ( 大抵はクッキー情報として保持 ) し Web ブラウザから渡される SessionID の値を確認することで HTTP セッションの管理を行っているこの SessionID を他者が利用することができれば他者の HTTP セッションになりすますことができてしまう通常 SessionID は Web アプリケーションによって推測困難な値が作成されるため Web アプリケーションを利用している他者の SessionID を推測することは困難である 3. Session Hijack (HTTP セッションに対しての攻撃 ) Web アプリケーション上の他者の HTTP セッションを乗っ取ることが可能であれば他者として成りすますことが可能になり不正行為者が犠牲者としてふるまったり犠牲者が入力した情報を搾取したりさまざまなセキュリティ侵害行為が可能となるそして "Web アプリケーション上の他者の HTTP セッションを乗っ取ること " とは犠牲者の SessionID に対して攻撃 ( 推測固定化など ) するのとほぼ同義になる Web アプリケーションの HTTP セッション管理機構に対しての攻撃は以下が考えられる 3

4 犠牲者のSessionIDを盗み出す 1 通信の盗聴 ( 通信経路上のルータの掌握 ARP Poisoning 攻撃やリピータハブの盗聴など ) HTTP over SSL に対する MITM 攻撃 ( 主に SSLv2) HTTP over SSL 上のクッキー情報 (SessionID 含 ) を HTTP 通信 ( 平文通信 ) にて盗聴する ( 主にクッキー情報の Secure 属性 ) XSS( クロスサイトスクリプティング ) 攻撃 2 犠牲者の SessionID を推測する Web アプリケーションの SessionID が推測可能であるという脆弱性を使う Web アプリケーションの SessionID に対して推測攻撃を行うバースデーアタックによる攻撃通常の総当り攻撃辞書攻撃 RainbowCrack 3 不正行為者には既知の SessionID を犠牲者に使わせる (Session Fixation) 有効な SessionID を収集する方法クエリ文字列上の SessionID に対してショルダーハック Referer ヘッダによる漏洩利用者の操作ミスによる漏洩連続してアクセスすることで取得 Session Adoption 問題不正行為者には既知の SessionID を犠牲者に使わせる方法クエリ文字列上の SessionID Cookie Monster 不正行為者自身の HTTP セッションを犠牲者に使わせる (Session Poisoning) 犠牲者が使うことで犠牲者の HTTP セッションに変化する (Session Morfing/Session Modification) 犠牲者が使っても不正行為者自身の HTTP セッションのままで犠牲者が入力した情報は不正行為者が入力した情報として Web アプリケーションに登録される (Session Surrogate) 4. Session Fixation 攻撃 2 SessionID による HTTP セッション管理とはで説明したとおり SessionID は推測困難な値であるそこで攻撃する側が成りすまされる利用者 ( 犠牲者 ) の SessionID を推測するのではなく不正行為者には既知のセッション ID を犠牲者に使わせようという攻撃手法が Session Fixation 攻撃と呼ばれるものである 1 どうせ盗聴するのであれば SessionID を盗難するよりも Credential 情報を盗難した方が効率的かもしれない 2 クッキー情報に httponly 属性が有効な場合は XST( クロスサイトトレーシング ) 攻撃も考えられる 3 SessionID 用の RainbowCrack については聞いたことがないが念のため追加してみた 4

5 この場合不正行為者にとっては犠牲者の SessionID は既知となるため推測する必要がないよって犠牲者がその SessionID を再利用してくれればそのまま犠牲者の HTTP セッションを乗っ取ることが可能となる Session Fixation 攻撃はさらに二つの段階に分解することができる 1. 有効な SessionID を収集する 2. 有効な SessionID を犠牲者に使わせる後述となるが Session Adoption 問題はこの二つの段階の有効な SessionID を収集する側と関連する問題であるので本文書ではもう一つの有効な SessionID を犠牲者に使わせるというのは概要程度にとどめ深く検討することはしていない 4.1. 有効な SessionID を収集する Session Fixation 攻撃を行うために不正行為者は犠牲者に配布するための有効な SessionID を収集しなければならない一般的な Web アプリケーションフレームワーク (ASP.NET や ASP,JSP/JavaServlet,PHP など ) では自動的に SessionID を送出する機能があるそれらの Web アプリケーションに SessionID を持たずにアクセスすれば Web アプリケーションフレームワーク上にセッションオブジェクトが生成されそれに紐付く SessionID が送出されるまたはクエリ文字列上で SessionID を保持している場合は " 画面の覗き見 ( ショルダーハック )" によって収集することも可能性として考えられる 4 さらにクエリ文字列上で SessionID を保持している場合外部サイトへのリンクなどによって "Referer" というリンク元の URL( クエリ文字列を含 ) として外部サイトのサーバのログに書き出されそれを集めるという可能性も考えられるこの他に収集するという意味とは異なるがクライアント (Web ブラウザ ) が決定した任意の値が SessionID として有効になる場合もあるこのような場合は有効な SessionID を集める必要がないなぜなら任意の値を SessionID として用いることができるからだこのようにクライアントが決定した任意の値が SessionID として有効になる問題が Session Adoption 問題と呼ばれている有効な SessionID を収集する主な方法は以下の方法が可能性として考えられるクエリ文字列上に保持されている場合ショルダーハックによる " 覗き見 " "Referer" というリンク元 URL として外部サイト ( 不正行為者が管理者の外部の Web サイト ) のログに漏洩利用者の操作ミスによる漏洩 Web アプリケーションフレームワークで HTTP セッションを自動生成させている場合は SessionID がない状態でアクセスすることで有効な SessionID を集めることができる任意の値の SessionID が有効な場合は有効な SessionID を収集する必要がない (Session Adoption 問題 ) ここで本文書のテーマのである Session Adoption 問題が登場したこの問題については次章 ( 5 Session Adoption 問題 ) 以降でさらに詳しく検討する 4 長い SessionID を瞬間的に暗記できるのかどうかという別の問題があるかもしれない 5

図 4.1-1 : 自動的に SessionID を送信する設定の場合は有効な SessionID を収集することは容易である 4.2.

6 図 : 自動的に SessionID を送信する設定の場合は有効な SessionID を収集することは容易である 4.2. 有効な SessionID を犠牲者に使わせる主に二つの方法があるクエリ文字列上に保持した SessionID が有効な場合 URL(URL はクエリ文字列を含む ) と共に犠牲者に配布 ( メール Web ページのリンクなど ) する Cookie Monster 問題で配布する有効な SessionID を犠牲者に使わせる方法については本文書のテーマではないので割愛する 5. Session Adoption 問題 Session Adoption 問題は Session Fixation 問題の一部というべきものでありクライアント (Web ブラウザ ) が決定した任意の値が SessionID として有効となってしまうという問題であるつまり Session Fixation 問題の中の有効な SessionID を収集するというテーマに関係する問題である SessionID には一意性と推測困難性が必要であり特に推測困難性という性質は SessionID による HTTP セッション管理機能の安全性のよりどころとなっている非常に重要な性質であるよってそもそもクライアントが SessionID を任意の値に決定できる機能は必要ではなくむしろセッション管理機能の安全性を低下させるものであり 5 執筆者の感覚として Session Adoption 問題は Web アプリケーションフレームワークのセキュリティ問題として修正されるべきであると認識しているしかしながら多くの Web アプリケーションでは HTTP セッションを自動的に開始するように設定されているため Session Adoption 問題がなくても有効な SessionID を収集することが可能であるよって Session Adoption 問題が存在しなくても不正行為者の有効な SessionID を収集するという行為を防ぐ手段がないのも事実である 5 クライアントがより推測困難な値を自ら選択してくる可能性はほとんどないだろう 6

7 つまり不正行為者の有効な SessionID を収集するという行為そのものを防ぐためには Session Adoption 問題への対策だけではなく自動開始機能を停止することも必要である蛇足ながら自動開始機能を停止することが困難なケースが多いためそれ故 Session Adoption 問題へ対策が熱心に行われていないかもしれない次章 ( 6 PHP の Session Adoption 問題 ) から PHP で書かれた Web アプリケーションに限定した上でかつ自動開始機能を停止している場合における Session Adoption 問題の役割について検討していく 6. PHP の Session Adoption 問題 PHP には Session Adoption 問題が存在するまた PHP には HTTP セッションを自動的に開始しないような設定が存在する ( 10 参考 1 ) この設定によって PHP には有効な SessionID を収集されないように設定することが可能である以下より PHP のコーディング方法によっては Session Adoption 問題を用いて不正行為者には既知の SessionID を犠牲者に使わせるような攻撃 (Session Fixation 攻撃 ) が成立する可能性について検討する 6.1. 検証環境 OS : CentOS5.4 Apache httpd Server ver2.2.3 PHP ver

6.2. PHP の Session Adoption 問題について 6.2.1 検証結果 ( 機能の確認 ) 1. PHP は HTTP セッションの自動起動を抑止することができる ( 図 6.2-1) 2. 図 6.2-1 の状態で図 6.2-2 のような PHP スクリプトへアクセスする ( 図 6.2-3~ 図 6.

8 6.2. PHP の Session Adoption 問題について検証結果 ( 機能の確認 ) 1. PHP は HTTP セッションの自動起動を抑止することができる ( 図 6.2-1) 2. 図の状態で図のような PHP スクリプトへアクセスする ( 図 6.2-3~ 図 6.2-6) 3. 図 6.2-3~ 図は正常な場合の挙動についての確認である HTTP セッションのない状態でアクセスし ( 図 6.2-3) Web アプリケーションフレームワーク (PHP エンジン ) が生成した SessionID で再アクセスすることでセッションオブジェクトが正常に生成されていることを確認した ( 図 6.2-4) この機能を使えばログイン入力画面では SessionID を送出することなくユーザ認証した場合だけ SessionID を送出するというような芸当が可能であるつまり対象の Web アプリケーションにアクセスするだけで既知の SessionID を大量に収集するという行為に耐性を持つことが可能となる 4. 図 6.2-5~ 図は Session Adoption の場合の挙動を確認している図で Web ブラウザが任意に生成した SessionID を Web アプリケーションへ渡しているその状態でその任意の値の SessionID と紐付いたセッションオブジェクトが Web アプリケーションフレームワーク上で生成されているかどうかを確認したのが図である図を見るとおり正常にセッションオブジェクトは生成されていることが確認できるこのように Session Adoption 問題が Session Fixation 問題の引き金となる場合が非常に稀なケースとは思われるが存在することを確認した図 : php.ini の session.auto_start によって HTTP セッションの自動起動を抑止している 8

input_data の値を $_SESSION['input_data'] に追記するように PHP スクリプトである図 6.2-3 : 図 6.

9 図 : 図の状態で本図のコードを実行する HTTP セッションを開始する session_start() 関数が呼ばれているクエリ文字列 input_data の値を $_SESSION['input_data'] に追記するように PHP スクリプトである図 : 図に対して HTTP セッションのない状態でアクセスした結果このように session_start() 関数によって b6pcs9lojun06ktm60gbmtmb40 という SessionID の HTTP セッションオブジェクトが生成されセッション変数に abcdefg がセットされている 9

10 図 : 図後提示された SessionID を使って再度アクセスした結果この結果から図で作成された HTTP セッションオブジェクトが生きており図の値 (abcdefg) に本図の値 (12345) が追記された図 : 次に図に対して任意の値 aaaaaaaaaaaaa の SessionID を送り Session Adoption を行ってみる Session Adoption によって生成されたセッションオブジェクト上の変数に abcdefg がセットされた 10

11 図 : 図後再度 AdoptionしたセッションIDを使ってアクセスした結果このようにAdoptionしたSessionIDで紐付いたHTTPセッションオブジェクトにという値が追記されたことからHTTPセッションオブジェクトが生きていることが確認できる 6.3. より具体的な PHP の Session Adoption 問題以下のような Web アプリケーションを考えてみる ( 図 6.3-1) 認証情報の入力画面では SessionID は発行されない認証された利用者のみに SessionID が発行される PHP で記述され session_regenerate_id() 関数は使われておらず session_start() 関数のみが用いられている SessionID なしで認証画面以外にアクセスした場合認証画面へリダイレクトされる ( この時点では有効な SessionID は発行されない ) つまり有効な SessionID を収集することができないようにプログラミングされた Web アプリケーションである Session Adoption 問題によってのみ不正行為者には既知の SessionID を犠牲者に使わせることができるような Web アプリケーションのサンプルを作成し実際に挙動の確認を行ったソースコードは図 6.3-2~ 図である通常の挙動を確認しているのが図 6.3-5~ 図であるユーザ名とパスワードを使って auth.php で認証されるまでは SessionID は送出されないようになっている 11

3-12 のように Session Fixation 攻撃を受けてしまう危険性が残ってしまう図 6.

12 また図 6.3-9~ 図のように SessionID なしでアクセスすることでは有効な SessionID を収集することはできないようになっているこのような状態でも Session Adoption 問題がある場合図 ~ 図のように Session Fixation 攻撃を受けてしまう危険性が残ってしまう図 : ページの遷移図これらのページで構成されている Web サイトでは認証されない限り有効な SessionID を収集することはできない図 : auth.php 認証を行う PHP プログラム認証に成功した場合のみ session_start() 関数が呼び出され有効な SessionID が送出される 12

が訪れる認証ユーザ用トップページ図 6.3-4 : check.php 図 6.

13 図 : index.php 認証したユーザ ( 有効な SessionID を有するユーザ ) が訪れる認証ユーザ用トップページ図 : check.php 図や図で Include される PHP プログラムで SessionID を保持しているクッキー情報が取得できるかどうかを確認している 13

14 図 : ログイン画面のイメージ ( 通常動作のイメージ ) ここでユーザ名パスワードを入力すると図 : 図の結果 ( 通常動作のイメージ ) 認証したユーザだけに SessionID が払い出される 14

図 6.3-7 : 認証画面 (login.html) よりユーザ test パスワード test でログインを試みた結果図 6.

3-8 : 図 6.3-7 後 Web ブラウザは SessionID を送り利用者のトップ画面 (index.

15 図 : 認証画面 (login.html) よりユーザ test パスワード test でログインを試みた結果図の通信データのイメージであるため認証に成功しているよって有効な SessionID kcqnjh7l7o0ah81ppr0qlu0df7 が送出されている図 : 図後 Web ブラウザは SessionID を送り利用者のトップ画面 (index.php) へアクセスしたユーザ ID test と表示されセッション ID も正しい値である図 : SessionID なし正しい認証情報なしで auth.php にアクセスしても SessionID を取得することできずに login.html へリダイレクトされる 15

16 図 : SessionID なし正しい認証情報なしで index.php にアクセスしても SessionID を取得することできずに login.html へリダイレクトされる ( 図と同様 ) 図 : 次は Session Adoption 問題を使って任意の値 ( ) を SessionID として送り込みつつ認証行う犠牲者が入力したユーザ情報により認証されそのまま index.php へリダイレクトされる図 : 図後 index.php へアクセスし正しく利用者のトップ画面が表示されたこのように図や図のような有効な SessionID を収集することができない Web アプリケーションであっても Session Adoption 問題が脅威となる場合がある 16

17 6.4. Session Adoption 問題と PlaceFolder の undefined 問題 6.3 より具体的な PHP の Session Adoption 問題には実は重要な脆弱性があるそれが図 6.4-1~ 図である図の auth.php のソースコードを確認してみるとユーザ ID とパスワードが与えられていない場合は ( 現時点で有効ではなくても )SessionID があるかどうかだけで認証済みか否かを判断しているよって図 6.4-1~ 図のように認証されていない場合であっても SessionID を提示するだけで index.php へアクセスすることが可能であるよって HTTP セッションを自動起動するような設定にしていない場合 ( 図および図 6.3-2~ 図のような Web アプリケーション ) HTTP セッションの存在が認証済み利用者からのアクセスであるということではないという点に注意して認証ロジックを実装する必要である 6 さらに図のような PHP スクリプトを考えてみるこのスクリプトは HTTP セッションが有効であればログインしたユーザ ID が $_SESSION['user_id'] に格納されていると想定しそれを使って本人情報だけを表示させようとしている点がポイントである 7 実際図は通常のログイン処理 (auth.php) を経由してアクセスした結果である通常のログイン処理によって $_SESSION['user_id'] にログインしたユーザ ID がセットされてしまっているため本人情報のみが表示されている一方で Session Adoption した場合の図が図である Session Adoption したことで $_SESSION['user_id'] は不定の値であるため本人情報のみに制限されず全件が表示されていることが確認できる 8 このように HTTP セッションを自動起動しないように設定している場合 HTTP セッションの存在 = 認証済みとは限らないという点に注意して認証ロジックを実装することが必要である本文書ではセッション ID が存在した場合 $_SESSION['user_id'] の値も確認するように check.php を修正した ( 図 6.4-6) 図のように修正することで図 6.4-1~ 図のような挙動を防ぐことが可能である ( 図 6.4-7) 6 自動的に HTTP セッション管理機能が起動するように設定している場合認証前から HTTP セッションが有効になっていることからこのような状況に応じた認証ロジックを実装している開発者がほとんどであると思われるのであえて HTTP セッションを自動起動するような設定にしていない場合という点を強調した 7 サンプルのコードでは変数がセットされているかどうか判断し Place Folder が確実に未定義になるようなコードとなっている 8 執筆者はセキュリティ診断作業中において稀に Session Adoption を引き金にしてこのような情報漏えいとなるようなセキュリティ問題を確認することがあるため開発者の方は未定義の PlaceFolder がないように注意してほしい 17

図 6.4-1 : 任意の値 (1234567) の SessionID を与えさえすれば auth.php の認証は通過し index.

18 図 : 任意の値 ( ) の SessionID を与えさえすれば auth.php の認証は通過し index.php へリダイレクトされる図 : 図後の画面認証チェックをすり抜けユーザ ID は不定の状態となっている 18

19 図 : user_info.php $_SESSION['user_id'] を使って利用者情報を表示する PHP この PHP プログラムの背景には必ず $_SESSION['user_id'] はセットされているはずでありよって本人情報だけが表示されるはずであると想定している点である図 : 通常のログイン処理を行っている場合 $_SESSION['user_id'] はセットされているため図で示した PHP プログラムはこの図のように本人情報しか表示されない 19

20 図 : 図 6.4-2のようなSession Adoptionされている状態では $_SESSION['user_id'] の値がセットされていないよって図 6.4-3のPHPプログラムにアクセスした結果はこのように本人以外の情報も表示されてしまうつまりユーザIDがセットされている前提が崩れ全件表示されてしまう事態となっている図 : HTTP セッションが有効かどうかの確認を行う check.php( 図 6.3-4) を修正し $_SESSION['user_id'] の有無まで確認するようにした check.php 20

21 図 : 認証ロジックを図に差し替えることにより図のような認証していない適当な SessionID を与えても認証画面へリダイレクトするようになる 6.5. Session Morfing(Session Modification) 6.3 より具体的な PHP の Session Adoption 問題で検討した図の auth.php と図の index.php を使いさらに 6.4 Session Adoption 問題の図の check.php を使ってさらに Session Fixation 問題を検討していきたい 6.3 より具体的な PHP の Session Adoption 問題で想定していた SessionID は任意の値であるが不正行為者の HTTP セッションの SessionID はどうだろうか本章と 6.6 Session Surrogate は任意の SessionID が有効になる Session Adoption 問題とは無関係であるが 6 PHP の Session Adoption 問題からつながる Session Poisoning (Session Modification) の一つとして検討してみたつまり図 6.5-1~ 図のように不正行為者が認証した状態でこの SessionID を犠牲者に使わせるのである ( 図 6.5-4~ 図 6.5-5) 不運なことに図の auth.php と図の index.php 図の check.php は認証後の $_SESSION['user_id'] が上書きされるよって図 6.5-1~ 図後の図のように犠牲者が不正行為者の HTTP セッションの SessionID を使ってログインしてしまうと $_SESSION['user_id'] が不正行為者の識別情報から犠牲者の識別情報に書き換わってしまうその後に不正行為者にとっては既知である SessionID を使ってアクセスすれば犠牲者の HTTP セッションを乗っ取ることが可能となるしかしながら不正行為者が攻撃対象の Web アプリケーションに対してアカウント登録を行いかつログインすることで SessionID を取得しその SessionID を犠牲者に使わせるという方法は不正行為者にとってはあまりにも煩雑で非効率 9 であるため悪用されにくいとは思われるが理論的な不正行為としては考えられるのではないだろうか 9 同時に攻撃を行う犠牲者ごとに登録済みアカウントと紐付いた SessionID が必要になる 21

対策として考えられるのは認証情報の上書きを行う場合は SessionID を再生成する認証済みである HTTP セッションに関しては認証情報 ( 本文書では $_SESSION['user_id' ]) の上書きを行わない ( 図 6.5-7~ 図 6.

22 対策として考えられるのは認証情報の上書きを行う場合は SessionID を再生成する認証済みである HTTP セッションに関しては認証情報 ( 本文書では $_SESSION['user_id' ]) の上書きを行わない ( 図 6.5-7~ 図 ) などが考えられる図 : 不正行為者のアカウントでログイン処理を行う図 : 図後の PHP の画面不正行為者の HTTP セッションを識別する SessionID は lvn1f3uhg04qc43roq5562ak52 である 22

23 図 : 図後にリダイレクトした index.php の画面 SessionID は lvn1f3uhg04qc43roq5562ak52 は不正行為者の HTTP セッション (user_id=hacker) である図 : 図後図と同一の SessionID を使って犠牲者がログイン処理を行ってしまうとどうなるだろうか図 : 図後のindex.phpでは直前のauth.php( 図 6.3-2) によって $_SESSION['user_id'] が hacker から test に上書きされているこの現象から犠牲者のHTTPセッションを識別するSessionIDは不正行為者には既知となっているため不正行為者にHTTPセッションを乗っ取られる危険性がある 23

24 図 : 図 6.5-1~ 図の流れ SessionID は同一のまま hacker の HTTP セッションが test の HTTP セッションへ変化した図 : 次に auth.php を図のように $_SESSION['user_id'] が存在する場合は認証情報を上書きしないように書き換えた詳細は check.php( 図 6.4-6) を参照 24

25 図 : 図に対してユーザ hacker でログインする図 : 図後に index.php にリダイレクトした結果 hacker の SessionID は 6nu5c7r4c17dnq4sje1osc2vl0 となっている図 : 既に hacker でログインしている SessionID を使って図に対してユーザ test がログインを試みている 25

図 6.5-11 : 図 6.5-10 の結果 HTTP セッションは hacker のままである図 6.5-12 : 図 6.5-8~ 図 6.

26 図 : 図の結果 HTTP セッションは hacker のままである図 : 図 6.5-8~ 図までを Web ブラウザの画面で見てみるこれはユーザ hacker でログインする画面図 : 図の結果画面ユーザ hacker としてログインし SessionID は 4eoks2qsspm6nrfe4rq58n1j12 となっている 26

図 6.5-14 : 図 6.5-13 後にそのまま今度はユーザ test でログインしてみる図 6.5-15 : 図 6.5-14 の結果図 6.

5 Session Morfing では不正行為者の HTTP セッションが犠牲者の HTTP セッションに変化したが変化しない場合でも個人情報などの搾取するための HTTP セッション管理への攻撃は理論的には考えられる

27 図 : 図後にそのまま今度はユーザ test でログインしてみる図 : 図の結果図と同一の SessionID であるがユーザは hacker のままでユーザ test へ変化することはなかった 6.6. Session Surrogate (Session サロゲート ) 6.5 Session Morfing では不正行為者の HTTP セッションが犠牲者の HTTP セッションに変化したが変化しない場合でも個人情報などの搾取するための HTTP セッション管理への攻撃は理論的には考えられる本章ではこの件について検討していく不正行為者にとっては 6.5 Session Morfing よりもさらに条件が厳しくなり Web ページ上に誰がログインしているか表示されていないなど社会工学的な条件などが必要になるさらに不正行為者にとっては他者になりすますことができるわけではないため悪用の効果も限定的である 27

セキュリティ診断を行っているとこのようなユーザ情報を画面に表示していない Web ページが稀にではあるが存在するその場合自分が現在利用している HTTP セッションが自分のものであるかどうか認識できない状態となってしまうこのような Web ページでは利用者の不注意も加わり他者の HTTP

5 Session Morfing 以上に不正行為者にとっては煩雑で非効率であるため極めて低いと考えられる本項に関しての対策は以下が考えられる Web ページ上にはこんにちはさんやさんがログイン中のように誰の HTTP セッションであるかを明示しておく図 6.6-1 : 図 6.

28 セキュリティ診断を行っているとこのようなユーザ情報を画面に表示していない Web ページが稀にではあるが存在するその場合自分が現在利用している HTTP セッションが自分のものであるかどうか認識できない状態となってしまうこのような Web ページでは利用者の不注意も加わり他者の HTTP セッションを使っていることに気づかずに自分自身の個人情報 / パスワードなどを入力してしまうという危険性も考えられる実際の攻撃可能性は 6.5 Session Morfing 以上に不正行為者にとっては煩雑で非効率であるため極めて低いと考えられる本項に関しての対策は以下が考えられる Web ページ上にはこんにちはさんやさんがログイン中のように誰の HTTP セッションであるかを明示しておく図 : 図のように変化しなくても不正行為者の HTTP セッションを使って犠牲者は個人情報などの機密情報を入力するかも知れない 7. Session Hijack の現実的な脅威他者の HTTP セッションを乗っ取るという攻撃 (Session Hijack) は現実的にどの程度の脅威があるのだろうか Session Hijack 攻撃の現実的な危険性を検討することでその一部である Session Fixation 攻撃の現実的な危険性も推定できるのではないだろうか他者の HTTP セッションを乗っ取るという攻撃は結局のところ " 他者になりすます " ということに帰着してしまう 28

29 " 他者になりすます " といったセキュリティ上のテーマを考えてみた場合 HTTP セッションを乗っ取る以外にも以下の脅威が存在する他者のユーザ名 / パスワード (Credential 情報 ) を盗むこちらの場合と HTTP セッションを乗っ取る場合との違いについて考察した HTTP セッションの乗っ取り HTTP セッションに設けられたタイムアウトの制限がある HTTP セッションを維持し続けなければならない credential 情報の盗難犠牲者がパスワード変更を行わない限りいつまでも利用可能また Credential 情報の盗難の代表としてフィッシング詐欺と Session Poisoning の代表として Session Fixation 攻撃について具体的な手順を比較してみた Session Fixation 攻撃 1. 有効な SessionID を収集 2. 収集した SessionID を犠牲者にばら撒く 3. 犠牲者が罠にかかる 4. 罠にかかった犠牲者の SessionID を特定することで不正行為者は HTTP セッションの乗っ取りが完成するフィッシング詐欺 1. フィッシングサイトの開設 2. 犠牲者にフィッシングサイトの URL をばら撒く 3. 犠牲者が罠にかかる 4. 後ほど犠牲者の Credential 情報を使って成りすます段階として共に 4 段階であるが Session Fixation 攻撃に関してはこれを HTTP セッションのタイムアウト 10 の制限以内 11 に実行しなければならないのに比べフィッシング詐欺においてはとくに時間的制限は必要とされない 12 このように考えると Session Poisoning するぐらいならフィッシング詐欺などで Credential 情報を収集した方が不正行為者としてはコストパフォーマンスが高いと考えてもよいだろうつまり Session Poisoning 攻撃自体 PKI 認証 ( 電子証明書 ) の普及がそれほど進んでいない現時点 (2009 年末 ~2010 年初頭 ) では危険性が高いセキュリティ上の問題とは言えないと評価してもよいだろう 8. まとめ {PHP の Session Fixation 対策 (Session Adoption 対策 )} 6 PHP の Session Adoption 問題で検証したように自動で HTTP セッションを開始しないように構成された PHP で書かれた Web アプリケーションではプログラミングの方法に問題があるとしても Session Adoption 問題が存在するためにセキュリティ上の脅威になるような場面は確認されたまた有効な SessionID を収集するための事前準備も必要ない 13 という点でも Session Adoption 問題をセキュリティ上の問題と捉えるべきではないだろうか 10 実際には 3 で犠牲者が罠にかかるときに Web アプリケーションにアクセスしタイムアウトはリセットされるのでタイムアウトの 2 倍の時間の制限という表現がより適切である 11 ハートビートを行うなどでタイムアウトを延長させることができる場合もあるので困難なハードルではないかも知れない 12 " フィッシングサイトである " とアンチウィルスソフトベンダーに認定される場合を考えると時間的制限がないわけではない 29

30 しかしながら非常に大きな影響を与える脆弱性とは執筆者自身も考えてはいない Session Adoption 問題は SessionFixation 問題の一部と考えることができると筆者は考えているよって高中低という大まかな三段階評価でイメージすれば低 ( 場合によっては中 14) 程度の危険性を有するセキュリティ上の問題ではないだろうかというのが執筆者の個人的な感想である 15 実際の攻撃可能性について吟味してみると Session Fixation 問題によって盗難できるのは所詮は HTTP セッションだけであるフィッシングサイトによって利用者のアカウントを盗難する方が手間も少なくかつ利益も大きいのではないだろうかと考えると不正行為者によって実際に悪用されにくい脆弱性ではないだろうかさて PHP の場合 Session Adoption 問題が修正される気配はないよってこのようなセキュリティ上の問題となる Web アプリケーションを作らないように Web プログラマが注意深くプログラムを作成する必要がある PHP の場合の Web プログラマ側での対策は session_regenerate_id() 関数を使い SessionID を再生成することつまり不正行為者が犠牲者に使わせた任意の SessionID を破棄して Web アプリケーションが推測困難な ID に再生成することであるこれによって Session Adoption 問題を解決することができるより一般的な (Session Adoption 問題を含む )Session Fixation 問題へ対策は以下のような項目などが考えられる認証後 ( ログイン処理が代表であるが自動ログイン機能がある場合はログイン機能に限定されない ) に Web アプリケーション側で SessionID を再生成する 16 セキュリティ重視の利用者のためにログオフ処理を用意し速やかに有効な HTTP セッションを破棄させる HTTP セッションの有効時間を適切に短いものにする同時ログインを禁止し再ログインした場合以前の HTTP セッションを破棄する ( ユーザ 1 人に 1 つの HTTP セッションの原則 ) しかしながら PHP のような Web アプリケーションフレームワークがクライアント (Web ブラウザ ) が設定した任意の値を SessionID として有効にできるということは Web プログラマによる注意深いセキュアプログラミングで解決可能とはいえ Web アプリケーションフレームワークのセキュリティ上の問題ではないだろうか蛇足ではあるが PHP ver5.1.0 以降の session_regenerate_id() 関数では第一引数が定義され古いセッションオブジェクトを破棄することも可能となった ( 図 6.6-1) 今後は session_regenerate_id() 関数を使う際に古い SessionID でアクセスさせる必要がない場合は第一引数に true を与え古いセッションオブジェクトを破棄するようにプログラミングすることを推奨する ( 10 参考の 11) 13 監視センターを有する場合はこの準備段階で攻撃の予兆を捉えることができるかもしれない 14 人気の Web サイトであることや自動ログインが有効であることクエリ文字列上の SessionID が有効であることなどが危険性を高める条件となるだろう 15 Session Fixation と Session Adoption の関係は XSS 問題の付属問題としての XST 問題の関係を髣髴とさせるのは執筆者だけだろうか 16 クッキー情報に SessionID を保持している場合は格段に問題とならないがクエリ文字列や Hidden フィールドに保持している場合頻繁に SessionID を書き換えてしまうと HTTP セッションが引き継がれないなどの弊害が発生するかもしれない 30

もう一つ蛇足ながらフレームワークの機能として Session 再生成機能がない場合などは

31 もう一つ蛇足ながらフレームワークの機能として Session 再生成機能がない場合などは Session 変数とクッキー情報上に推測困難な値を保持しておき適時その値を再生成することで再生成機能と代わりとすることも可能である ( 図 6.6-2) 図 : 図 : 自作クッキーとセッション変数も含めて SessionID とみなすことでフレームワークに実装していないセッション管理の機能を実装させることが可能 31

32 9. 検証作業者 NTT コミュニケーションズ株式会社 IT マネジメントサービス事業部ネットワークマネジメントサービス部セキュリティオペレーションセンター佐名木智貴本城敏信 10. 参考 1. PHP: session_start - Manual 2. PHP: 実行時設定 - Manual 3. PHP: session_regenerate_id - Manual 4. PHP: session_id - Manual 5. CSRF と Session Fixation の諸問題について 6. Session Fixation Vulnerability in Web-based Applications 7. Cookiemonster - Cookie Bug Affecting Non-Generic Domains 8. Cross Site Cooking 9. PHP の Session Adoption は重大な脅威ではない PHP: 既知のセキュリティ脆弱性 - Session Adoption session_regeneration_id とセッションフィクシエーション対策セキュア Web プログラミング Tips 集 ( 出版社 : 株式会社ソフトリサーチセンター ) ISBN= 履歴 2010 年 03 月 09 日 : ver1.0 最初の公開 32

33 12. 最新版の公開 URL 本レポートに関する問合せ先 NTT コミュニケーションズ株式会社 IT マネジメントサービス事業部ネットワークマネジメントサービス部セキュリティオペレーションセンター以上 33

SOC Report

SOC Report mailto スキームのエスケープについて N T T コミュニケーションズ株式会社経営企画部マネージドセキュリティサービス推進室セキュリティオペレーション担当 2013 年 02 月 01 日 Ver. 1.0 1. 調査概要... 3 1.1. 調査概要... 3 2. MAILTO スキームでのエスケープ処理... 3 2.1. 脆弱なWEBページを想定する