CSP による防御とリアルワールドレポート収集/csp-and-real-world-reporting

Slide 1

Slide 1 text

CSP real world reporting Recruit Tech Night #rtechnight 2017/02/03

Slide 2

Slide 2 text

Jack

Slide 3

Slide 3 text

P rotein S teroid 3 C ontent

Slide 4

Slide 4 text

4 C ontent S teroid P rotein S ecurity P olicy

Slide 5

Slide 5 text

Slide 6

Slide 6 text

6 Policy of Security for Content ● This content is allowed to ○ exec inline script ? ○ load assets from origin xxx ? ○ embend iframe ? ○ mixed content ? ○ etc

Slide 7

Slide 7 text

7 How to apply CSP ● via Header ● via Meta Tag Content-Security-Policy: $policy

Slide 8

Slide 8 text

8 CSP directives ● connect-src ● font-src ● frame-src ● img-src ● manifest-src ● media-src ● object-src ● script-src ● style-src ● worker-src どこから読み込めるかの設定 ex) img-src ‘self’ https://jxck.io (同じ Origin と https://jxck.io のみ画像を許可) default-src は指定しない場合のフォールバックとして働く。

Slide 9

Slide 9 text

9 CSP keywords ● ‘self’ ● ‘none’ ● ‘unsafe-inline’ ● ‘unsafe-eval’ , <style> を利用したインラインの実行や、 eval 自体もブロックされるため、明示的に許可するには unsafe-* を使う。

Slide 10

Slide 10 text

10 Most Powerful Policy ● can I have… ○ jquery from cdn ? :No ○ google anlytics ? :No ○ youtube? :No ○ iframe... :NO! ○ inli :Never !! Content-Security-Policy: default-src ‘self’

Slide 11

Slide 11 text

11 Example: XSS

Slide 12

Slide 12 text

No more Escape Input ? ● 本質的に攻撃を防いでいるわけではない ○ CSP に対応してないクライアントもある ● ポリシー違反を不活性にするだけ ○ ポリシーに穴があれば攻撃は成り立つ ● これまでのセキュリティ対策との合わせ技 ○ 防ぎきれなかった攻撃を不活性にする最後の砦 12

Slide 13

Slide 13 text

13 case study: github.com

Slide 14

Slide 14 text

It’s really works ?? 14

Slide 15

Slide 15 text

report-uri 15 ● Send Report as JSON to URI Content-Security-Policy: default-src ‘self’; report-uri https://report-server/... { "csp-report": { "document-uri": "発生場所", "referrer": "リファラ", "blocked-uri": "防いだもの", "violated-directive": "違反していたディレクティブ ", "original-policy": "元となるポリシー", } }

Slide 16

Slide 16 text

Report doesn’t tells me about attack ● 何が起こったかは分かる ○ ブロックされたもの ○ それを引きおこしたポリシー ● どうして起こったかはわからない ○ 攻撃か？それ以外か？ ● その結果ユーザがどういう体験をしたかもわかりにくい ○ 広告が見えなかった？ ○ 登録ができなかった？ 16

Slide 17

Slide 17 text

It’s really… OK ...? 17

Slide 18

Slide 18 text

Too strict to deploy immediate ● ポリシーが妥当かをチェックするのは難しい ○ ステージングなどでやってみるしかない ● リアルワールドでの使われ方は多様 ○ どんなブラウザをどんな設定で使ってるか不明 ● いきなり本番で有効にするのは怖い ○ ユーザが不都合な現象に出会わないか。。 ○ 攻撃が発生するよりも怖いかもしれない。。 18

Slide 19

Slide 19 text

CSP-Report-Only ● CSP を適用するがブロックはしない ○ レポートを送るだけ ○ 実際にどんなレポートが来るかを解析できる ● いつ外すか？ ○ ポリシーに自身が持てたら ○ 無理に Report-Only を外す必要もないかも ○ 何が起こってるか分かるだけでも前進してる 19

Slide 20

Slide 20 text

一年ほどやってみた 20

Slide 21

Slide 21 text

blog.jxck.io 21 ● basically static contents only ○ no ○ no Dynamic Generated ○ no CDN ● 基本的に XSS などの発生は考えにくい ○ その条件でもレポートがあるのか ○ あるとすればどんなものかを調査 ○ があるサービスではもっと増えるだろう

Slide 22

Slide 22 text

Current Settings 22 content-security-policy-report-only: default-src 'self' https://jxck.io https://*.jxck.io https://www.google-analytics.co m ; child-src https://blog.jxck.io https://www.youtube.com ; connect-src wss://ws.jxck.io ; report-uri https://jxck.report-uri.io/...

Slide 23

Slide 23 text

23 CSP report (2016/3 ~ now) deploy fixup csp setting non critical reports

Slide 24

Slide 24 text

24 CSP Report case#1 ● inline style in FF view-source:// { "csp-report": { "blocked-uri": "self", "document-uri": "view-source", "original-policy": "...", "script-sample": "-moz-tab-size: 4", "source-file": "view-source:https://blog.jxck.io/entries/...", "violated-directive": "default-src view-source:// ..." } }

Slide 25

Slide 25 text

25 CSP Report case#1 ● inline style in FF view-source://

Slide 26

Slide 26 text

26 CSP Report case#2 ● inline style in Chrome .txt, .md, .xml { "csp-report": { "document-uri": "https://jxck.io/humans.txt", "referrer": "", "violated-directive": "style-src", "effective-directive": "style-src", "original-policy":"default-src 'self' https://*.jxck.io...", "disposition":"report", "blocked-uri":"inline", "line-number":1, "status-code":0 } }

Slide 27

Slide 27 text

27 CSP Report case#2 ● inline style in Chrome .txt, .md, .xml

Slide 28

Slide 28 text

28 CSP Report case#3 ● about://blank { "csp-report": { "document-uri": "about://blank", "violated-directive": "default-src 'self' https://jxck.io...", "effective-directive": "img-src", "original-policy": "default-src 'self' https://jxck.io…", "blocked-uri": "data", "status-code": 0 } }

Slide 29

Slide 29 text

29 CSP Report case#2 ● browser-extension { "csp-report": { "document-uri": "https://blog.jxck.io/entries/...", "violated-directive": "default-src 'self' https://jxck.io ...", "effective-directive": "img-src", "original-policy": "default-src 'self' https://jxck.io ...", "blocked-uri": "ms-browser-extension", "status-code": 0 } }

Slide 30

Slide 30 text

30 CSP Report case#2 ● append script via bookmarklet (maybe) { "csp-report": { "document-uri": "https://blog.jxck.io/entries/...", "referrer": "https://blog.jxck.io/", "violated-directive": "script-src", "effective-directive": "script-src", "original-policy": "default-src 'self' https://jxck.io...", "disposition": "report", "blocked-uri": "https://code.jquery.com/jquery-3.0.0.min.js", "line-number": 1, "column-number": 108, "status-code": 0 } }

Slide 31

Slide 31 text

More and More... 31

Slide 32

Slide 32 text

32 Protected? / Clippled? ● ほとんどの違反は攻撃には見えない ○ 本当に全部ブロックすべき？ ○ ユーザに不便を強いてないか？ ● 基本的に開発者向けのサイト ○ コンテンツはいじられる前提 ○ bookmarklets, extentions, localproxy etc ○ レポート収集くらいがちょうど良さそう ● Protected / Clippled ○ コンテンツ次第としか言えない ○ Github は思い切ってるなぁ

Slide 33

Slide 33 text

Mixed Contents 33

Slide 34

Slide 34 text

Finding Mixed Contents 34 ● Mixed Contents ○ HTTPS コンテンツ内で HTTP コンテンツを読み込む ○ MITM されてるかもしれない(安全を保証できない) ○ URL バーが緑ではなくなる ● Active ○ 元の DOM を書き換えられる(script, iframe etc) ○ ブロックされる ● Passive ○ 元の DOM は書き換えられない(img, video, audio etc) ○ エラーはでるがブロックされない

Slide 35

Slide 35 text

HTTPS 移行と Mixed Contents 35 ● Mixed Contents のよくあるパターン ○ Consumer Generated Media (ユーザの埋めた img など) ○ Ad (広告の iframe など) ○ Legacy Hard Coded URL (古い新聞社など) ● 勢いで HTTPS 移行すると ○ insecure 表示になって信用を失う ○ ユーザの作ったコンテンツが壊れる ○ 広告が見えなくて収入がががが ○ 全部の URL 書き換えるの、、マジ無理、、

Slide 36

Slide 36 text

Upgrade-Insecure-Request 36 ● http:// を https:// にブラウザが読み換える ○ https:// がなければ 404 になる ○ ただし、絶対に mixed contents にならない ● サーバの対応だけで移行できる ○ コンテンツを書き換えないで良い ○ https にできてないものを access.log で見つけられる Content-Security-Policy: Upgrade-Insecure-Requests

Slide 37

Slide 37 text

Block-All-Mixed-Contents 37 ● Passive でもブロックする ○ コンテンツは壊れるかもしれない ○ ただし、絶対に mixed contents にならない ● CSP Report と組み合わせられる ○ Report-Only にすればコンテツに影響が出ない ○ https にできてないものを csp reoprt で見つけられる Content-Security-Policy: Block-All-Mixed-Contents

Slide 38

Slide 38 text

Report Server 38

Slide 39

Slide 39 text

39 report-uri.io ● not recommended (personaly) ○ UI が ○ソ ○ 同時に Report をたくさん送ると 500 返すことが ○ 半年以前のデータが表示できない？ ○ HTTP ヘッダが見えないので UA がわからない ○ 過去のレポートをエクスポートできない ● do yourself ○ POST 受け取るシンプルなエンドポイントでよい ○ 処理は kibana, grafana, big query などで ○ Google Analytics がやってくれると嬉しい

Slide 40

Slide 40 text

40 Report Analyze ● ほとんどが設定ミス ○ ステージングとプロダクションで分けよう ○ フレームワーク/CMS での自動化に期待 ● Attacks を見つけるのは難しい ○ 難、、無理じゃね？ ○ でも傾向には価値がある ○ AI とかに期待

Slide 41

Slide 41 text

One More Thing 41

Slide 42

Slide 42 text

HTTP Public Key Pinning 42 ● 意図してない公開鍵での表示を防ぐ ○ CA インシデントの多発により提案された ○ 主に Google が怒って入れた ● 運用が難しい ○ 証明書が変わると表示されなくなる場合も ○ バックアップのハッシュを事前にやっておくべき Public-Key-Pins: pin-sha256=”#{hash-of-public-key}”