Slide 1
Slide 1 text
ブラウザの脆弱性とそのインパクト
Masato Kinugawa, Cure53
Muneaki Nishimura, Recruit Technologies Co., Ltd.
Slide 2
Slide 2 text
この講義の概要
Webの安全性は、サーバ側の堅牢な実装に加え、ブラウザのセキュリティモデル
の上に成り立っています。ブラウザに脆弱性があると、あるサイトに書き込んだ
データが他のサイトに漏えいするなどの様々な問題が生じます。
ブラウザの脆弱性の多くは、実装のちょっとしたおかしな動作から見つかります。
しかし、ブラウザの利用者の多くは、その動作が脆弱性であり、攻撃に悪用され
うることに気付きません。脆弱性を見つけるには、そうした動作を悪用する方法
を見つけ出すための「発想力」が必要となります。
本講座では、そうした攻撃者の発想力を身に着けるためのポイントを学びます。
Slide 3
Slide 3 text
自己紹介
Slide 4
Slide 4 text
Masato Kinugawa
Cure53
2016年より独Cure53で脆弱性診断。それ以前は脆弱性報
告の報奨金で生活していた。好きな脆弱性はXSS。Web
アプリケーションやブラウザのXSSに関連する脆弱性を
中心に多数発見。OWASP AppSec APAC 2014、CODE
BLUE(第2回、第3回)、AVTOKYO 2015で講演あり。2013
年よりセキュリティ・キャンプに関わる。
Slide 5
Slide 5 text
西村 宗晃
株式会社リクルートテクノロジーズ
サイバーセキュリティエンジニアリング部
シニアセキュリティエンジニア
国内携帯電話メーカーでのセキュリティコンサルタント
などを経て2016年より現職。リクルートグループ全社の
脆弱性検査や修正支援に携わる。趣味はブラウザの脆弱
性を探すこと。著書にブラウザハック（監訳）。主な講
演歴にCODE BLUE 2015、AVTOKYO 2016、PacSec 2016。
2014年よりセキュリティ・キャンプ全国大会講師
Slide 6
Slide 6 text
脆弱性探しの主なプロセス
Slide 7
Slide 7 text
1. 対象を決める
2. 対象を深く知る
3. 対象のおかしな動作を探す
4. その悪用シナリオを考える
Slide 8
Slide 8 text
1. 対象を決める
2. 対象を深く知る
3. 対象のおかしな動作を探す
4. その悪用シナリオを考える
Slide 9
Slide 9 text
対象を決める
Slide 10
Slide 10 text
どのモジュールの脆弱性を探すか
• ブラウザは様々なモジュールで構成されている
• 数あるモジュールの中からどれを叩くかを決めることが最初の一歩
• 対象を決める基準は心がときめくかどうか
• その後のモチベーションに影響するので極めて重要
Nishimura
Slide 11
Slide 11 text
ブラウザの構成要素は
• 様々な観点で、心ときめくモジュールを見つけ出す
• ドキュメントパーサ
• スクリプト処理機能
• プロトコル
• マルチメディアサポート
• 内包しているミドルウェア
• 各種API
• UI部品
• ブラウズを便利にするための機能
• セキュリティ機能
• 他
Nishimura
Slide 12
Slide 12 text
演習1. ブラウザのモジュールを洗い出す（10分）
• 以下の観点でブラウザのモジュールを列挙してみよう（何を調べてもOK）
• ドキュメントパーサ
• スクリプト処理機能
• プロトコル
• マルチメディアサポート
• 内包しているミドルウェア
• 各種API
• UI部品
• ブラウズを便利にするための機能
• セキュリティ機能
• 他
Nishimura
Slide 13
Slide 13 text
演習1の回答例
• 例えばこんなモジュール
• ドキュメントパーサ（HTML, XML, SVG, MathML, XUL）
• スクリプト処理機能（JavaScript, VBScript, asm.js, WebAssembly）
• プロトコル（HTTP, FTP, WebSocket, HTTP/2, QUIC, DNS, mDNS, WebRTC）
• マルチメディアサポート（JPG, GIF, PNG, WebM, Ogg, AAC, MP3, MP4, FLAC）
• 内包しているミドルウェア（Skia, ffmpeg, ICU, NSS, OpenVR, libpng, sqlite）
• 各種API（Fetch API, Push API, Extension API, Fullscreen API, Web Speech API）
• UI部品（Location Bar, History, Bookmark, Context Menu）
• ブラウズを便利にするための機能（Chrome Extension, Reading View, Secret Mode）
• セキュリティ機能（SOP, XSS Filter, CSP, SRI, TLS, Mixed Content, HSTS, HPKP, CT）
• 他
Nishimura
Slide 14
Slide 14 text
たとえばこんな方法で対象を決める
Slide 15
Slide 15 text
新しい機能を探す
• 新しく搭載された機能は、まだ誰も脆弱性を探していない可能性が高い
• 開発者向けのアルファ版を狙う
• Firefox Nightly
• Chrome Dev, Canary
• Safari Technology Preview
• EdgeはWindows 10の先行リリース版が狙い目（@shhnjk談）
• 新しい機能を知る手段
• Release Notes
• 各ブラウザのFeature Status
• 各ブラウザベンダーの技術ブログや開発者向けカンファレンスの動画
• バグ管理システム（RSSで取得・ただしS/N比はあまり良くない）
Nishimura
Slide 16
Slide 16 text
Firefox developer release notes
https://developer.mozilla.org/en-US/Firefox/Releases
Nishimura
Slide 17
Slide 17 text
Linkタグでpreloadを指定できるのか！
面白そうだ！調べてみよう！
Nishimura
Slide 18
Slide 18 text
Firefox Platform Status
https://platform-status.mozilla.org/
Nishimura
Slide 19
Slide 19 text
Chrome Platform Status
https://www.chromestatus.com/features
Nishimura
Slide 20
Slide 20 text
Mozilla Hacks – the Web developer blog
https://hacks.mozilla.org/
Nishimura
Slide 21
Slide 21 text
Chromium Blog
https://blog.chromium.org/
Nishimura
Slide 22
Slide 22 text
Chrome Dev Summit 2016 - YouTube
https://www.youtube.com/playlist?list=PLNYkxOF6rcIBTs2KPy1E6tIYaWoFcG3uj
Nishimura
Slide 23
Slide 23 text
Google for Mobile Tokyo 2015
https://www.youtube.com/watch?v=VHN2wJWi0WE
Nishimura
Slide 24
Slide 24 text
古いイケてない機能を探す
• こんな古い機能はイケてない
• 標準化されておらず仕様が不明確なもの
• 流行らなかったもの
• プラグイン全般（Flash/Adobe Reader）
• まともなドキュメントすらないことも多い
• 古い機能を知る手段
• Release Notes
• セキュリティ研究者の投稿や発表
Kinugawa
Slide 25
Slide 25 text
イケてない例：showModalDialog
Kinugawa
Slide 26
Slide 26 text
ダイアログ使用中他のウインドウは操作不可
（UIに関連する問題が起きそう？）
dialogArguments/returnValueプロパティを使った
独自のウインドウ間のデータのやりとり
（ここにオリジンの制限はあるのか？）
イケてない例：showModalDialog
Kinugawa
Slide 27
Slide 27 text
Firefox サイト互換性情報
https://www.fxsitecompat.com/ja/docs/
Kinugawa
Slide 28
Slide 28 text
Mario Heiderich: "My Sweet Innocence Exposed - Eleven Reasons why we will all miss you, 'e'"
https://www.youtube.com/watch?v=aeevfVXPIqo
Kinugawa
Slide 29
Slide 29 text
列挙する・列挙されたものから探す
• 1つテーマを決めて列挙してみる
• HTTPリクエストを送信できるJavaScriptのAPI（sendBeacon, Fetch, Worker...）
• ブラウザネイティブのダイアログが出現するAPI（alert, confirm, getUserMedia...）
• MIMEタイプ（text/javascript, image/svg+xml, application/octet-stream...）
• 既に列挙されたものをみていくのも有効
• windowオブジェクト
• HTTPLeaks
• HTML5 Security Cheatsheet
• 列挙のメリット
• 一度にテストできる
• 対象の相対的な面白さに気付ける
Kinugawa
Slide 30
Slide 30 text
例：windowオブジェクトを見る
Kinugawa
Slide 31
Slide 31 text
HTTPLeaks
https://github.com/cure53/HTTPLeaks/blob/master/leak.html
Kinugawa
Slide 32
Slide 32 text
HTML5 Security Cheatsheet
https://html5sec.org/
Kinugawa
Slide 33
Slide 33 text
IEではCSSからスクリプトを実行
できるのか！CSSでどのくらい攻
撃できるか見てみるかな！
Kinugawa
Slide 34
Slide 34 text
コミット履歴から更なる気付きを得る
• Gitのコミット履歴から面白そうな機能追加を探す
• モバイルOSの新規機能対応（3D Touch, Spotlight, Universal Links）
• 実装中の機能（Web App Manifest, GeckoView）
• コミット履歴から新たな着眼点を得る
• プログラマが脆弱性を作りやすそうな記述の存在（正規表現, 文字列への変数埋め込み）
• 扱いの難しいサードパーティライブラリの利用（SQLite, Alamofire）
Nishimura
Slide 35
Slide 35 text
GitHub - mozilla-mobile/firefox-ios: Firefox for iOS
https://github.com/mozilla-mobile/firefox-ios
Nishimura
Slide 36
Slide 36 text
Bug 1289687 - Support Internationalized Domain Names
https://github.com/mozilla-mobile/firefox-ios/commit/78be54586c9e027465d8e0da28bb42595d4ebe32
Nishimura
Slide 37
Slide 37 text
演習2. コミット履歴から脆弱性を探す（10分）
• このコミットにはどんな脆弱性があるでしょう
• https://goo.gl/xo6MMV
• このコードには現在のブラウザが備えるべき「ある攻撃」への対策が入っていません
• IDNや国際化ドメインという単語を検索してみよう
Nishimura
Slide 38
Slide 38 text
演習2の回答
• ホモグラフ攻撃の対策が入っていない
• 本物のサイトとよく似たURLで偽サイトに誘導するフィッシング
• アルファベットの「a」とよく似たキリル文字「 а 」U+0430などが使われる
• 以下は「a」がU+0430
• 以下は「:」がU+0589で、「/」がU+2215
Nishimura
Slide 39
Slide 39 text
演習2の回答
• ちなみにこの脆弱性を報告した結果
• IDN（国際化ドメイン）が当面は無効化されることに・・・
Nishimura
Slide 40
Slide 40 text
コミット履歴から新たな着眼点を得る
データの保存にSQLiteを使っている！
どこかでSQL Injectionが起きないかな！
Swiftでは文字列リテラルに変数を埋め込めるのか！
HTMLを生成してるところでXSSが起きないかな！
Nishimura
Slide 41
Slide 41 text
SELECTやINSERTという単語でコード全体をgrep
外部から渡されたパラメータがSQLクエリに
展開されている個所がないか探す（このコードの例は安全）
Nishimura
Slide 42
Slide 42 text
Bug 1317580 - Add additional deeplink support for FxA
https://github.com/mozilla-mobile/firefox-ios/pull/2249/files
Nishimura
Slide 43
Slide 43 text
演習3. コミット履歴から脆弱性を探す（20分）
• このコミットにはどんな脆弱性があるでしょう
• https://github.com/mozilla-mobile/firefox-ios/pull/2249/files
• 文字列リテラルに変数を埋め込んでいる個所を探してみよう
• 発生する脆弱性が分かった人は、どのような経路で攻撃できるかを調べてみよう
Nishimura
Slide 44
Slide 44 text
演習3の回答
• Firefox Accountsのページ上でXSSできる
• webView.evaluateJavaScriptの第1引数（変数script）に
任意の文字列を指定できることが原因
• iOSのDeep Linkを使って、以下のURLをSafariで開けば攻撃成立
firefox://?fxa=signin&email=test@example.jp');
$('.email').val('JAVASCRIPT_INJECTED!!
Nishimura
Slide 45
Slide 45 text
Webアプリの脆弱性検査から気付きを得る
• ブラウザがこう動けばアプリが脆弱になるのに、と気付くことがある
• URL文字列を取得するAPIが特定の記号文字列を返すなら…
• 信頼できない文字列を扱う一連の関数の動作が1つでもおかしければ…
• 任意のhostヘッダを犠牲者に送信させることができたなら…
• CSPが正しく機能しなければ…
• 攻撃のシナリオが明確なら、対象を定めやすい
• ➡ location.* プロパティが返す値
• ➡ 利用されている関数の詳細な動作
• ➡ ヘッダを送信できる関数の制限が適切か
• ➡ CSPの実装が正確か
Kinugawa
Slide 46
Slide 46 text
Kinugawaの実例：CSPの実装不備
CSPの設定の安全性を検査してほしいと仕事で依頼された際、
FirefoxのCSPがsandbox化されたiframeのsrcdoc属性で機能しないことを発見。
余談：報告したところ、StatusがDUPLICATEに。一体誰が報告を…？
Kinugawa
Slide 47
Slide 47 text
Bug 1073952 - CSP can be bypassed with
https://bugzilla.mozilla.org/show_bug.cgi?id=1073952
Kinugawa
Slide 48
Slide 48 text
過去に学ぶ
• 過去の修正された脆弱性の情報を見る
• セキュリティアドバイザリ
• 時間が経って開示されたバグ票（bugzilla.mozilla.org, bugs.chromium.org）
• 報告者のブログやカンファレンスの発表資料
• 過去のバグからはたくさんの有益な情報が得られる
• どこに脆弱性があったのか
• どんな脆弱性があるのか
• どうすれば脆弱性が発生しうるのか
• 報告者はどのように脆弱性を発見したか
Kinugawa
Slide 49
Slide 49 text
Mozilla Foundation Security Advisories
https://www.mozilla.org/en-US/security/advisories/
Kinugawa
Slide 50
Slide 50 text
Chrome Releases: Stable Channel Update for Desktop
https://chromereleases.googleblog.com/2017/07/stable-channel-update-for-desktop.html
Kinugawa
Slide 51
Slide 51 text
Kinugawaがやったこと
• はせがわようすけさんの資料を熟読（http://utf-8.jp）
• さまざまなブラウザに起因するXSS手法があることを知る
• Content Sniffing
• 文字コード
• 使える文字種に縛りがあるときのXSS
• mXSS
• それぞれを自分の手を動かして再現させた
• さらに、深く調べる余地がありそうな部分を自分で調べ直した
• 全ての文字コードの動作を一から調べてみよう
Kinugawa
Slide 52
Slide 52 text
各ブラウザが解釈可能なcharsetの比較表
https://l0.cm/encodings/table/
Kinugawa
Slide 53
Slide 53 text
文字コードを調べてみつかったもの(一例)
• CVE-2011-3058
• https://bugs.chromium.org/p/chromium/issues/detail?id=109574
• EUC-JPのページで、0x8EE3というバイトシーケンスでバックスラッシュ文字が出現。文字
列リテラル中でユーザ入力を受け付けている場合、本来バックスラッシュが出現する0x5C
をエスケープしていてもXSSが起こってしまう。
• CVE-2013-5612
• https://www.mozilla.org/en-US/security/advisories/mfsa2013-106/
• POSTリクエストを経由して文字コードが指定されていないページにアクセスすると、直
前の文字コードを使用してページが表示されてしまう。ISO-2022-JPなどの特殊なバイト
表現を持つ文字コードを利用することでHTML構造を破壊しXSSが起こってしまう。
Kinugawa
Slide 54
Slide 54 text
他にもあるよ
• about: URLをひたすら解析する
• ブラウザのバイナリに埋め込まれた隠しページを探し出す
• about:neterror?e=nssBadCert&d=Hello%20Guys!
Hello Guys!
Nishimura
Slide 55
Slide 55 text
他にもあるよ
• 利用しているサードパーティライブラリの脆弱性を探す
Nishimura
Slide 56
Slide 56 text
サードパーティライブラリの脆弱性
• Mozilla NSS（Network Security Module）
• FirefoxのTLSや暗号処理で使われているライブラリ
• ドイツの研究者Hanno Böck氏が、暗号処理で使われるbig_numの剰余演算の脆弱性を
AFLによるFuzzingで発見。このFuzzingでは、NSSとOpenSSLの演算結果を比較し、異なる
演算結果が出たときにアサーションする手法が用いられた
https://blog.fuzzing-project.org/37-Mozilla-NSS-Wrong-calculation-results-in-mp_div-and-mp_exptmod.html
• SQLite
• Beijing Chaitin Techの研究者が、SQLiteにおけるメモリ破壊の脆弱性を発見。この脆弱性
はSafariのWeb SQL Databaseに影響することを用い、Pwn2OwnにてSafariの攻略に成功
https://www.blackhat.com/docs/us-17/wednesday/us-17-Feng-Many-Birds-One-Stone-Exploiting-A-Single-
SQLite-Vulnerability-Across-Multiple-Software.pdf
Nishimura
Slide 57
Slide 57 text
1. 対象を決める
2. 対象を深く知る
3. 対象のおかしな動作を探す
4. その悪用シナリオを考える
Slide 58
Slide 58 text
対象を深く知る
• 目的や使用用途は？
• どのように使うのか？
• InputとOutputは？
• 対象にはどのような制限事項があるのか？
• ブラウザ上でどんなことが起きてはいけないのか？
• 対象が提供する機能は悪用できないか？
• ブラウザのセキュリティ機構を迂回できないか？
• これまで安全と見られていたWebサイトに対する新たな攻撃手段として利用できないか？
Nishimura
Slide 59
Slide 59 text
深く知るためにどうするか
• 実際に使って動かす
• テストプログラムのコミットなどを参考にプログラムを書いてみる
• 仕様を読む
• コードを読む
• コードにログを仕込んでビルドし、詳しい振る舞いを確かめる
• バイナリを読む
Nishimura
Slide 60
Slide 60 text
Kinugawa
edgehtml.dllのバイナリ
C:¥Windows¥System32¥edgehtml.dll
Slide 61
Slide 61 text
edgehtml.dllのバイナリ
C:¥Windows¥System32¥edgehtml.dll
XSSフィルターの正規表現
Kinugawa
Slide 62
Slide 62 text
演習4. XSSフィルターの反応原因を探る（20分）
• Internet Explorer のXSSフィルターは次のURLになぜか反応します
• https://goo.gl/WSEkgq
• C:¥Windows¥System32¥mshtml.dll のバイナリから正規表現をみつけ、
どの部分に反応したかを推測しよう
• 正規表現は"implementation"と検索するとみつかります
• また、本来ならどのような攻撃文字列を阻止するものか考え、その文字列を
使って以下のページでアラートを実行してみよう
• https://goo.gl/Vmkebc
Kinugawa
Slide 63
Slide 63 text
演習4の回答: どの部分に反応したか
Kinugawa
{[¥"¥'][ ]*(([^a-z0-
9~_:¥'¥" ])|((i|(¥¥u0069))(n|(¥¥u006[Ee])))).+?{¥(}.*?{¥)}}
"instagram(インスタグラム)"
Slide 64
Slide 64 text
演習4の回答: 本来遮断したいもの
Kinugawa
{[¥"¥'][ ]*(([^a-z0-9~_:¥'¥" ])|((i|(¥¥u0069))(n|(¥¥u006[Ee])))).+?{¥(}.*?{¥)}}
"alert" in window //true
new Date() instanceof Date //true
var q=""in alert(1)//"
var q=""instanceof alert(1)//"
補足： in と instanceof 演算子について
Slide 65
Slide 65 text
フィルターを深く調べてみつけたもの
• フィルターのバイパス
• 以前までのバイパス可能なフィルタールール：
Kinugawa
var q=""i¥u006E alert(1)//";
{[¥"¥'][ ]*(([^a-z0-9~_:¥'¥" ])|(in)).+?{¥(}.*?{¥)}}
バイパスの例：
(※Windows 8.1以下のIE11ではまだ古いルールが使われています。)
Slide 66
Slide 66 text
フィルターを深く調べてみつけたもの
• フィルターの反応を利用して逆にXSSをする手法
• https://www.slideshare.net/masatokinugawa/xxn-ja
Kinugawa
var q=":
";
javascript: を無関係の文脈にマッチさせて攻撃する例：
Slide 67
Slide 67 text
演習5. Fetch APIの仕様を調べる（20分）
• Fetch APIにはどのようなセキュリティ上の制限が施されているか
• 仕様書（WHATWGのFetch Standard）を読んで洗い出してみよう
https://fetch.spec.whatwg.org/
• これは2015年のセキュリティ・キャンプの演習問題の再掲です
Nishimura
Slide 68
Slide 68 text
演習5のヒント
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);
});
Nishimura
Slide 69
Slide 69 text
演習5のヒント
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を指定しても良い?
どんなヘッダを指定しても良い?
どんなメソッドを指定しても良い?
Nishimura
Slide 70
Slide 70 text
演習5の回答例
• 通信先ホスト
• about, blob, data, file, ftp, filesystem, http(s)以外のスキームはエラーを返す
• 現在のオリジンによって指定できないスキームもある（例：http: file:のFetchは禁止）
• HSTS, HPKP, CSP, Mixed Content Blockに従うこと
• SOPおよびCORSに準拠すること
• 接続禁止ポート（Port Banning）に従うこと
• 通信メソッド
• CONNECT, TRACE, TRACKメソッドは指定禁止
Nishimura
Slide 71
Slide 71 text
演習5の回答例
• リクエストヘッダ
• 以下のヘッダは指定禁止
• Accept-Charset, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request-
Method, Connection, Content-Length, Cookie, Cookie2, Date, DNT, Expect, Host, Keep-Alive,
Origin, Referer, TE, Trailer, Transfer-Encoding, Upgrade, Via, Proxy-*, Sec-*
• ヘッダ名に0x00, 0x0a, 0x0dを含めてはいけない
• その他のヘッダはCORSに準拠すること
• リクエストボディ
• GET, HEADリクエストにリクエストボディを付けてはいけない
Nishimura
Slide 72
Slide 72 text
演習5の回答例
• レスポンスヘッダ
• 以下のヘッダは読み取り禁止
• Set-Cookie, Set-Cookie2
• その他のヘッダはCORSに準拠すること
• エラーオブジェクト
• 接続先のリダイレクト後のURLが異なるオリジンである場合、
返却されるオブジェクトのURLにパスやクエリ文字列を含んではいけない
• 接続先が異なるオリジンである場合、取得したデータを含めてはならない
Nishimura
Slide 73
Slide 73 text
仕様どおりに動くかを調べるだけで脆弱性が見つかる
• 2015年5月：Firefox 39
• リクエストにHostやCookieヘッダを付加できる（$3000）
https://bugzilla.mozilla.org/show_bug.cgi?id=1162411
• 2015年5月：Firefox 40 Nightly
• リダイレクト後のクロスオリジンURLがレスポンスボディに含まれる（$3000）
https://bugzilla.mozilla.org/show_bug.cgi?id=1162018
• しかも歴史は繰り返す
• 次の2ページで紹介するのは2017年に他の人が見つけたMicrosoft Edgeの脆弱性
Nishimura
Slide 74
Slide 74 text
リクエストにHostやCookieヘッダを付加できる
http://seclists.org/fulldisclosure/2017/Mar/37
Nishimura
Slide 75
Slide 75 text
リダイレクト後のクロスオリジンURLがレスポンスボディに含まれる
http://mov.sx/2017/04/16/microsoft-edge-leaks-url.html
Nishimura
Slide 76
Slide 76 text
1. 対象を決める
2. 対象を深く知る
3. 対象のおかしな動作を探す
4. その悪用シナリオを考える
Slide 77
Slide 77 text
対象のおかしな動作を探す
• わずかな「いつもと違う」に目を光らせる
• 設定通りの動きをしない
• アドレスバーが更新されない
• クラッシュ、フリーズ
• 文字化け
• HTMLタグが効いている
• ブラウザによって動作が異なる
• 一見ただのバグでも、詳しくみると悪用可能な動作かもしれない
Kinugawa
Slide 78
Slide 78 text
おかしな動作は案外わかりにくい
• 問題と気付けるかどうかが重要
• 例えば CVE-2012-3695
• http://masatokinugawa.l0.cm/2012/08/safari-location.href.html
• location.href に含まれるBasic認証情報部分がデコードして返される
• 実際の利用場面を考えれば、まずい動作であることがわかりますか？
https://aaa%2F@example.com/
https://aaa/@example.com/
Kinugawa
Slide 79
Slide 79 text
おかしな動作を引き出す方法
• 様々な要素と対象を組み合わせてみる
• プロトコルスキーム (http:, https:, ftp:, data:, resource:, about:, chrome-extension:)
• リクエストメソッド (GET, POST, HEAD, OPTIONS, TRACE)
• 表示される場所 (iframe, object/embedタグ, svgのforeignobject, Reading View)
• Fetchする方法 (imgタグ, video/audioタグ, WorkerのimportScripts, ServiceWorker内)
• ナビゲーションの方法 (Locationヘッダ, meta refresh, window.open, ブラウザバック)
• 異常な入力 (重複した値, 長すぎる文字列, 空の値, 大きすぎる数値, マイナスの数値)
• あらかじめ1つのくくりで列挙した要素があると便利
Kinugawa
Slide 80
Slide 80 text
Kinugawaの実例
• CVE-2015-4483
• https://bugzilla.mozilla.org/show_bug.cgi?id=1148732
• feed: を先頭に付けたhttpsのURLにPOSTリクエストを送信すると、POSTを受けたページで
Mixed Content Blockerが機能しない
• 最初の気付きはアドレスバーから feed: が消えないことだった
Kinugawa
Slide 81
Slide 81 text
先週修正されたFirefoxの脆弱性
• CVE-2017-7788
• https://bugzilla.mozilla.org/show_bug.cgi?id=1073952
• のsrcdoc属性にscript要素を記述すると、CSPのscript-src指定に関わらず
インラインスクリプトが実行される。ただしスクリプトが動作するオリジンはsandbox
originであり、親フレームのCookieなどは盗めない
• CVE-2017-7789
• https://bugzilla.mozilla.org/show_bug.cgi?id=1074642
• HTTPレスポンスにHSTSヘッダが複数付いているとHSTSが効かない。サイトの構成で
OriginとEdgeサーバの両方でHSTSヘッダを付けた場合、HSTSが効かない。
HTTP ヘッダインジェクションでHSTSを無効化する悪用方法も考えられる
Nishimura
Slide 82
Slide 82 text
図に表すとこんなかんじ
CSP sandbox
iframe srcdoc
HSTS 重複した値
POST feed:
Mixed Content Blocker CVE-2015-4483
CVE-2017-7788
CVE-2017-7789
×
× ×
➡
➡
➡
×
×
×
考慮されていない組み合わせからおかしな動作が起き、脆弱性が引き起こされる
Kinugawa
Slide 83
Slide 83 text
仕様とおかしな動作
• 仕様そのものが攻撃の可能性を十分に想定できていないことがある
• 例えば@font-face のunicode-range
http://masatokinugawa.l0.cm/2015/10/css-based-attack-abusing-unicode-range.html
• 仕様そのものを改善する議論に発展することも
• 場合によっては機能を廃止する判断が下されるかもしれない
• E4X
• ApplicationCache
Kinugawa
Slide 84
Slide 84 text
演習6. CSPバイパスXSSチャレンジ（20分）
• 以下のページでアラートを実行してみよう
• https://goo.gl/pVqnrw
• CSPのnonceに対応したChromeかFirefoxを使ってください
• アラートを実行できた人：このようなバイパス手法に対処するために新しい
制限が提案されています。どのような方法がありうるか考えてみよう
Kinugawa
Slide 85
Slide 85 text
演習6の回答例
• 正規に使われているスクリプトタグのnonceを利用
• Dangling Markup Injectionにより、追加したスクリプトタグの属性中にnonceを含ませる
Kinugawa
Slide 86
Slide 86 text
提案されている新たな仕様
• CSP Lv3でDangling Markup Injectionに対処する記述が追加されている
• https://www.w3.org/TR/CSP/#matching-elements
• "
Slide 87
Slide 87 text
1. 対象を決める
2. 対象を深く知る
3. 対象のおかしな動作を探す
4. その悪用シナリオを考える
Slide 88
Slide 88 text
見つけた動作を悪用可能なシナリオを考える
• 現実のWebアプリでどう悪用できるかを示す
• その振る舞いのせいで、本来は安全であるはずのサイトが安全でなくなることを示す
• 実例をもとに、現行のWebのセキュリティモデルが毀損することを示す
• 現実に悪用できない場合でも、最大限に悪用可能なシナリオを考えて示す
• もしサイトの実装が○○なら、この動作を悪用して△△できる
• 仮定が身近にありそうな例であれば、危険性を理解してもらえる
Nishimura
Slide 89
Slide 89 text
演習7. おかしな動作の悪用方法を考える（20分）
• 以下のFirefox拡張（WebExtension）には、ある脆弱性があります
• https://github.com/nishimunea/securitycamp2017
• この脆弱性を最大限に悪用するシナリオを考えてください
• シナリオには仮定を置いて構いません
例：○○するサイトで、ユーザが△△した場合に、□□が起きる
Nishimura
Slide 90
Slide 90 text
演習7の回答例
• ページのタイトル展開部分にHTML Injectionがあるのは皆さんも分かったはず
• ただし、この拡張にはCSPがガチガチに効いているので、XSSには至りません
https://github.com/nishimunea/securitycamp2017/blob/master/manifest.json#L6
• HTML Injectionできる程度なら深刻度は低
• 2年経っても直してもらえないでしょう
https://bugzilla.mozilla.org/show_bug.cgi?id=1224425
• そこで、現実的な悪用シナリオを示す必要が出てきます
Nishimura
Slide 91
Slide 91 text
演習7の回答例
• 拡張のJavaScriptに着目すると、%TITLE%、%CONTENT%、という順に
テンプレートへ変数が展開されていることがわかります
Nishimura
Slide 92
Slide 92 text
演習7の回答例
• タイトル（%TITLE%）にform要素を埋め込むことで、XSSを使わずとも、
ページの内容（%CONTENT%）を外部へ盗み出すことができます
• 以下のform要素をエンコードして、ページのtitle要素に埋め込みます
%CONTENT%
Nishimura
Slide 93
Slide 93 text
演習7の回答例
• ユーザが指定した文字列をtitleに展開するサイトは数多くあります
• 身近な例では、Google検索の結果画面のタイトルが悪用できます
• ただし、検索結果のページ内容を盗み出してもあまりインパクトはありません
Nishimura
Slide 94
Slide 94 text
演習7の回答例
• 攻撃者がページのタイトル（title要素）に任意の文字列を指定でき、かつ、
そこに盗まれてはいけない情報が含まれているサイトを探します
• 皆さんは分かりますか？
Nishimura
Slide 95
Slide 95 text
演習7の回答例
• たとえばGmailを見てみましょう
Nishimura
Slide 96
Slide 96 text
演習7の回答例
• 受信メールを開くと、メールのタイトルがページのtitle要素に表示されます
Nishimura
Slide 97
Slide 97 text
演習7の回答例
• この画面で拡張を選択すると、HTML Injectionが成立し、ボタンが出現します
Nishimura
Slide 98
Slide 98 text
演習7の回答例
• ボタンを押すと、ページのDOM（%CONTENT%）が外部に送信されます
Nishimura
Slide 99
Slide 99 text
演習7の回答例
• 送られたデータには、受信トレイにある他のメールの本文まで含まれています
Nishimura
Slide 100
Slide 100 text
演習7の回答例
• 被害者がGmailで悪意のあるメールを受信し、それを拡張で開いた場合、
受信トレイに表示された全てのメールが攻撃者に盗まれる恐れがある
• ここまでやれば、深刻度が中程度まで上がる可能性がある
Nishimura
Slide 101
Slide 101 text
さいごに
Slide 102
Slide 102 text
さいごに
• 2人が実際に見つけた脆弱性を例に、脆弱性を探すための発想法を学びました
• 日頃の調査・研究の積み重ねや地味な作業の繰り返し（素振り）が、あるとき、
脆弱性を見つける際の閃きに結び付いているというのがポイントです
• 脆弱性の探し方は十人十色です
• 本日の講義では4つのメソッドを紹介しましたが、これに従う必要はありません
• 自分の心がときめく対象を見つけ、自分が面白いと思えるやり方で脆弱性を見つけること。
これが長い間に渡って脆弱性を見つけ続けるための秘訣なのかもしれません
Nishimura
Slide 103
Slide 103 text
おわり