5K Views
June 21, 24
スライド概要
CSPヘッダ付与のすすめ
PHPカンファレンス福岡 2024資料
WebサイトのXSS脆弱性絶対転がす ―Content Security Policyのすすめ― 小川
タイトルは日和った
3 自己紹介 • 小川 • 経歴 • ~2009 : Web開発のバイト&業務委託 • 2009~2019: 三菱重工 • イット何も関係ない仕事。野良のパソコンの大先生してた • 2019~いま : 株式会社root ip • ニッチなB2BのSaaS作ってます • PHPとVue分かる人来て!!1
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
10 クロスサイトスクリプティング(XSS)怖い • 簡単に起きる割に威力が高すぎる • 怖くて夜しか眠れない… • 不安で寿司しか喉を通らない… • 絶対止めたい
11 通常対策は漏れる
htmlspecialchars() 入れりゃ良いんでしょ?
13 通常対策は漏れる • PHPにはhtmlspecialchars()があるから・・・ • 本当に全箇所に漏れなく適用出来てますか? • 自分は大丈夫?他のメンバーは?新人が来たら? • そもそも"気をつける"だけが対策なの? • 前に1000箇所くらい一気に付けて死にそうになった • 長い
14 通常対策は漏れる
15 「モダンなFW使ってるから大丈夫」
16 「モダンなFW使ってるから大丈夫」 そんなんじゃ甘いよ
17
「モダンなFWだから大丈夫」?
• デフォルトでエスケープされてるでしょ?
• ???「PHP側で<table>作って入れようぜ!!11」
• 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
52 おわり 資料は𝕏の@hogeに置いておきます