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