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

10K Views

June 21, 24

スライド概要

CSPヘッダ付与のすすめ

PHPカンファレンス福岡 2024資料

profile-image

パソコンの大先生です

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

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

2.

タイトルは日和った

3.

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

4.

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

5.

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

6.

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

7.

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

8.

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

9.

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

10.

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

11.

11 通常対策は漏れる

12.

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

13.

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

14.

14 通常対策は漏れる

15.

15 「モダンなFW使ってるから大丈夫」

16.

16 「モダンなFW使ってるから大丈夫」 そんなんじゃ甘いよ

17.
[beta]
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.

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

19.

19 モジュールからも

20.

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

21.

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

22.

22 @lonegoatsoap

23.

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

24.

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

25.

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

26.

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

27.
[beta]
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.

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

29.

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.

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

31.

31 具体的にどうすんの?

32.
[beta]
32

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

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

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

33.

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

34.

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

35.

35 CSP適用で重要なこと

36.

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

37.

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.

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

39.

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

40.

おまけ

41.

41 nginx add_headerの罠

42.

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

43.

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

44.

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

45.

45 @lonegoatsoap

46.

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

47.

47 @lonegoatsoap

48.

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

49.

49 まとめ

50.

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

51.

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.

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