Microsoft PowerPoint - psj06johns-j.ppt

Size: px

Start display at page:

Download "Microsoft PowerPoint - psj06johns-j.ppt"

りさこやまがた
5 years ago
Views:

1 クロスサイトリクエストフォージェリ (XSRF) Universität Hamburg なぜ配慮しないといけないか PacSec 年 11 月 27 日 ~30 日 Martin Johns Fachbereich Informatik SVS Sicherheit in Verteilten Systemen

2 自己紹介 Martin Johns informatik.uni-hamburg.de 所属ハンブルク大学セキュリティ研究者 Secologic プロジェクトメンバー SAP Commerzbank Eurosec ハンブルク大学が推進する研究プロジェクトドイツ連邦経済技術省 (BMWi) 後援プロジェクト目標 : ソフトウェアのセキュリティ向上詳しくはまで Martin Johns, UH, FB Inf, SVS,

3 内容ウェブアプリケーションの認証 XSRF / セッションライディングサーバー側の対策クライアント側の保護結論 Martin Johns, UH, FB Inf, SVS,

4 内容ウェブアプリケーションの認証 XSRF / セッションライディングサーバー側の対策クライアント側の保護結論 Martin Johns, UH, FB Inf, SVS,

5 明示的な認証認証証明がウェブアプリケーションによって伝達される URL のリライト : セッショントークンが各 URL に含まれるフォームによるセッショントークン XSRF に強い ( 唯一ほぼ確実な保護策といえる ) Martin Johns, UH, FB Inf, SVS,

6 暗黙的な認証ブラウザにより自動的に実行されるクッキー http 認証 (Basic Digest NTLM) IP によるスキームクライアント側の SSL XSRF に対して潜在的に脆弱である Martin Johns, UH, FB Inf, SVS,

7 クッキーによるセッション管理認証フォームの後サーバーがクライアントのブラウザにクッキーを設定するこのクッキーが有効である限りクライアントの要求は認証されたものとして扱われる Martin Johns, UH, FB Inf, SVS,

8 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,

9 クライアント側の SSL 認証ウェブアプリケーションにより信頼された機関が署名した X.509 の証明をクライアントのウェブブラウザが持っている初期認証 : クライアントは自己証明しなければしなければならないならないそのためウェブサーバーはクライアントからの有効な署名を要求する SSL handshake ブラウザによってはユーザがパスワードを入力 ( 一回のみ ) した際に初期接続確立を確認できる場合もそうでない場合もある接続が確立すればクライアントのブラウザとウェブサーバーとの間で SSL セッションが成立する SSL セッションが有効である限りウェブサーバーに対するすべての要求は折衝済みの証明を用いて送信される Martin Johns, UH, FB Inf, SVS,

10 IP による認証ファイヤウォールイントラネットウェブサーバー Martin Johns, UH, FB Inf, SVS,

11 内容ウェブアプリケーションの認証 XSRF / セッションライディングサーバー側の対策クライアント側の保護結論 Martin Johns, UH, FB Inf, SVS,

12 XSRF / セッションライディング暗黙的な認証メカニズムをメカニズムを攻撃する 2001 年から知られるようになった別名 XSRF CSRF セッションライディング ( シーサーフとも ) 未知で / 重要視されていない (XSS やSQL インジェクションと比べて ) アタックベクター攻撃 : 攻撃者は標的とするウェブブラウザの中で隠れた http 要求を作成するこの要求は標的の認証コンテクストの中で実行される Martin Johns, UH, FB Inf, SVS,

13 XSRF / セッションライディング (II) Cookie: auth_ok Martin Johns, UH, FB Inf, SVS,

14 XSRF / セッションライディング (II) GET transfer.cgi?am=10000&an= Cookie: auth_ok Martin Johns, UH, FB Inf, SVS,

15 XSRF / セッションライディング (III) 原因 : 状態変更要求がウェブアプリケーション内で作成されたことをウェブアプリケーションが確認しない攻撃法 : GET 要求を作成する : SRC 属性を持つ画像タグが状態変更 URL を指定するこの URLはhttp リダイレクトにより難読化される可能性がある POST 要求を作成する : 攻撃者が IFRAME( ( またはポップアップウィンドウ ) を作成するこのフレームには HTML フォームが含まれるこのフォームは JavaScript で送信される Martin Johns, UH, FB Inf, SVS,

16 XSRF / セッションライディング (IV) 反射型 : 攻撃者は隠れた要求の生成元をホストするようなウェブサイトを作成しなければならないローカル / 蓄積型 : 悪意のある http 要求の生成元は攻撃を受けたウェブサイト上でホストされる例 : ユーザは海外の URL で画像を掲載を掲載できる Martin Johns, UH, FB Inf, SVS,

17 例 1: アプリケーションの破壊攻撃対象 : digg.com digg.com のフロントページは各々のストーリーが獲得する digg ( ( 投票 ) 数によって決定される XSRF の使用によりウェブページは標的とするブラウザに任意のURLを digg ( ( 投票 ) させることができたこのデモ用ページも自ら digg ( ( 投票 ) したものである Martin Johns, UH, FB Inf, SVS,

18 例 2: 経済的な損失を与える攻撃対象 : Netflix.com ユーザのレンタルキューに複数の動画を加えるユーザのレンタルキューのトップに動画を加えるユーザアカウント上の氏名と住所を変更するユーザアカウント上のメールアドレスとパスワードを変更する ( つまりユーザのアカウントを乗っ取る ) ユーザアカウントをキャンセルする ( 未確認 / 推測 ) Martin Johns, UH, FB Inf, SVS,

19 例 3: サーバーを獲得する攻撃対象 : Wordpress 2.02 Wordpress のテーマエディタは XSRF に対して脆弱だった Wordpress のテーマファイルは php-files にもできる XSRF によって攻撃者は任意の php コードを挿入するためにテーマファイルを修正を修正できた Martin Johns, UH, FB Inf, SVS,

20 例 4: イントラネットへの侵入攻撃対象 : ( ほとんどの ) イントラネットウェブサーバー外部の画像を過度に挿入し時間設定した JavaScript イベントを使うことによって悪意のあるウェブサイトは例えば下記のようなことができる : イントラネットをポートスキャンする既存のウェブサーバーやインストールされたアプリケーションにフィンガープリントする JavaScript マルウェア Intranet webserver Firewall Malicious site Martin Johns, UH, FB Inf, SVS,

21 XSRF / セッションライディング (IV) 全般的な問題 : セッションライディングに対する脆弱性はプログラミング上のミスによって起こるものではない完全に正確なコードでも攻撃対象になりうるセッションライディングの原因は http にある : 専用の認証証明がない状態変更 GET 要求 JavaScript セッションライディング対策とは実はプロトコルを改善することである Martin Johns, UH, FB Inf, SVS,

22 内容ウェブアプリケーションの認証 XSRF / セッションライディングサーバー側の対策クライアント側の保護結論 Martin Johns, UH, FB Inf, SVS,

23 誤解 POST 要求のみを承認するローカル攻撃を防ぐ海外のウェブページでは隠れた POST 要求をフレームで作成できるリファラチェック一部のユーザはリファラを禁止しているリファラのない要求の承認がの承認が必要であるリファラがなくても http 要求を選択的に作成できる技術がある : さらにリファラは Flash でなりすましができる Martin Johns, UH, FB Inf, SVS,

24 手法 1: 明示的な認証への移行 URL のリライト : セッショントークンは各 URL に含まれる注意 : プロキシログ / リファラを介したトークンの流出ローカル攻撃を防ぐことはできないアプリケーションにより作成されたすべての URL にはトークンが含まれるフォームによるセッショントークンセッショントークンは隠れたフォームフィールドを介して伝達される注意 : Back ボタンを壊す可能性がある明示的暗黙的メカニズムのメカニズムの組み合わせ例クッキーと URL のリライト使用されたフレームワークによるサポートが必要しかし依然 SID の流出は問題となるだろう Martin Johns, UH, FB Inf, SVS,

25 手法 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,

26 手法 2: マニュアルによる保護 (II) ローカル攻撃 : すべての海外コンテンツの海外コンテンツのミラーを作るのミラーを作る任意の URL を認めないユーザのサーバーからの画像のみを提供する注意 : 自分のコンピュータに攻撃者から任意のデータが保存されないようにすること Martin Johns, UH, FB Inf, SVS,

27 手法 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, Martin Johns, UH, FB Inf, SVS,

28 内容ウェブアプリケーションの認証 XSRF / セッションライディングサーバー側の対策クライアント側の保護結論 Martin Johns, UH, FB Inf, SVS,

29 RequestRodeo: 概念クライアント側のプロキシまたはブラウザ拡張 ( RequestRodeo ) 潜在的な不正要求の特定暗黙的な認証の排除ブラウザの改善 Martin Johns, UH, FB Inf, SVS,

30 疑わしい要求の特定要求の生成元によってその状態が決定する定義 : 許可された要求 http 要求は下記の場合のみ許可された要求許可された要求と分類される : あるウェブページとのやりとり ( 例 : リンクのクリックフォームの送信またはJavaScriptを経る ) によって作成された要求でありかつ初めのページのURLと要求されたページのURLが同一生成元ポリシーに準拠している要求の状態はブラウザによって決まる許可された要求のみが暗黙的な認証情報を持つことを許される Martin Johns, UH, FB Inf, SVS,

31 プロキシソリューション : http レスポンスの処理 URL にトークンを加える http レスポンス内の HTML コードが処理される http 要求を生成する可能性のある要素の特定 URL トークンによってその要素の標的となる URL が強化されるトークンはレスポンスの URL と共にテーブル内に保存されるこのようにプロキシは要求の生成元を決定できる信頼できるリファラ各々の http 要求に URL トークンがあるか否かがチェックされるトークンがある場合その元となる URL が検索される要求のドメインとその生成元が一致しない場合暗黙的な認証情報は排除される Martin Johns, UH, FB Inf, SVS,

32 暗黙的な認証の排除クッキー : クッキーフィールドはすべて無許可の要求無許可の要求から排除されるクッキーのドメイン値は考慮されなければならない http 認証 : ブラウザ拡張 : 無許可の要求に対する新たな認証の交渉のきっかけとなるプロキシ : 認証ヘッダを排除する前に URL にトークンを加えるクライアント側の SSL: 要求を送信する前に警告ウェブサイトウェブサイトを表示する気づきにくい : ユーザは画像タグによる隠れた攻撃に気づきにくい Martin Johns, UH, FB Inf, SVS,

33 暗黙的な認証の排除 (II) IP による認証無許可の要求が認められるのはその対象が世界規模である場合のみこのためリフレクションサーバーが導入されるリフレクションサーバーは DMZ でホストされている ( つまり内部ファイヤウォールの反対側にあることになる ) 無許可の要求を認める前にプロキシはリフレクションサーバーがその要求対象対象にアクセスできることを確認するチェックした IP のキャッシングによってパフォーマンス低下を最小限に抑えるこのようなリフレクションサーバーによって JavaScript マルウェアからも保護できる Martin Johns, UH, FB Inf, SVS,

34 暗黙的な認証の排除 : IP による認証 DMZ RequestRodeo HEAD? OK リフレクションサーバーイントラネットウェブサーバー内部ファイヤウォール外部ファイヤウォール悪意のあるサイト Martin Johns, UH, FB Inf, SVS,

35 暗黙的な認証の排除 : IP による認証! DMZ RequestRodeo? DENY HEAD リフレクションサーバーイントラネットウェブサーバー内部ファイヤウォール外部ファイヤウォール悪意のあるサイト Martin Johns, UH, FB Inf, SVS,

36 導入プロキシ [1]: Python に導入 Twisted フレームワークを使用でリリース予定ブラウザ拡張 : 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,

37 検討事項慎重なアプローチ : 接続を許可する暗黙的な認証を排除するのみとするパブリックリソースに対する要求は阻止しないサーバー側では微調整も効果的である制限 : ローカル攻撃からの保護はできないプロキシソリューション : NTLM / クライアント側の SSL は実施されない今後の課題 XSS 対策テクニックの追加 Martin Johns, UH, FB Inf, SVS,

38 内容ウェブアプリケーションの認証 XSRF / セッションライディングサーバー側の対策クライアント側の保護結論 Martin Johns, UH, FB Inf, SVS,

39 結論セッションライディングは問題である! 正しく見えるコードも攻撃を受ける可能性がある! プログラマ : できる限りノンスを使うユーザ : ログアウトする! Martin Johns, UH, FB Inf, SVS,

40 おわりにご清聴ありがとうございましたご質問ご意見はありませんか? Martin Johns, UH, FB Inf, SVS,

内容 ( 演習 1) 脆弱性の原理解説基礎知識脆弱性の発見方法演習 1: 意図しない命令の実行演習解説 2

内容 ( 演習 1) 脆弱性の原理解説基礎知識脆弱性の発見方法演習 1: 意図しない命令の実行演習解説 2 AppGoat を利用した集合教育補助資料 - クロスサイトリクエストフォージェリ編 - 独立行政法人情報処理推進機構 (IPA) 技術本部セキュリティセンター内容 ( 演習 1) 脆弱性の原理解説基礎知識脆弱性の発見方法演習 1: 意図しない命令の実行演習解説 2 クロスサイトリクエストフォージェリ (CSRF) とは? CSRF(Cross Site Request Forgeries)=