同一オリジンポリシーとCORS

Transcript

1. 徳丸本 輪読会 受動的攻撃と同一オリジンポリシー   CORS   かろてん@carotene
2. 受動的攻撃   と   同一オリジンポリシー
3. あたまのわるいまとめ •  いろんなこうげきほうほうがあるね   –  またないでこっちからいくやつ   –  わなをしかけてまつやつ   •  どうすればこうげきをふせげるんだろうね   –  サーバ、ブラウザどっちもたいさくがいる   •  サーバがわはつぎのしょうで   •  ブラウザがわは「できることをせいげん」   –  どういつオリジンポリシー
4. 能動的攻撃と受動的攻撃 •  能動的攻撃  
5. 能動的攻撃と受動的攻撃 •  受動的攻撃（罠系）   – 単純な受動的攻撃   – 正規サイトを悪用する受動的攻撃   – サイトをまたがった受動的攻撃  
6. 能動的攻撃と受動的攻撃 •  単純な受動的攻撃   – 罠を「自分が用意したサイト」に仕掛ける  
7. 能動的攻撃と受動的攻撃 •  正規サイトを悪用する受動的攻撃   – 罠を「正規サイト」に仕掛ける  
8. 能動的攻撃と受動的攻撃 •  正規サイトを悪用する受動的攻撃  
9. 能動的攻撃と受動的攻撃 •  正規サイトを悪用する受動的攻撃のメリット   – 罠サイトに誘導しなくて良い  →  楽   – 被害が拡大する可能性が高い  →  楽   – 利用者の情報を得られる  →  いろいろできそう  
10. 能動的攻撃と受動的攻撃 •  正規サイトへの罠の仕込み方   – コンテンツ書き換え   •  FTPパスワード入手   •  Webサーバの脆弱性をつく   •  SQLインジェクション   •  クロスサイトスクリプティング脆弱性  
11. 能動的攻撃と受動的攻撃 •  事例   – Gumblar   •  ドライバダウンロードによってマルウェアを感染させ、   :pアカウントを送信させるなどした  
12. 能動的攻撃と受動的攻撃 •  サイトをまたがった受動的攻撃
13. 能動的攻撃と受動的攻撃 •  サイトをまたがった受動的攻撃 •  正規サイトにログインしている利用者の   アカウントを悪用した攻撃   •  正規サイトへリクエストを飛ばす際、   セッションクッキーを送るので、ログインしていれば   ログインした状態で攻撃される  
14. 能動的攻撃と受動的攻撃 •  サイトをまたがった受動的攻撃 •  例   –  CSRF   –  XSS   –  HTTPヘッダ・インジェクション　等  
15. 攻撃に対しては、   サーバとブラウザ両方で   対策しなくてはならない
16. ブラウザは   どのように受動的攻撃を防ぐか
17. ブラウザでできることを   「制限」すれば良い
18. ブラウザの対策 •  サンドボックスという考え方   •  同一オリジンポリシー   – JavaScriptによるiframeアクセスの実験   – Iframeを悪用した罠の可能性  
19. サンドボックスという考え方 •  「プログラムができることを制限する」   という考え方   – JavaScript,  Javaアプレット,  Flash  Playerで   用いられている  
20. サンドボックスという考え方 •  例えば、JavaScriptのサンドボックス   – ローカルファイルへのアクセス禁止   – プリンタなどの資源の利用禁止   （画面表示はOK）   – ネットワークアクセスの制限   （同一オリジンポリシー）
21. 同一オリジンポリシー •  サンドボックスに用意された制限の１つ   – クライアントスクリプトからサイトをまたがったアク セスを禁止する  
22. 同一オリジンポリシー
23. 同一オリジンポリシー OK OK OK
24. 同一オリジンポリシー
25. 同一オリジンポリシー OK NG
26. 同一オリジンポリシー •  クライアントスクリプトからサイトをまたがった アクセスを禁止する場合がある  
27. 同一オリジンポリシー •  なぜ必要なのか、Iframeを使った例で考える   – Iframeの外側から内側の値を取得する例   外側
28. 同一オリジンポリシー •  iframe  –  中   この値を取得する
29. 同一オリジンポリシー •  iframe  -­‐  外   内側の値を取得する 内側のURL
30. 同一オリジンポリシー •  内側のオリジン  =  外側のオリジンの場合   外側 外：hMps://security-­‐client-­‐carotene.c9users.io 中：hMps://security-­‐client-­‐carotene.c9users.io
31. 同一オリジンポリシー •  内側のオリジン  =  外側のオリジンの場合   – 中の値を受け取れる  
32. 同一オリジンポリシー •  内側のオリジン  ≠  外側のオリジンの場合   外側 外：hMps://security-­‐trap-­‐carotene.c9users.io 中：hMps://security-­‐client-­‐carotene.c9users.io
33. 同一オリジンポリシー •  内側のオリジン ≠  外側のオリジンの場合   – 中の値を受け取れない  
34. 同一オリジンポリシー •  もし、取得できてしまったら   – 罠ページから、正規サイトの機密情報を得られ、   送信されてしまうかも   外側 外：罠ページ 中：正規サイトの機密情報  
35. 同一オリジンである条件
36. 同一オリジンである条件 •  ３条件   –  URLのホストが一致している   –  スキーム（プロトコル）が一致している   –  ポート番号が一致している   •  Cookieはスキームとポート関係ないから緩め   •  ただし、JavaScirptはディレクトリ関係ない  
37. 同一オリジンである条件 •  同一オリジンポリシーによる保護対象は   iframeだけじゃない   •  例えばXMLHMpRequestとか   •  このあとでてくるよ  
38. 同一オリジンでも防げないやつ •  XSS（クロスサイトスクリプティング攻撃）   – Iframeの内側にJavaScriptを送り込んで実行する  
39. [コラム]第三者のJavaScriptを許可 •  サイト運営者が第三者を信頼して実行する   –  アクセス解析、バナー広告、ブログパーツなど   •  実際には以下のような問題が発生している   –  提供元が意図的に個人情報を収集する   –  提供元サーバに脆弱性があり、JSが差し替えられる   –  提供元のJSに脆弱性があり、別のスクリプトが実行される    
40. [コラム]第三者のJavaScriptを許可 •  提供元が信頼できるかどうかを調査すること が大事  
41. [コラム]第三者のJavaScriptを許可 •  閲覧者が第三者を信頼して埋め込む JavaScript   – Firefoxのグリースモンキーアドオン   – 自分でスクリプトを自由に作成でき、また公開さ れているスクリプトを使うことができる   – 通常のJSよりも権限がつよいらしく、   怪しいスクリプトをinstallしないことが大事  
42. JavaScript以外の   クロスドメインアクセス
43. ほかのクロスドメインアクセス •  <frame>,  <iframe>   •  <img>   •  <script>   •  <link  type=‘text/stylesheet’>   •  <form  ac^on=’’>  
44. ほかのクロスドメインアクセス •  <frame>,  <iframe>   – クロスドメインアクセスOK   – ただしJavaScriptからクロスドメインのドキュメント にアクセスするのはだめ  
45. ほかのクロスドメインアクセス •  <img>   – srcはクロスドメインの指定OK（そりゃそうじゃ）   – 画像リクエストする時cookieもおくれる   – 罠サイトに「認証の必要な画像」を表示すること ができる（？）   – JavaScriptからimgにアクセスする時（canvas等）は   クロスドメインだとアクセスできない  
46. ほかのクロスドメインアクセス •  <script>   – srcはクロスドメインの指定OK（そりゃそうじゃ：図）   – ただし、特定の状況下において、   JSのソースコードが変化する事があるので注意  
47. ほかのクロスドメインアクセス
48. ほかのクロスドメインアクセス •  <css>   –  クロスドメイン読み込み可能（よく使う）   •  Link   •  @import   •  addImport(JSのメソッド）   –  ただし、過去にCSSXSSという脆弱性がIEに存在した  
49. ほかのクロスドメインアクセス •  CSSXSS   – Webブラウザが、CSSのつもりでHTMLなど異なる ファイルを呼んでしまう脆弱性を利用した攻撃   – 昔のIEはファイルの中に「  {  」が入っていればCSS と認識してしまうらしい  
50. ほかのクロスドメインアクセス •  <form  ac^on=“**”>   – **はクロスドメインでも動作する   – これを利用したのがCSRF（4.5節）  
51. CORS
52. あたまのわるいまとめ •  おりじんまたいでしゅとくすることもできるよ   – しんぷるなリクエスト   – しんぷるじゃないリクエスト   – にんしょうじょうほうをおくるリクエスト   •  どれもサーバがわのせっていがいるよ
53. CORSとは •  Cross-­‐Origin  Resource  Sharing   •  越えられない壁（Originの壁）をこえる仕様   •  なんでもかんでも超えられるようにすると   危ないから仕様にしてる  
54. シンプルなリクエストでCORS
55. シンプルなリクエストでCORS
56. シンプルなリクエストでCORS   •  クライアントはこんなかんじ  
57. シンプルなリクエストでCORS   •  サーバはこんなかんじ  
58. シンプルなリクエストでCORS   •  結果：失敗   リクエストされたリソースには、Access-­‐Control-­‐Allow-­‐Originヘッダがないって。   あと、Origin  ‘hMps://~’からのアクセスは許可されてないってさ。  
59. アクセスを許可する   •  特定のOriginからのCORSアクセスを許可する  
60. シンプルなリクエストでCORS   •  結果：成功  
61. シンプルなリクエスト  #とは   •  以下の３つの条件がある   – メソッドの条件   – XMLHMpRequestオブジェクトで設定できるヘッダ の条件   – Content−Typeヘッダの条件  
62. シンプルなリクエスト  #とは   •  以下の３つの条件がある   – メソッドの条件   •  GET  or  HEAD  or  POST   – XMLHMpRequestのヘッダの条件   – Content−Typeヘッダの条件  
63. シンプルなリクエスト  #とは   •  以下の３つの条件がある   –  メソッドの条件   –  XMLHMpRequestのヘッダの条件   •  Accept   •  Accept-­‐Language   •  Content-­‐Language   •  Content-­‐Type   –  Content−Typeヘッダの条件  
64. シンプルなリクエスト  #とは   •  以下の３つの条件がある   – メソッドの条件   – XMLHMpRequestのヘッダの条件   – Content−Typeヘッダの条件   •  applica^on/x-­‐www-­‐form-­‐urlencoded   •  mul^part/form-­‐data   •  text/plain  
65. シンプルなリクエスト  #とは •  これらの条件は   – HTMLフォームによる送信と比べて   過度にリスクが増加しない範囲で   条件が指定されている  
66. プリフライトリクエストでCORS
67. プリフライトリクエスト   •  シンプルなリクエストの条件を満たさない場合、   pre-­‐flight  requestというHTTPリエクストを送信   •  リクエストを投げる前   「このリクエスト、本当に送っていいっすか ね？」ってサーバに聞くためのリクエスト
68. プリフライトリクエスト   •  クライアント側ソース 「シンプルなリクエスト」の条件を   満たしていない  
69. プリフライトリクエスト   •  サーバ側ソース
70. プリフライトリクエスト   •  結果
71. プリフライトリクエスト   XmlHMpRequestの前に、   プリフライトリクエストを送っている   APIは左の２つに対して   「いっすよ」と応答する必要がある  
72. プリフライトリクエスト   これが「いっすよ」  
73. プリフライトリクエスト   •  結果 Postが送られた  
74. プリフライトリクエスト   •  結果 サーバはリクエストを送ることに対し て「いっすよ」とはいった     レスポンスを返すとはいってない  
75. プリフライトリクエスト   POSTがきたときはこれで返す  
76. プリフライトリクエスト   •  結果
77. いっすか？   いっすよ   じゃおくりますね   かえすわ  
78. 認証情報を含むリクエストでCORS
79. 認証情報を含むリクエスト •  クロスオリジンに対するリクエストの場合、   以下のリクエストヘッダは送信されない – HTTP認証   – Cookie   （等、認証に用いられるもの）  
80. 認証情報を含むリクエスト •  でも、送りたい時がある  
81. 認証情報を含むリクエスト •  withCreden^alsを使って、cookieを送ろう  
82. withCreden^alsを使わないとき   •  クライアントはこんなかんじ  
83. withCreden^alsを使わないとき   •  サーバはこんなかんじ  
84. withCreden^alsを使わないとき •  何度問い合わせても
85. withCreden^alsを使わないとき •  ブラウザのcookieを見てみると PHP_SESSID的なやつがない  
86. withCreden^alsを使わないとき   •  レスポンスヘッダを見てみると   Set-­‐cookieがある  
87. withCreden^alsを使わないとき   •  つまり   – サーバ側からはcookieをsetするように言ってる   – でもブラウザがそうしないようにしている  
88. withCreden^alsを使うとき   •  クライアントに１行ついか  
89. withCreden^alsを使うとき   •  失敗   リクエストがcreden^lasモードのときは、   レスポンスヘッダのAccess-­‐Control-­‐Allow-­‐Creden^alsをtrueにしろっておこられた
90. withCreden^alsを使うとき   •  サーバに１行ついか  
91. withCreden^alsを使わないとき •  やったね！
92. まとめ •  クッキーなど認証用のヘッダを伴う   クロスオリジンアクセスは、   以下の両方を満たす必要がある     –  XMLHMpRequestオブジェクトの   withCreden^alsプロパティをtrueに   –  レスポンスヘッダに   Access-­‐Control-­‐Allow-­‐Creden^als:  true