WebサイトのXSS脆弱性絶対転がす ―Content Security Policyのすすめ―

WebサイトのXSS脆弱性絶対転がす ―Content Security Policyのすすめ― 小川

タイトルは日和った

3 自己紹介 • 小川 • 経歴 • ~2009 : Web開発のバイト&業務委託 • 2009~2019: 三菱重工 • ｲｯﾄ何も関係ない仕事。野良のパソコンの大先生してた • 2019~いま : 株式会社root ip • ニッチなB2BのSaaS作ってます • PHPとVue分かる人来て！！１

4 サマリ • クロスサイトスクリプティング(XSS)怖い • 一箇所あるだけで全情報抜かれる • 通常対策は漏れる • htmlspecialchars()が漏れたら死 • 「ﾓﾀﾞﾝなFWだから大丈夫」？そんなんじゃ甘いよ • Content Security Policyで包括対策しよう • XSS絶対(9割位)転がす • 開発がやろう

5 クロスサイトスクリプティング(XSS) 怖い

クロスサイトスクリプティング(XSS) 対策してますか？

7 クロスサイトスクリプティング(XSS)怖い • クロスサイトスクリプティング(XSS) • クライアント側で不正なJavaScriptを動作させる攻撃 • クライアントサイドJSで出来ることは何でも出来る • 発生原因 • エスケープしないユーザ入力をHTMLに入れてしまうだけ

8 クロスサイトスクリプティング(XSS)怖い •例 • セッション盗んでログイン • 情報全部外部に送信 • 低権限のユーザでも「この画面がおかしいんです！！！」と問い合わせ → テナント管理者が見に行ってXSS発動、無事死亡 • データ全部消す • 犯罪予告書かせる • 「警視庁爆破する」と書かせる事件 • 無限アラートで兵庫県○と握手

9 クロスサイトスクリプティング(XSS)怖い Q. 言うてそんなにある？ A. あるよ 脆弱性対策情報データベースJVN iPediaの登録状況 [2024年第1四半期（1月〜3月）] https://www.ipa.go.jp/security/reports/vuln/jvn/ipedia2024q1.html

• https://www.ipa.go.jp/security/reports/vuln/jvn/ipedia2024q1.html

10 クロスサイトスクリプティング(XSS)怖い • 簡単に起きる割に威力が高すぎる • 怖くて夜しか眠れない… • 不安で寿司しか喉を通らない… • 絶対止めたい

11 通常対策は漏れる

htmlspecialchars() 入れりゃ良いんでしょ？

13 通常対策は漏れる • PHPにはhtmlspecialchars()があるから・・・ • 本当に全箇所に漏れなく適用出来てますか？ • 自分は大丈夫？他のメンバーは？新人が来たら？ • そもそも"気をつける"だけが対策なの？ • 前に1000箇所くらい一気に付けて死にそうになった • 長い

14 通常対策は漏れる

15 「ﾓﾀﾞﾝなFW使ってるから大丈夫」

16 「ﾓﾀﾞﾝなFW使ってるから大丈夫」 そんなんじゃ甘いよ

17

「ﾓﾀﾞﾝなFWだから大丈夫」？
• デフォルトでエスケープされてるでしょ？
• ？？？「PHP側で<table>作って入れようぜ！！１１」
• Laravel
• {!! $html !!}
• <input value={{ $value }}> ← aaa onclick=alert(1)

• Vue
• <div v-html="html"></div>

• React
• <div dangerouslySetInnerHTML={html} />

• 汎用 <a href="javascript:alert(1)">

18 出来る＝誰かがやる 明日の自分かもしれないし、新人かもしれない

19 モジュールからも

20 モジュールからも • 例 VueQuill (WYSIWYGエディタ) • textareaをWYSIWYGにしたら便利そう • おーええやん

21 モジュールからも • 例 VueQuill (WYSIWYGエディタ) • textareaをWYSIWYGにしたら便利そう • おーええやん・・・ん？

22 @lonegoatsoap

23 モジュールからも • 例 VueQuill (WYSIWYGエディタ) • htmlモードで普通にXSS • onclick='alert("XSS")' をPOSTするだけ • サーバーサイドでのサニタイズはモジュール利用者の責務 ※本例はデフォルトの"Delta"モードなら起きないのでモジュール側の問題 ではない • 自分で書いたコードが全てではない というのが重要

24 どうにかなりませんか・・・？

25 Content Security Policyで 包括対策しよう

26 Content Security Policyとは • ブラウザが何をロードするのか指示するポリシー • JavaScript, スタイル, 画像, ... • HTTPレスポンスヘッダで指示する • Content-Security-Policy: script-src ○ ○ ○ • 意図したJavaScript以外全部止める • 仮にエスケープ漏れても動かなければセーフ • 無限に機能あり • 今日はXSS対策以外紹介しません • MDNみて

27

Content Security Policyとは
• サンプル
Content-Security-Policy:
script-src 'self' asset.example.com

• script srcを同ドメインかasset.example.comからのみ許可
• HTML内のインラインスクリプトは禁止
• <script>alert(1)</script>とかonload="..."とか

• eval系も禁止

28 Content Security Policyとは • サンプル実行例 • onmouseoverがあってもCSPでブロック • 単純に動かない ↑CSP違反だからブロックした旨のエラー@DevTools

29 Content Security Policyとは • XSS対策ポリシーの書き方 (Level 2) Content-Security-Policy: script-src <source> <source> • <sorce> に許可するJS読み込み元を指定 • 'self' … <script src=...>で同じドメインを許可 • asset.example.com …〃特定の外部ドメイン or URLを許可 • 'unsafe-inline' … <script>...</script>やonclickを許可 ↑CSP使う意味無い • 'unsafe-eval' … eval()やFunction()を許可 ↑これも微妙 • 他 (今回strict-dynamicは話しません)

30 Content Security Policyとは • github.comでの使用例 (script-src以外が長いので中略) • github.githubassets.com のJSのみ許可 • ユーザファイルは github.com, githubusercontent.com

31 具体的にどうすんの？

32

自サイトへの適用
• 自サイトに必要なスクリプトの元を調べる
• 列挙したポリシーを作る
Content-Security-Policy:
script-src 'self' domain1 domain2/analytics.js ...;

• コード修正
• インライン<script>...</script>はjsファイルに出す
• onclick などをイベントリスナーへ変える(addEventListener)
• javascript: リンクも直す

• HTTPサーバーかPHPでヘッダ出力

33 本番適用怖い・・・怖くない？

34 ブロックする前に • レポートだけ出すモードで試せる(ブロックしない) Content-Security-Policy-Report-Only: script-src 'self ... 'report-sample'; report-uri /csp-violation-report-endpoint/; • ポリシー違反時にreport-uriにJSONでレポートが来る • 両立も可 • 緩めのPolicy＋厳し目のReport-Only • (実は使ったことないです)

35 CSP適用で重要なこと

36 CSP適用で重要なこと • 開発者が主体的に実施する必要があります • セキュリティ屋任せは無理 • 何が意図した挙動なの否かは開発者しか知らない • これだけで全防御はダメ • エスケープは今まで通り必要 • JS以外にも脅威はある • 「多層防御」重要 • 抜け道もある

37 補足 • 今回はCSP Level 2のみ説明 • Level 3もある • 実はこっちの方がセキュア • nonce付きscriptタグ＋そこから先の読み込み纏めて許可できる script-src 'nonce-RANDOM' 'strict-dynamic'; <script nonce="RANDOM" ... • SPA等 index.htmlをnignx/CDN配信してると辛い (nonce何処でいれるの問題) • 「大変だからやらない」より、導入しやすいLevel 2をまず紹介 • Lv.3 の方がやりやすい場合もある

38 補足 • XSS対策としては強力、でも他の攻撃には無力 対策できるのこれだけ

39 補足 • XSS対策としては強力、でも他の攻撃には無力 対策できるのこれだけ

おまけ

41 nginx add_headerの罠

nginx add_headerの罠 • システムリリースに向けて開発中のある日 • いつの間にかCSPヘッダが消えてる？？？ • APIアクセスでは付く、 index.htmlでだけ付かない • 新手のスタンド攻撃か？ あるはず→

43 nginx add_headerの罠 • add_header って名前だし追加だろうなあ・・・

44 nginx add_headerの罠 • add_header って名前だし追加だろうなあ・・・ 何も書いてない場合だけ継承

45 @lonegoatsoap

46 nginx add_headerの罠 ←これは追加 ←これは1からセット (継承せず) ←ここは継承

47 @lonegoatsoap

48 nginx add_headerの罠 • add_headerは継承したりしなかったりする • 今更変えられなのはわかる(PHPer感) • 書いてあるでしょ • はい • CSPだけに頼ったら危ない事例 • 「多層防御」の重要性 • ちゃんとチェックしよう

49 まとめ

50 まとめ • クロスサイトスクリプティング(XSS)怖い • 一箇所あるだけで全情報抜かれる • 通常対策は漏れる • htmlspecialchars()が漏れたら死 • 「ﾓﾀﾞﾝなFWだから大丈夫」？そんなんじゃ甘いよ • Content Security Policyで包括対策しよう • XSS絶対(9割位)転がす • 開発がやろう

51 参考リンク • W3C • https://www.w3.org/TR/CSP2/ • https://www.w3.org/TR/CSP3/ • MDN • https://developer.mozilla.org/ja/docs/Web/HTTP/CS P • OWASP CSP Cheat Sheet • https://cheatsheetseries.owasp.org/cheatsheets/Co ntent_Security_Policy_Cheat_Sheet.html

• https://www.w3.org/TR/CSP2/
• https://www.w3.org/TR/CSP3/
• https://developer.mozilla.org/ja/docs/Web/HTTP/CS
• https://cheatsheetseries.owasp.org/cheatsheets/Co

52 おわり 資料は𝕏の@hogeに置いておきます