1.
Webプラットフォームのセキュリティ
セキュリティ・キャンプ全国大会2015
高レイヤートラック
The Web Platform Security

2.
背景
• プラットフォーム化するWeb
経済、医療、政治など様々な分野でWebは欠かせない存在に
国家の安全や人の生命に関わる情報のやり取りも
• 複雑化するWeb
ブラウザは6週間おきにメジャーバージョンアップ
ブラウザの機能追加により、昨日まで安全だったサイトが脆弱に
Webアプリの大規模化
開発者の努力や脆弱性診断だけで安全性を保つことは困難に

3.
背景
• Webをセキュアにする様々な技術が登場
クロスサイトスクリプティングを抑止する技術(CSP)
全ての通信をTLSで暗号化する技術(HSTS)
サーバ上のリソースの改ざんを検知する技術(SRI)
• しかしこれらが全ての問題を解決する訳ではない
その技術を導入することにより新たに生じる問題
仕様自体の考慮漏れ
Webの仕様はW3CやIETFなどで有識者が話し合って策定
参加する有識者が思い付かないことは仕様にも反映されない
過去の知見を確実にFeedbackするプロセスがない

4.
事前学習を振り返る
• HSTSを元に次のような問題点を考察した
その技術では解決できない問題
端末時刻の改ざんによるHSTSの強制失効
その技術の導入により新たに生じる問題
HSTSを用いたユーザー追跡 (HSTS Supercookies)
実装の誤りに起因する問題
指定を誤るとHTTPS非対応のサブドメインがアクセス不能に
仕様上既定されていない振る舞い
HSTSはWebSocket(ws:)にも適用されるのか？
CVE-2015-1244: Chrome でWebSocketにHSTSが適用されない
HSTSはプライバシーモードにも引き継ぐのか？
またその逆は？

5.
この講義の目的
• Webの開発者
ブラウザが備えるセキュリティ機能の効果とその代償を理解し、
機能を適切に利用できるようになる
• セキュリティ研究者
現在のブラウザが解決できていない問題を明確化し、それを
解決するための研究・提案ができるようになる
• バグハンター
ブラウザの機能の抜け穴を見つけて指摘できるようになる
そして報奨金をガッポリ稼ぐ！

6.
この講義の内容
• 次のテーマを元にディスカッションを行う
安全な通信を実現するためにブラウザがしていること
HTTPSを使えば本当に十分なのか考えてみよう
Same Origin Policy(SOP)とは何か
自分の言葉でSOPを説明してみよう
ブラウザがFetch APIに課した制限
APIの悪用を防ぐためにブラウザが禁止していることを学ぼう

7.
私の戦歴(参考)
• 次のような仕様不備を脆弱性として指摘してきた
ChromeのCSP違反レポートの送信先が<base>で制御できる
https://crbug.com/431218
ChromeのHTML ImportsがContent-Type指定を無視する
https://crbug.com/439877
ChromeのService Workersがiframe[sandbox]内で動作する
https://crbug.com/486308
FirefoxのWeb Notificationのアイコン表示がCSPを無視する
https://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0119.html
FirefoxのReferrer Policyが新しいタブで開いた際に効かない
https://lists.w3.org/Archives/Public/public-webappsec/2015Apr/0246.html
FirefoxのBroadcast Channel APIがプライバシーモードから
通常モードのウィンドウに通知される
https://bugzilla.mozilla.org/show_bug.cgi?id=1148032

8.
安全な通信を実現するために
ブラウザがしていること

9.
問題
• 次のようなユーザ認証を行うサイトがある
サーバとの通信にはどのような脅威があるか？
どのようにすれば安全な通信ができるか？
ログインのリクエスト
ユーザ名=abc & パスワード=123…
レスポンス
セッションID=Zyxwv…

10.
Phishing
• 偽のサイトに誘導し、そこでパスワードなどの機微
な情報を入力させる
利用者を騙すために、本物のサイトと似た画面のデザインや
URLが用いられることが多い
ログインのリクエスト
ユーザ名=abc & パスワード=123
よく見ると小文字のRN
送信内容が盗まれる

11.
ブラウザのPhishing対策
• 本物と見分けの付かない偽のURL
形の似た異なる文字によるURL偽装(Homographic Attack)
http://www.cs.technion.ac.il/~gabr/papers/homograph_full.pdf
例：小文字の“M”と“RN”を区別するのは難しい
国際化ドメイン名(IDN)によりリスクが増加
例：Latinの'c'(U+0063)とCyrillicの'c'(U+0441)は見た目が同じ
対策として、ブラウザはIDNの表示ルールを各自で定め、
ルールに違反するURLはPunycode(ピュニコード)で表示
例：http://ebаy.com  http://xn--eby-7cd.com
Punycodeで表示'a' はCyrillic

12.
ブラウザのPhishing対策
• 本物と見分けの付かない偽のURL(続き)
ChromeのIDN表示ルール(抜粋)
https://www.chromium.org/developers/design-documents/idn-in-google-chrome
URLに含まれる言語がユーザのロケールと一致すること
混在が許されない複数の文字集合がURLに存在しないこと
例えば、GreekとHiraganaが混在しないこと
Safariはホワイトリストで許可した文字集合のみIDNで表示
https://support.apple.com/kb/TA22996?locale=ja_JP&viewlocale=en_US
GreekやCyrillicを含むURLは全て禁止
ギリシャ語ドメインは表示できない
何故か絵文字はホワイトリストに含まれる

13.
ブラウザのPhishing対策
• URLの偽装を根本的に防ぐのは難しい
そもそもRFCに対策が難しいと書いてある
http://jprs.co.jp/idn/rfc5890j.txt
"紛らわしい文字の問題を統合的に解決する技術的対策が存在しないことは
注記に値する。この問題の影響範囲を限定する方法は様々なものが存在す
るが、この問題を解消することはおそらくできないだろう。"
EV SSL証明書は対策方法となりうる
アドレスバーに運営組織名を表示
https://cabforum.org/ev-faq/
しかし訓練されていない利用者には効果が無いという指摘も
http://www.usablesecurity.org/papers/jackson.pdf

14.
ブラウザのPhishing対策
• ITリテラシーの高くない利用者をどう守るか
そもそもURLの偽装が中途半端でも被害にあう人はいる
例: http://web.ib.mizuhobank.co.jp.ckw.●●●●.com
https://www.antiphishing.jp/news/alert/mizuho20150520.html
画面さえ本物と似ていれば人は騙される
• 最近の主流はURLのReputationに基づく検知
Chrome,Firefox,SafariはGoogleのSafe Browsing APIを利用
https://developers.google.com/safe-browsing/
IEは独自のSmartScreenフィルター機能を搭載
http://windows.microsoft.com/ja-jp/internet-explorer/products/ie-9/features/smartscreen-filter
それって検出精度は大丈夫？

15.
ブラウザのPhishing対策
Firefox 38
Safari 8
Chrome 43

16.
Pharming
• DNS情報の改ざんにより、偽サイトへ誘導させる
利用者は正規のURLを指定しても偽サイトに誘導される
URLを見ただけでは偽サイトだと判別できない
ログインのリクエスト
ユーザ名=abc & パスワード=123
正規サイトと同じURL
偽
DNSによる名前解決
偽のIPアドレス

17.
Pharming
• DNS情報はどこで改ざんされるのか
hostsの改ざん、DNSサーバやルータへの攻撃など
ドメイン名ハイジャック
• これも根本的な対策が難しい問題
HTTPSにすれば、ある程度は防ぐことができる
偽のサーバとの接続は証明書検証エラーになる
ドメイン名ハイジャックはHTTPSでも阻止できない
ドメイン名を所有していれば正規のサーバ証明書を入手できる

18.
Passive MITM
• 通信路のデータ盗聴し、様々な情報を取得する
主に平文で流れるデータが対象
広範囲に及ぶ攻撃を仕掛けることができる
盗聴 盗聴

19.
Passive MITM
• 誰が盗聴するのか
某国家の諜報機関(電気通信事業者と共謀)
企業の情報システム部門、Wi-Fi APの提供事業者など
• Pervasive Surveillance (Mass Surveillance)
膨大な計算能力を有する諜報機関による広範囲なMITM
海底ケーブルを盗聴して大量のデータを取得するなど
暗号化データを盗聴するための研究開発が行われていた事実も
https://en.wikipedia.org/wiki/Dual_EC_DRBG
実際に攻撃が行われていたことが2013年に明らかとなり、
通信路を暗号化する取り組みが加速し始めた
https://tools.ietf.org/html/rfc7258

20.
Passive MITM
• 平文で流れるデータは意外と多い
HTTP, FTP, SMTP, POP, Telnet…
HTTPSでも接続先のホスト名は平文で送信される
TCP/IPのレイヤは暗号化されていない
TLS拡張のSNI(Server Name Indication)も平文
• HTTPSを使えば防げるけれど
サーバのパフォーマンス低下
証明書を定期的に更新する手間
サイトに接続できない端末の発生
プリインストールされているルート証明書の有効期限切れ
古いTLS規格や弱い暗号スイートのみをサポートする端末

21.
ブラウザのPassive MITM対策
• あの手この手でHTTPSの利用を促進
Let's Encrypt
https://letsencrypt.org/howitworks/technology/
Opportunistic Security for HTTP (日和見暗号)
https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-02
Prefer Secure Origins For Powerful New Features
https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features
• Let's Encrypt
HTTPSを手軽に利用することを目的に作られた無料の認証局
2つのシェルコマンドで証明書の発行から運用まで
https://letsencrypt.readthedocs.org/en/latest/intro.html#about-the-let-s-encrypt-client

22.
ブラウザのPassive MITM対策
• Opportunistic Security for HTTP (日和見暗号)
サーバ認証をせずにTLSでhttp:80の通信を暗号化
オレオレ証明書ベースのTLSでも平文よりは安全
http/2の拡張仕様として仕様策定中
https://tools.ietf.org/html/draft-nottingham-http2-encryption-03
• Prefer Secure Origins For Powerful New Features
HTTPS接続時でなければ使えない機能を増やしていく
https://w3ctag.github.io/web-https/
https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
Service WorkersやPush APIには既に適用されている
http://www.w3.org/TR/service-workers/
http://www.w3.org/TR/push-api/

23.
Active MITM
• 盗聴に加え、通信路のデータの改ざんを行うMITM
標的のWebサーバになりすまし、HTTPSの通信も盗聴／改ざん
Passive MITMに比べて被害は局所的
https://example.jp/
盗聴・改ざん

24.
Active MITM
• 誰が攻撃を仕掛けるのか
シリア政府は国民のFacebookへの接続に対してMITMを実施
https://www.eff.org/ja/deeplinks/2011/05/syrian-man-middle-against-facebook
認証局への侵入により不正発行された証明書がイランでGmail
アカウントのハイジャック等に悪用された可能性
https://www.eff.org/ja/deeplinks/2011/09/post-mortem-iranian-diginotar-attack
航空機内Wi-FiサービスプロバイダのGogo
https://casecurity.org/2015/01/08/gogo-found-spoofing-google-ssl-certificates/
• HTTPSは有効な手段であるはずだが…
多くのユーザが証明書エラーの警告を無視する
Chrome 29では約70%の利用者が証明書エラーを無視
http://www.robreeder.com/pubs/sslExperimentCHI2014.pdf

25.
ブラウザのActive MITM対策
• 証明書エラーのクリックスルー率を下げる
クリックスルーの危険性を視覚的に訴えるUIに変更
Internet Explorer 6 Microsoft Edge
(2015年7月時点の開発版)

26.
ブラウザのActive MITM対策
• 証明書エラーのクリックスルー率を下げる(続き)
クリックスルーを行う際のユーザ操作を増やす
Safari 8 (1クリック) Firefox 39 (4クリック)

27.
ブラウザのActive MITM対策
• HSTSによるクリックスルーの禁止
2015年6月現在、全ての主要ブラウザがHSTSをサポート
Firefox 39 Chrome 43

28.
ブラウザのActive MITM対策
• Mixed Content
HTTPSで配信されたページからHTTPのリソースの取得を禁止
http://www.w3.org/TR/mixed-content/
JavaScriptやCSSが改ざんされると、HTTPSで保護されたページの
情報が盗まれたり改ざんされたりするため
リソースを2種類に分類して段階的に制限を適用
Blockable Content
JavaScript, CSS, plugins, XMLHttpRequest
Optionally Blockable Content
image, audio, video, prefetch

29.
ブラウザのActive MITM対策
• Mixed Content(続き)
Firefox 1(初回のみ警告を表示) Firefox 38(デフォルトでブロック)

30.
PKI Attacks (with Active MITM)
• 不正に発行されたサーバ証明書を悪用したMITM
認証局への侵入やオペレーションミス、暗号の危殆化などに
より不正な証明書が発行される
不正に発行された証明書は正規の証明書と区別できない
従来のPKIの仕組みでは対処できない問題
https://example.jp/ 証明書を不正発行
HTTPS接続HTTPS接続

31.
PKI Attacks (with Active MITM)
• 過去に起きた証明書の不正発行(の一部)
2008年 RapidSSL MD5署名に対するハッシュ衝突攻撃
2008年 Thawte ドメイン名の所有確認手順の不備
2008年 StartCom Webサイトに対する攻撃
2008年 Comodo ドメイン名の所有確認手順の不備
2011年 Comodo ドメイン名の所有確認手順の不備
2011年 DigiNotar 認証局(登録局)に対する侵入
2012年 TURKTRUST 中間CA証明書の誤発行
2013年 ANSSI 中間CA証明書の誤発行
2015年 Comodo ドメイン名の所有確認手順の不備

32.
ブラウザのPKI Attack対策
• 2011年以降、様々な手法が提案された
主流は公開鍵ピンニング
これまでに多くの問題を検知してきた実績
http://googleonlinesecurity.blogspot.jp/2011/08/update-on-attempted-man-in-middle.html
最近何かと話題のCT(Certificate Transparency)
ChromeはCT非対応のEV証明書の運営組織をURLに表示しない
http://www.symantec.com/ja/jp/page.jsp?id=ssl-certificate-transparency
Chrome 43 (運営組織は非表示) Firefox 39 (運営組織を表示)

33.
ブラウザのPKI Attack対策
• 公開鍵ピンニングとは
正規の証明書の情報をあらかじめブラウザに記憶(ピン留め)
以降、ピン留めした証明書以外によるHTTPSの通信を禁止
• 公開鍵ピンニングにも様々な課題がある
利用者がルート証明書ストアに追加した証明書は許可される
不正な証明書をインストールさせられた場合は対処できない
実際にLenovoのSuperfishは防ぐことができなかった
http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-
breaks-https-connections/
ピン留めした証明書情報の更新忘れによるセルフDoS
新しい証明書を運用した際にピン留めした情報との不一致が発生
HPKPでは救済措置としてバックアップピンの登録を強制

34.
ブラウザのPKI Attack対策
• CTとは
発行した証明書のデータを認証局がログサーバに記録
ログサーバは誰でも閲覧可能であるため、証明書の不正発行が
あれば(きっと)誰かが気付くことができる
• CTにも様々な問題がある
ログサーバの情報を集計することにより様々な情報がばれる
各認証局の売上や世界シェア
設立予定の会社名や非公開の製品名を含む非公開のドメイン情報
ログサーバのアクセス履歴を見れば、いつどこからどのドメイン
にアクセスされたかが分かる(OCSPで指摘された問題)
他にも説明しきれないくらい様々な問題がある(詳細は以下)
http://ozuma.sakura.ne.jp/sumida/attach/01_cert_t-view.pdf
http://www.slideshare.net/kenjiurushima/certificate-transparencyssl

35.
ここまでのまとめ
• 安全な通信を実現するためにブラウザは様々な対策
を講じてきた
「HTTPSを使えば安全」ではない
• 他にも様々な脅威とその対策が行われている
サーバ秘密鍵の漏洩とその対策(Perfect Forward Secrecy)
TLSのレコード分断(Cookie Cutter Attack)
ブラウザの自発的なフォールバック(SSL 3.0 Fallback)
and more!!

36.
ここまでのまとめ
• 技術的に未解決の問題はまだまだある
Phishingの根絶
ドメイン名ハイジャック
ルート証明書ストアに対する不正な証明書のインストール
• 新しい機能の導入により生じる様々な問題もある
公開鍵ピンニングの運用ミスによるセルフDoS
CTによる非公開ドメイン情報やアクセス数などの流出

37.
Same Origin Policy(SOP)とは何か

38.
問題
• ブラウザにはSame Origin Policy(SOP)と呼ばれる
コンテンツ分離の概念がある
SOPとは何か？
Origin(生成元)が用いられる理由は何故か？
SOPの適用例にはどのようなものがあるか？

39.
Origin
• URLの構成要素のうち、scheme + host + port を
組み合わせたもの(RFC6454)
https://tools.ietf.org/html/rfc6454
http://example.jpと同じOrigin
http://example.jp:80/
http://example.jp/path/file
http://example.jpと異なるOrigin
http://example.jp:8080/
http://www.example. jp/
https://example. jp:80/
http://example.com/

40.
Same Origin Policy (SOP)
• WebコンテンツをOriginに基づいて分離する仕組み
同じOriginのコンテンツは信頼できるという前提に基づいた
セキュリティモデル
URLやパス単位に信頼の境界を定義する試みも過去にはあったが、
ブラウザの実装や運用が煩雑になりうまくいかなかった
https://tools.ietf.org/html/rfc6454#section-8
何故ホスト名(host)のみでコンテンツを分離しないのか？
同じhostでもhttp:とhttps:で信頼のレベルを分けたいから
https://tools.ietf.org/html/rfc6454#section-3.2
SOPは全てのユースケースを満たすものではない
例：異なる学生のページが同一Originに存在する大学のサイト
http://example.edu/~student/

41.
SOPの適用例①
• 異なるOriginのオブジェクトは操作できない
次の場合、サブウィンドウのlocationの参照は禁止
var subwin = window.open('http://other.example.jp/');
var subloc = subwin.location; // 禁止

42.
SOPの適用例①
• 例外的に操作できるオブジェクトもある
次の場合、サブウィンドウのlocationの変更は許可
var subwin = window.open('http://other.example.jp/');
subwin.location = ‘http://www.ipa.or.jp’; // 許可

43.
SOPの適用例②
• 異なるOriginに対するリクエスト
次のリクエストは異なるOriginでも許可
<script src="http://other.example.jp/foo.js">
<form action="http://other.example.jp/" method="post">
new WebSocket('ws://other.example.jp/');
次のリクエストはサーバがCORS*1対応の場合に限り許可
var req = new XMLHttpRequest();
req.open(‘GET’, ‘http://other.example.jp/’);
req.send();
@font-face { font-family: 'external';
src: url('http://other.example.jp/font.woff'); }
*1 CORS：https://developer.mozilla.org/ja/docs/HTTP_access_control

44.
SOPが適用されない機能
• 全てのコンテンツがSOPで分離される訳ではない
リモートのオリジンからローカルファイルの参照は禁止
例: <iframe src="file:///etc/passwd">
Cookieはdomainとpathに基づくアクセス制御
HTTP認証はrealmに基づくアクセス制御
Service Workersは同一のSecure Originのみ利用可能
https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features
ReferrerはHTTPSのOriginがHTTPで通信を行う際のみ規制

45.
SOPと擬似URL
• SOPが必ずしもOriginに基づく訳ではない
window.openやiframeで開かれたabout:blankやjavascript: URL
は親のドキュメント(ナビゲーション元)のOriginを継承
blob: URLはその元となるBlobを作成したOriginを継承
data: URLのOriginはブラウザによって大きく異なる(次頁)
親のオリジンを継承

46.
data: URLのOrigin
a [href]
window.open
iframe 30x Redirect Refresh
アドレスバー
手入力
お気に入り
Internet
Explorer
11
(遷移不可) (遷移不可) (遷移不可) (遷移不可) (遷移不可) (遷移不可)
Microsoft
Edge
20.10240
(遷移不可)
独自の
Origin
(遷移不可) (遷移不可) (遷移不可) (遷移不可)
Firefox
39
ナビゲーション
元のOrigin
ナビゲーション
元のOrigin
独自の
Origin
独自の
Origin
独自の
Origin
ナビゲーション
対象Windowの
Origin
Safari
8
独自の
Origin
独自の
Origin
独自の
Origin
(ただしバグ有り)
独自の
Origin
独自の
Origin
独自の
Origin
Chrome
43
独自の
Origin
独自の
Origin
(遷移不可)
独自の
Origin
独自の
Origin
独自の
Origin

47.
SOPの実装には一貫性が無い
• コンテンツの分離するかどうかの基準が曖昧
SOPは単一のルールではなく「Origin単位で色々と分離しないとね」
という漠然としたもの
機能ごとに分離の仕方を決めるのでたまに誤る(SOPバイパスの脆弱性)
擬似URLのOriginもURLごとに決められる
iframe[sandbox]やiframe[srcdoc]などの登場で複雑化
Originの定義もブラウザにより異なる
ブラウザの脆弱性の温床
• 従来の仕様を見直そうとする動きもある
Origin Cookie: SOPに基づく新しいCookie
http://tools.ietf.org/html/draft-west-origin-cookies-01
• 機能の振る舞いを個別に調べることが重要
全てSOPで保護されていると思っていると痛い目に遭う

48.
ブラウザがFetch APIに課した制限

49.
Fetch API
• HTTPによる非同期通信を提供する低水準のAPI
指定したURLに対するHTTPリクエスト送信／レスポンス受信
HTTPリクエストのメソッド、ヘッダ、ボディを指定可能
HTTPレスポンスのヘッダ、ボディを読み取り可能
2015年7月現在、ChromeとFirefoxで利用可能
http://example.jp/
HTTPリクエスト
fetch(‘http://example.jp/path‘)
HTTPレスポンス

50.
Fetch APIの使い方
fetch('http://api.example.jp/path',{
method:'POST',
headers: {
'Content-Type':'text/plain'
},
body:'Hello World!'
}).then(function(res){
console.log(res.headers.get('Content-Type'));
}).catch(function(err){
console.error(err);
});

51.
ブラウザは何を制限すべきか
fetch('http://api.example.jp/path',{
method:'POST',
headers: {
'Content-Type':'text/plain'
},
body:'Hello World!'
}).then(function(res){
console.log(res.headers.get('Content-Type'));
}).catch(function(err){
console.error(err);
});
常にボディを指定して良い?
どんな文字を含めても良い?
どんなヘッダの値を読んでも良い?
どんな情報が含まれても良い?
どんなURLを指定しても良い?
どんなヘッダを指定しても良い?
どんなメソッドを指定しても良い?

52.
この講義のまとめ
• Webには様々な脅威があり、ブラウザベンダは
個々に対策を講じてきた
しかしWebの仕様は複雑かつ曖昧であり、その対策方法にも
一貫性が無かったり抜け漏れが生じたりする
対策する技術を加えたことで新たに生じる問題
後方互換性などの理由により技術的に未解決の問題
• 現状を理解し、それぞれの立場で今やれることを
やってWebを安全にしていくしかない
今ある技術を正しく理解して使う
今の技術では未解決の問題を解決するために提案をする

53.
謝辞
本資料は下記の方々にレビューして頂きました。
この場を借りて御礼を申し上げます。
• 株式会社セキュアスカイ・テクノロジー
はせがわようすけ様
• 富士ゼロックス株式会社
漆嶌賢二様
• トレンドマイクロ株式会社
木村仁美様