Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

3568f852fd62f33f29b6321452ec09e6?s=47 carotene4035
July 29, 2018
500

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

3568f852fd62f33f29b6321452ec09e6?s=128

carotene4035

July 29, 2018
Tweet

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. 同一オリジンポリシー •  サンドボックスに用意された制限の1つ   – クライアントスクリプトからサイトをまたがったアク セスを禁止する  

  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. 同一オリジンである条件 •  3条件   –  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. シンプルなリクエスト  #とは   •  以下の3つの条件がある   – メソッドの条件   – XMLHMpRequestオブジェクトで設定できるヘッダ の条件

      – Content−Typeヘッダの条件  
  62. シンプルなリクエスト  #とは   •  以下の3つの条件がある   – メソッドの条件   •  GET

     or  HEAD  or  POST   – XMLHMpRequestのヘッダの条件   – Content−Typeヘッダの条件  
  63. シンプルなリクエスト  #とは   •  以下の3つの条件がある   –  メソッドの条件   – 

    XMLHMpRequestのヘッダの条件   •  Accept   •  Accept-­‐Language   •  Content-­‐Language   •  Content-­‐Type   –  Content−Typeヘッダの条件  
  64. シンプルなリクエスト  #とは   •  以下の3つの条件がある   – メソッドの条件   – 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は左の2つに対して   「いっすよ」と応答する必要がある  

  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を使うとき   •  クライアントに1行ついか  

  89. withCreden^alsを使うとき   •  失敗   リクエストがcreden^lasモードのときは、   レスポンスヘッダのAccess-­‐Control-­‐Allow-­‐Creden^alsをtrueにしろっておこられた

  90. withCreden^alsを使うとき   •  サーバに1行ついか  

  91. withCreden^alsを使わないとき •  やったね!

  92. まとめ •  クッキーなど認証用のヘッダを伴う   クロスオリジンアクセスは、   以下の両方を満たす必要がある     – 

    XMLHMpRequestオブジェクトの   withCreden^alsプロパティをtrueに   –  レスポンスヘッダに   Access-­‐Control-­‐Allow-­‐Creden^als:  true