Same Origin Policy

Webセキュリティ
(7)Same Origin Policy
by はなわ
今日のテーマ
• Same Origin Policy（同一生成元ポリシー）
• ＝クロスドメイン制約
• Webセキュリティの考え方の基礎
• 理解を深める
• 発展的話題の前提知識
• 復習
• 再考：XSSの危険性
• Same Origin Policyとは
• 間接攻撃とSame Origin Policy
• まとめ
はじめに
• 今日の内容は、過去の講習と深い関連
• Javascript
• XHR
• セキュリティ
• XSS、CSRF
XHR
• XMLHttpRequest
• JavascriptでHTTP通信
• Ajaxの裏側の通信
XMLHttpRequest
①HTTPリクエスト
②HTTPレスポンス
サイト閲覧者
新規ID:
登録
XMLHttpRequest
①HTTPリクエスト
②HTTPレスポンス
サイト閲覧者
新規ID:
admin
登録
③IDを入力
(XHR)
XMLHttpRequest
①HTTPリクエスト
②HTTPレスポンス
サイト閲覧者
新規ID:
admin
ID adminは取得できません
登録
③IDを入力
(XHR)
④既存データだった。
エラーメッセージ。
間接攻撃
• 攻撃者が用意した攻撃ページに、被害者
がアクセスして初めて成り立つような攻
撃。狙いは被害者の権限の悪用。
XSS
• 間接攻撃の一種
• 動的にWebページを生成するアプリケーショ
ンのセキュリティ上の不備を意図的に利用
し、狭義にはサイト間を横断して悪意のある
スクリプトを混入させること。広義にはスク
リプトに限らず、任意の要素を混入させるこ
と。（出典：Wikipedia）
XSS
①HTTPリクエスト
http:/.../?id=<script src="ht..">
②HTTPレスポンス
サイト閲覧者
<script src="http://">さんの
プロフィール
③Javascriptが
実行される
CSRF
• 間接攻撃の一種
• Webサイトにスクリプトや自動転送
(HTTPリダイレクト)を仕込むことによっ
て、閲覧者に意図せず別のWebサイト上で
何らかの操作(掲示板への書き込みなど)を
行なわせる攻撃手法。（出典：e-Words）
CSRF図解
• 認証機構のあるサイト
• 被害者がログインしている前提
• 例としてWebメールサービスを考える
ログイン中
サイト閲覧者
Webサーバ
通常のリクエスト
To:
Cc:
Internet
本文:
メール送信
①「新規メール作成」
②新規メール入力フォーム
③「メール送信」ボタン
⑤「送信しました」ページ
サイト閲覧者
to=hanawa@
example.com&
body=hello
④メール送信
CSRFのリクエスト
攻撃者のWebサーバ
とっておきの情報があります
ここをクリック
Internet
①攻撃者が仕掛けた
URLにアクセス
③メール送信
②JavaScriptで
「メール送信」の
リクエストを再現
④「送信しました」ページ
サイト閲覧者
to=hanawa@
example.com&
body=hello
• 復習
• 再考：XSSの危険性
• Same Origin Policyとは
• 間接攻撃とSame Origin Policy
• まとめ
XSSの危険性
• SNSサービスにXSSがあれば、攻撃者
が好きなJSを仕込める
そんなに危険？
• SNSサービスにXSSがあれば、攻撃者
が好きなJSを仕込める
• プロバイダのユーザ用HPに、攻撃者が
好きなJSを仕込める
➡この2つの違いとは？
JS設置とXSSの違い
• ブラウザクラッシャーとか置かれたら?
JS設置とXSSの違い
• ブラウザクラッシャーとか置かれたら?
➡危険度はどこに設置しても同じ。
XSSの怖さとは別。
JS設置とXSSの違い
• 有名サイトなら被害者が増える？
• プロバイダにヤバいものを置いたらすぐ
捕まるはず？
JS設置とXSSの違い
• 有名サイトなら被害者が増える？
• プロバイダにヤバいものを置いたらすぐ
捕まるはず？
➡そうかもしれないが、本質的ではない
JS設置とXSSの違い
• XSSの場合
• 脆弱性のあるページ自体を操作可能
• 同じホスト内の情報にアクセス可能
JS設置とXSSの違い
• Javascriptが「どこのドメインで」実
行されるのか
• XSS：そのページ自身や同一ホスト
のページを取得・操作される
• JS設置：他ドメインにアクセス不可
「JSがどのURL
にあるか」が重要
• 復習
• 再考：XSSの危険性
• Same Origin Policyとは
• 間接攻撃とSame Origin Policy
• まとめ
Same Origin Policy
• Same Origin Policyとは
• 直訳：同じ起源ポリシー
• JSで別URLのDOMを操作できる範囲
• 同一ホストのみに限定
Same Origin Policy
• JavaScriptに関する制約
• XMLHttpRequest、iframe
Same Origin Policy
• 例：http://store.hnw.jp/のJS
• アクセス可能：store.hnw.jp
• アクセス不可：news.hnw.jp
• アクセス不可：www.yahoo.com
なぜこんな制約が？
• 他のドメインにアクセスできたとする
1. 銀行サイトにログインした状態で
2. 悪意のあるサイトにアクセス
3. JSで銀行サイトのコンテンツ取得
➡悪意あるJSから口座内容が丸見え
必要性まとめ
• Javascriptから任意ドメインにアクセ
スできたとしたら
• 気づかずに任意サイトにアクセス
• ブラウザが信用できない状態に近い
必要性まとめ
• あるホストの安全性を保証するには？
• 同一ホスト内のJSは安全
• 他ドメインのJSはDOM操作できない
• 同一ホストのみ信用するという解
＝Same Origin Policy
同一ホストのJS
は信用するよ
• 復習
• 再考：XSSの危険性
• Same Origin Policyとは
• 間接攻撃とSame Origin Policy
• まとめ
CSRFへの対策
• 推測不可能なトークンの埋め込み
• 次のリクエストでトークンを照合
CSRFへの対策
• CSRF対策が有効な理由
• 第三者がコンテンツ（＝トークン）
を盗み見ることができない
CSRFと
Same Origin Policy
• 「他ドメインのJSからはDOM操作でき
ない」という前提
➡トークン埋め込みが対策として有効
XSSと
Same Origin Policy
• XSSがあると任意のJSを差し込まれる
• 「同一ホスト内のJSは安全」という
前提が崩れている
➡XSSの怖さの一面
Same Origin Policyが
崩れている例
• http://ne.jp/
hanawa/以下に100万
人が使うECサイトができたよ！
• http://ne.jp/ crack/にJS設置
➡CSRF対策は破られる
➡iframeでDOM操作される
同一ホストが信用でき
ない場合、
脆弱性があるのと同じ
• 復習
• 再考：XSSの危険性
• Same Origin Policyとは
• 間接攻撃とSame Origin Policy
• まとめ
まとめ
• Same Origin Policy
• 「同一ホストだけ信用するポリシー」
• 同一ホストのみ別URLのDOM操作が可能
• 崩れると間接攻撃されるのと同等の脅威
まとめ
• 心がけ
• 同一ホストのJSが信用できる環境を維持
ご清聴
ありがとう
ございました