CSP Lv.2の話

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) ヘッダのNonce
2) タグの属性値のNonce
それぞれにBase64な乱数を設定する。
• 乱数が予測されなければ、攻撃者が
script/styleを挿入してもそのタグ内のコードが
実行/反映されることはない。
• インラインコードを排除するよりも
ずっとずっと現実的な方法でCSPを適用できる。

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

CSP 1.0
script-src 'self'
!
<script>alert("doesn't work");</script>
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
CSP 2.0
script-src 'self' 'sha256-wWhNL+Czna...'
!
<script>alert("work");</script>
<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は…うん…

CSP Lv.2の話

More Related Content

What's hot

Similar to CSP Lv.2の話

CSP Lv.2の話