クロスサイトリクエストフォージェリ (XSRF) Universität Hamburg なぜ配慮しないといけないか PacSec 2006 2006 年 11 月 27 日 ~30 日 Martin Johns Fachbereich Informatik SVS Sicherheit in Verteilten Systemen
自己紹介 Martin Johns informatik.uni-hamburg.de 所属 ハンブルク大学セキュリティ研究者 Secologic プロジェクトメンバー SAP Commerzbank Eurosec ハンブルク大学が推進する研究プロジェクト ドイツ連邦経済技術省 (BMWi) 後援プロジェクト 目標 : ソフトウェアのセキュリティ向上 詳しくは http://www.secologic.org まで Martin Johns, UH, FB Inf, SVS, 2006 2
内容 ウェブアプリケーションの認証 XSRF / セッションライディング サーバー側の対策 クライアント側の保護 結論 Martin Johns, UH, FB Inf, SVS, 2006 3
内容 ウェブアプリケーションの認証 XSRF / セッションライディング サーバー側の対策 クライアント側の保護 結論 Martin Johns, UH, FB Inf, SVS, 2006 4
明示的な認証 認証証明がウェブアプリケーションによって伝達される URL のリライト : セッショントークンが各 URL に含まれる フォームによるセッショントークン XSRF に強い ( 唯一ほぼ確実な保護策といえる ) Martin Johns, UH, FB Inf, SVS, 2006 5
暗黙的な認証 ブラウザにより自動的に実行される クッキー http 認証 (Basic Digest NTLM) IP によるスキーム クライアント側の SSL XSRF に対して潜在的に脆弱である Martin Johns, UH, FB Inf, SVS, 2006 6
クッキーによるセッション管理 認証フォームの後 サーバーがクライアントのブラウザにクッキーを設定する このクッキーが有効である限り クライアントの要求は認証されたものとして扱われる Martin Johns, UH, FB Inf, SVS, 2006 7
http 認証 (Basic Digest) クライアントサーバー クライアントが制限されたリソースを要求する GET index.html 401 Unauthorized GET index.html Authorization: h3m8dxjh 200 OK HTML data サーバーは 401 Unauthorized で応答する これによってクライアントのブラウザは証明を要求する クライアントが要求を再送信する ユーザの証明は Authorization のヘッダとして含まれる 今後 この認証領域に対する要求にはすべて自動的に証明が含まれるようになる Martin Johns, UH, FB Inf, SVS, 2006 8
クライアント側の SSL 認証 ウェブアプリケーションにより信頼された機関が署名した X.509 の証明をクライアントのウェブブラウザが持っている 初期認証 : クライアントは自己証明しなければしなければならないならない そのため ウェブサーバーはクライアントからの有効な署名を要求する SSL handshake ブラウザによっては ユーザがパスワードを入力 ( 一回のみ ) した際に初期接続確立を確認できる場合も そうでない場合もある 接続が確立すれば クライアントのブラウザとウェブサーバーとの間で SSL セッションが成立する SSL セッションが有効である限り ウェブサーバーに対するすべての要求は折衝済みの証明を用いて送信される Martin Johns, UH, FB Inf, SVS, 2006 9
IP による認証 ファイヤウォール イントラネットウェブサーバー Martin Johns, UH, FB Inf, SVS, 2006 10
内容 ウェブアプリケーションの認証 XSRF / セッションライディング サーバー側の対策 クライアント側の保護 結論 Martin Johns, UH, FB Inf, SVS, 2006 11
XSRF / セッションライディング暗黙的な認証メカニズムをメカニズムを攻撃する 2001 年から知られるようになった 別名 XSRF CSRF セッションライディング ( シーサーフ とも ) 未知で / 重要視されていない (XSS やSQL インジェクションと比べて ) アタックベクター攻撃 : 攻撃者は標的とするウェブブラウザの中で隠れた http 要求を作成する この要求は標的の認証コンテクストの中で実行される Martin Johns, UH, FB Inf, SVS, 2006 12
XSRF / セッションライディング (II) www.bank.com Cookie: auth_ok Martin Johns, UH, FB Inf, SVS, 2006 13
XSRF / セッションライディング (II) www.bank.com www.attacker.org GET transfer.cgi?am=10000&an=3422421 Cookie: auth_ok Martin Johns, UH, FB Inf, SVS, 2006 14
XSRF / セッションライディング (III) 原因 : 状態変更要求がウェブアプリケーション 内で 作成されたことをウェブアプリケーションが確認しない攻撃法 : GET 要求を作成する : SRC 属性を持つ画像タグが状態変更 URL を指定する この URLはhttp リダイレクトにより難読化される可能性がある POST 要求を作成する : 攻撃者が IFRAME( ( またはポップアップウィンドウ ) を作成する このフレームには HTML フォームが含まれる このフォームは JavaScript で送信される Martin Johns, UH, FB Inf, SVS, 2006 15
XSRF / セッションライディング (IV) 反射型 : 攻撃者は隠れた要求の生成元をホストするようなウェブサイトを作成しなければならない ローカル / 蓄積型 : 悪意のある http 要求の生成元は攻撃を受けたウェブサイト上でホストされる 例 : ユーザは海外の URL で画像を掲載を掲載できる Martin Johns, UH, FB Inf, SVS, 2006 16
例 1: アプリケーションの破壊攻撃対象 : digg.com digg.com のフロントページは 各々のストーリーが獲得する digg ( ( 投票 ) 数によって決定される XSRF の使用により ウェブページは標的とするブラウザに任意のURLを digg ( ( 投票 ) させることができた このデモ用ページも自ら digg ( ( 投票 ) したものである Martin Johns, UH, FB Inf, SVS, 2006 17
例 2: 経済的な損失を与える攻撃対象 : Netflix.com ユーザのレンタルキューに複数の動画を加える ユーザのレンタルキューのトップに動画を加える ユーザアカウント上の氏名と住所を変更する ユーザアカウント上のメールアドレスとパスワードを変更する ( つまりユーザのアカウントを乗っ取る ) ユーザアカウントをキャンセルする ( 未確認 / 推測 ) Martin Johns, UH, FB Inf, SVS, 2006 18
例 3: サーバーを獲得する攻撃対象 : Wordpress 2.02 Wordpress のテーマエディタは XSRF に対して脆弱だった Wordpress のテーマファイルは php-files にもできる XSRF によって攻撃者は 任意の php コードを挿入するために テーマファイルを修正を修正できた Martin Johns, UH, FB Inf, SVS, 2006 19
例 4: イントラネットへの侵入攻撃対象 : ( ほとんどの ) イントラネットウェブサーバー 外部の画像を過度に挿入し 時間設定した JavaScript イベントを使うことによって 悪意のあるウェブサイトは例えば下記のようなことができる : イントラネットをポートスキャンする 既存のウェブサーバーやインストールされたアプリケーションにフィンガープリントする JavaScript マルウェア Intranet webserver Firewall Malicious site Martin Johns, UH, FB Inf, SVS, 2006 20
XSRF / セッションライディング (IV) 全般的な問題 : セッションライディングに対する脆弱性はプログラミング上のミスによって起こるものではない 完全に正確なコードでも攻撃対象になりうる セッションライディングの原因は http にある : 専用の認証証明がない 状態変更 GET 要求 JavaScript セッションライディング対策 とは 実は プロトコルを改善することである Martin Johns, UH, FB Inf, SVS, 2006 21
内容 ウェブアプリケーションの認証 XSRF / セッションライディング サーバー側の対策 クライアント側の保護 結論 Martin Johns, UH, FB Inf, SVS, 2006 22
誤解 POST 要求のみを承認する ローカル攻撃を防ぐ 海外のウェブページでは 隠れた POST 要求をフレームで作成できるリファラチェック 一部のユーザはリファラを禁止している リファラのない要求の承認がの承認が必要である リファラがなくても http 要求を選択的に作成できる技術がある : さらに リファラは Flash でなりすましができる Martin Johns, UH, FB Inf, SVS, 2006 23
手法 1: 明示的な認証への移行 URL のリライト : セッショントークンは各 URL に含まれる 注意 : プロキシログ / リファラを介したトークンの流出 ローカル攻撃を防ぐことはできない アプリケーションにより作成されたすべての URL にはトークンが含まれる フォームによるセッショントークン セッショントークンは 隠れた フォームフィールドを介して伝達される 注意 : Back ボタンを壊す可能性がある明示的 暗黙的メカニズムのメカニズムの組み合わせ 例 クッキーと URL のリライト 使用されたフレームワークによるサポートが必要 しかし 依然 SID の流出は問題となるだろう Martin Johns, UH, FB Inf, SVS, 2006 24
手法 2: マニュアルによる保護 反射型攻撃 : POST 要求だけに対して状態変更要求の作成を許可する (http の発明者が意図していたとおり ) 一回のみ有効なフォームトークンを使用する ( ノンス ) 例 : これにより ウェブアプリケーションにより提供された HTML のフォームがそもそも POST 要求の生成元であったことが確認できる <form action="submit.cgi" method="post"> <input type="text" name="foo"> <input type="hidden" name="nonce" </form> value="xulkjsf22enbsc"> Martin Johns, UH, FB Inf, SVS, 2006 25
手法 2: マニュアルによる保護 (II) ローカル攻撃 : すべての海外コンテンツの海外コンテンツのミラーを作るのミラーを作る 任意の URL を認めない ユーザのサーバーからの画像のみを提供する 注意 : 自分のコンピュータに攻撃者から任意のデータが保存されないようにすること Martin Johns, UH, FB Inf, SVS, 2006 26
手法 3: 自動保護 NoForge [1] リバースプロキシ ウェブアプリケーションとインターネットの間に位置する http レスポンスを解析し すべての内部 URL に対してトークンを与える トークンを含まない要求をドロップする セッショントラッキングにクッキーを使用するアプリケーションのみ保護する [1] Nenad Jovanovic, Engin Kirda and Christopher Kruegel, Preventing Cross Site Request Forgery Attacks, IEEE International Conference on Security and Privacy in Communication Networks (SecureComm), Baltimore, MD, August 2006, http://www.seclab.tuwien.ac.at/papers/noforge.pdf Martin Johns, UH, FB Inf, SVS, 2006 27
内容 ウェブアプリケーションの認証 XSRF / セッションライディング サーバー側の対策 クライアント側の保護 結論 Martin Johns, UH, FB Inf, SVS, 2006 28
RequestRodeo: 概念 クライアント側のプロキシまたはブラウザ拡張 ( RequestRodeo ) 潜在的な不正要求の特定 暗黙的な認証の排除 ブラウザの改善 Martin Johns, UH, FB Inf, SVS, 2006 29
疑わしい要求の特定 要求の生成元によってその状態が決定する 定義 : 許可された要求 http 要求は下記の場合のみ許可された要求許可された要求と分類される : あるウェブページとのやりとり ( 例 : リンクのクリック フォームの送信 またはJavaScriptを経る ) によって作成された要求であり かつ 初めのページのURLと要求されたページのURLが 同一生成元ポリシー に準拠している要求の状態はブラウザによって決まる 許可された要求のみが暗黙的な認証情報を持つことを許される Martin Johns, UH, FB Inf, SVS, 2006 30
プロキシソリューション : http レスポンスの処理 URL にトークンを加える http レスポンス内の HTML コードが処理される http 要求を生成する可能性のある要素の特定 URL トークンによって その要素の標的となる URL が強化される トークンはレスポンスの URL と共にテーブル内に保存される このようにプロキシは要求の生成元を決定できる 信頼できるリファラ 各々の http 要求に URL トークンがあるか否かがチェックされる トークンがある場合 その元となる URL が検索される 要求のドメインとその生成元が一致しない場合 暗黙的な認証情報は排除される Martin Johns, UH, FB Inf, SVS, 2006 31
暗黙的な認証の排除 クッキー : クッキー フィールドはすべて 無許可の要求無許可の要求から排除される クッキーのドメイン値は考慮されなければならない http 認証 : ブラウザ拡張 : 無許可の要求に対する新たな認証の交渉のきっかけとなる プロキシ : 認証ヘッダ を排除する前に URL にトークンを加える クライアント側の SSL: 要求を送信する前に警告ウェブサイトウェブサイトを表示する 気づきにくい : ユーザは画像タグによる隠れた攻撃に気づきにくい Martin Johns, UH, FB Inf, SVS, 2006 32
暗黙的な認証の排除 (II) IP による認証 無許可の要求が認められるのはその対象が世界規模である場合のみ このため リフレクションサーバー が導入される リフレクションサーバーは DMZ でホストされている ( つまり内部ファイヤウォールの反対側にあることになる ) 無許可の要求を認める前に プロキシはリフレクションサーバーがその要求対象対象にアクセスできることを確認する チェックした IP のキャッシングによって パフォーマンス低下を最小限に抑える このようなリフレクションサーバーによって JavaScript マルウェア からも保護できる Martin Johns, UH, FB Inf, SVS, 2006 33
暗黙的な認証の排除 : IP による認証 DMZ RequestRodeo HEAD? OK リフレクションサーバー イントラネットウェブサーバー 内部ファイヤウォール 外部ファイヤウォール 悪意のあるサイト Martin Johns, UH, FB Inf, SVS, 2006 34
暗黙的な認証の排除 : IP による認証! DMZ RequestRodeo? DENY HEAD リフレクションサーバー イントラネットウェブサーバー 内部ファイヤウォール 外部ファイヤウォール 悪意のあるサイト Martin Johns, UH, FB Inf, SVS, 2006 35
導入 プロキシ [1]: Python に導入 Twisted フレームワークを使用 www.secologic.org でリリース予定 ブラウザ拡張 : Firefox への拡張 開発中 [1] "RequestRodeo: Client Side Protection against Session Riding, Martin Johns and Justus Winter, in Proceedings of the OWASP Europe 2006 Conference by Piessens, F. (ed.), Report CW448, Katholieke Universiteit Leuven, 2006 Martin Johns, UH, FB Inf, SVS, 2006 36
検討事項 慎重なアプローチ : 接続を許可する 暗黙的な認証を排除するのみとする パブリックリソースに対する要求は阻止しない サーバー側では微調整も効果的である制限 : ローカル 攻撃からの保護はできない プロキシソリューション : NTLM / クライアント側の SSL は実施されない 今後の課題 XSS 対策テクニックの追加 Martin Johns, UH, FB Inf, SVS, 2006 37
内容 ウェブアプリケーションの認証 XSRF / セッションライディング サーバー側の対策 クライアント側の保護 結論 Martin Johns, UH, FB Inf, SVS, 2006 38
結論 セッションライディングは問題である! 正しく見えるコードも攻撃を受ける可能性がある! プログラマ : できる限りノンスを使うユーザ : ログアウトする! Martin Johns, UH, FB Inf, SVS, 2006 39
おわりに ご清聴ありがとうございましたご質問ご意見はありませんか? Martin Johns, UH, FB Inf, SVS, 2006 40