XSSの運用の話ぷれぜんたー：やぎはしゅ

CSP Lv.2の話ぷれぜんたー：やぎはしゅ

CSP #とは• Content Security Policyの略称。 - [MDN CSP] [検索]

• XSSなどの影響を緩和する機構。 - 根源は絶てずとも実行はさせない。

• リソースの読み込み元を制限する。 - インラインコードやevalも制限可能。

• 適切に用いればXSSに対する切り札になる。 - 未対応ブラウザでもSOPになるだけ！

流行ってるの？

• Twitter(report-only) - mobile.twitter.comでは普通に使ってる(IEのせい？)

• ChromeのExtensionではだいぶ前から必須。 - これはChromeが前提なので等しく適用できる。

• Firefox OSのアプリケーションでも必須。 - こちらもFirefox前提なので容易に適用可。

サポート状況

• だいたい全部のブラウザで使える。 • ただし、ここでいう"ブラウザ"にInternet Explorerは含まれないものとする。

• IE10以降でsandboxディレクティブのみ対応。

使い方

• HTTPレスポンスヘッダにContent-Security-Policy: {$policy}という感じでCSPポリシーを追加。

• これだけで対応ブラウザは勝手にやってくれる。 • metaタグを使ってもできるけど、使う場合はX-XSS-Protection: 1; mode=blockを一緒に吐いた方がいいかも。(まぁでもIEは実質対応してないし意味ないか)

インラインスクリプト

• HTMLソース中に出現する<script>alert(1)</script>みたいなベタ書きのソースコードや、

• HTMLソース中に出現する<button onclick="alert(1)">hoge</button>みたいな属性値で設定するイベントハンドラ。

eval(とそれ相当)なもの

• window.eval() • window.setTimeout() • window.setInterval() • Function() • この4つ

ポリシーの書き方

default-src 'self' - 外部オリジンの全てのリソースを拒否 !script-src http://xss.moe - スクリプトはhttp://xss.moe以外からは読み込まない !style-src 'unsafe-inline' - インラインCSSを許可 !default-src 'self'; style-src 'self' 'unsafe-inline' - 一番上のルールに加えて、インラインCSSは許可

本題

• そんなCSPを発展させたCSP Lv.2の最終草案が2014年7月3日に公開されたよー！ - http://www.w3.org/TR/CSP2/

• このイケてる機構をみんなに知ってもらいたい！ • 気になるものをピックアップしますー。

Path matching

• Pathマッチングに対応。 • 従来のオリジンのみでのマッチングではなく、Pathでのマッチングも有効に。

• 例えばhttp://web.sfc.keio.ac.jp/~t11913yy/以下のjsファイルしか読み込ませたくないとか。

CSP 1.0 script-src http://xss.moe OK script-src http://xss.moe/js/ NG script-src http://xss.moe/js/file.js NG

CSP 2.0 script-src http://xss.moe OK script-src http://xss.moe/js/ OK script-src http://xss.moe/js/file.js OK

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

Path matchingの注意点

• リダイレクトが絡む場合は少し特殊に。 • パス情報のリークを防ぐために、リソースの読み込み元でリダイレクトしている場合はパスのマッチングはされないので注意。

こんなルールのとき img-src http://xss.moe http://xss-not.moe/path

http://xss-not.moe/not-path Fail !http://xss.moe/redirecter Pass !http://xss.moe/redirecter―Redirect→ http://xss-not.moe/not-path Pass

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

Nonce source

• 実行可能なインラインスクリプトを指定可能に。 • 必要なインラインのscript/styleのnonce属性を 使って、unsafe-inlineを指定せずにCSP適用可。

• 実装より先に考えないと適用が難しかったCSPが後からでも適用しやすく！！

CSP 1.0 script-src 'self' 'unsafe-inline' !<script> alert('this is overdone.'); </script>

CSP 2.0 script-src 'self' 'nonce-ODEyMzg5ODgx...' !<script nonce="ODEyMzg5ODgx..."> alert('this works well, and minimum.'); </script>

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

Nonce source• 実際のコードにおいては1) ヘッダのNonce2) タグの属性値のNonceそれぞれにBase64な乱数を設定する。

• 乱数が予測されなければ、攻撃者がscript/styleを挿入してもそのタグ内のコードが実行/反映されることはない。

• インラインコードを排除するよりもずっとずっと現実的な方法でCSPを適用できる。

Source hash

• インラインのscript/styleタグで使用可能。 • script-src/style-srcで指定する。 • タグ内のコードのハッシュダイジェストを使う。 • サポートされるアルゴリズムは以下の通り。 - SHA-256 - SHA-384 - SHA-512

CSP 2.0 script-src 'self' 'sha256-wWhNL+Czna...' !<script>alert("work");</script> <script>alert("doesn't work");</script>

CSP 1.0 script-src 'self' !<script>alert("doesn't work");</script>

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

Source hash• 事前計算したハッシュダイジェストをヘッダで渡すだけなので、乱数を使うより高速？

• ただしコードの修正が入った場合など、いちいちダイジェストの再計算が必要で面倒臭い。

• そういう手間を考えると素直に外部スクリプト化した方が楽なのでは？

• ルータのWeb管理画面など、コードの修正がめったにないような製品ではいいかも。

frame-ancestors

• iframeなどを通したアクセスに対する挙動を設定するディレクティブ。

• X-Frame-Optionsとの違いは後述。 • X-Frame-Optionsと競合する場合は、 このディレクティブが優先される。

• デフォルトではワイルドカードが設定される。 • 微々たる違いだけど地味にデカい！

X-Frame-Optionsとの差異

• X-Frame-Optionsとframe-ancestorsのポリシーの対応は、ざっくり言うとこんな感じ。DENY → 'none'SAMEORIGIN → 'self'

• 基本的に実現したい機構は同じで、クリックジャッキングなどの対策。

• 大きな違いは次のスライドで。

X-Frame-Options CSP Lv.2のframe-ancestors

ここだけ見る 全部見る

frameアクセスを制限したいページ

frameアクセスを制限したいページ

referrer

• リファラの送信を制御するディレクティブ • サーバ側の設定を変更するだけでサイト全体のリファラ送信についてのポリシーを変更できる。

• けっこうイケてる気がする。 • HTTPのrefererヘッダはミススペリングｗCSPのディレクティブでは正しい綴り使うよ！って最終草案に書いてあって笑ったｗ

referrer

referrer none - リファラを一切送信させない referrer none-when-downgrade - SSL/TLSを使っているページからそうでないページヘは リファラを送信しない referrer origin - 同一オリジン間でのリファラ送信を許可 referrer origin-when-cross-origin - 同一オリジンならリファラを送信、 そうでなければオリジンのみ送信 referrer unsafe-url - 全てのリファラを送信

origin-when-cross-origin

• CORS周りの仕様に関係する部分。 • クロスオリジンのリクエスト送信時は勝手にOriginヘッダが付く。

• このヘッダを用いて正当なリクエストかどうかを判別する場合もあるので、これが必要。

reflected-xss

• XSS Filter/XSS Auditorの動作を規定するディレクティブ。

• X-XSS-Protectionとの関係は後述。 • IEのXSS Filterの対策もされているのでイケメン。これも後述。

reflected-xss

reflected-xss allow - XSS Filter/XSS Auditorを無効化 - X-XSS-Protection: 0に相当 !reflected-xss filter - XSS Filter/XSS Auditorを有効化 - X-XSS-Protection: 1に相当 !

reflected-xss block - XSS Filter/XSS Auditorをブロックモードで有効化 - X-XSS-Protection: 1; mode=blockに相当

metaタグでの指定禁止• reflected-xssディレクティブをmetaタグで設定した場合、無視される。

• IEのXSS Filterでは、非ブロックモード時、インジェクションされた文字列の一部を#に置き換える。

• これを用いてreflected-xssディレクティブを無効化できるため、脆弱となる可能性が！

• ただし現状IEはCSPを実質サポートしていないに等しいためこの心配は(ry

sandbox

• iframe sandboxのポリシーをCSPで指定できる。 • iframe sandboxはiframe内のコンテンツの挙動を制限できる機構。

• CSPでのXSS対策という視点では効果は限定的だけど、HTMLコンテンツ中にいろいろ吐き出さなくて済むというのは利点になるかも。

• IEもこれだけは対応してる。

sandbox

sandbox allow-forms - フレーム内でのフォーム送信を許可 sandbox allow-pointer-lock - ポインタロックを許可 sandbox allow-popups - ポップアップを許可 sandbox allow-same-origin - フレーム内コンテンツを同一オリジンのものとして扱う sandbox allow-scripts - フレーム内でのスクリプト実行を許可 sandbox allow-top-navigation - フレーム内から親フレームへのアクセスを許可

CSP Lv.2サポート状況

• Chrome - Path matching … ○ - Nonce source … ○ - Source hash … ○

• Safari - Path matching … ○ - Nonce source … ✕ - Source hash … ✕

• Firefox - Path matching … ○ - Nonce source … ○ - Source hash … ○

まとめ

• すでにできあがったものに適用するのが難しかったCSPが、Lv.2になってだいぶ進歩する！

• 細かいところで使い勝手がよくなっているので、既に使っている開発者もアンテナ張っておくべし！

• 運用の面倒臭さは相変わらずだけど、導入までの障壁はずっと少なくなったので、使うべし！

• ただしIEは…うん…