WAFをバイパスする技術：テクニック、テスト、防御のプレイブック

ウェブ・アプリケーション・ファイアウォールは、徹底した防御戦略の強力なレイヤーだが、銀の弾丸ではない。 WAFを回避する技術-セキュリティ・チームが言及しているように、敵がどのように悪意のあるトラフィックを隠蔽するかを研究することで、防御者がそのギャップを予測し、埋めることができるようにすることです。この記事では、高レベルの回避のテーマ、防御テストのための実践的な SQL インジェクションのケーススタディ、安全な自動化の実践、モニタリングのアプローチ、Penligent のような継続的検証プラットフォームが最新のセキュリティ・プログラムにどのように適合するかについて説明します。

WAF回避術」とは何か？

簡単に言えば、WAF を回避する技術とは、攻撃者がどのようにウェブ・アプリケーション・ファイアウォールの防御を回避するかを研究することであり、防御者にとってより重要なのは、そのような回避を予測し、テストし、ブロックする方法です。WAF（ウェブ・アプリケーション・ファイアウォール）は銀の弾丸ではなく、攻撃者は常に戦術を進化させています。回避の「技」を学ぶことで、セキュリティチームは、攻撃者の創造性を、不意を突かれるのではなく、防御の準備に変えるために必要な洞察力を得ることができます。

WAFバイパス研究が重要な理由

今日のセキュリティ・チームは、システムに侵入するために回避テクニックを研究しているのではない。また、ウェブ・セキュリティ・ベンダーは大きな進歩を遂げたが、トラフィックがプロトコルやエンコーディングの想定される動作の限界に達した場合、WAFは依然として誤りを犯しやすい。

最近の学術的な研究（WAFFLED, 2025）では、AWS、Azure、Cloudflare、Google Cloud、ModSecurityを評価し、次のように記録している。 1,207件の実際のバイパス・インスタンス 解析の不整合やコンテンツタイプの取り扱いのルーズさが原因だ。これは失敗の証拠ではなく、敵が忍耐強く、創造的で、几帳面であることを思い出させるものだ。

同時に、WAF市場は成長を続けている。2024年には$7.33億米ドルとなり、2025年には$8.60億米ドルに達すると予測されている。 (Fortune Business Insights）。WAFが必要であるため、企業は多額の投資を続けている。しかし、WAFは無敵ではない。

教訓？WAFの導入は第一段階である。WAFの限界を理解し、その洞察に基づいて防御をチューニングすることがステップ2である。成熟したチームはその両方を行う。

攻撃者はどのようにWAFを回避しようとするのか：防御の視点

敵がどのようにウェブアプリケーションファイアウォールをすり抜けようとするのかを理解することは、攻撃を教えることではありません。実際には、ほとんどの回避の試みは単純な力学に依存しています。ファイアウォールとアプリケーションは時々、同じリクエストを異なる方法で見ます。攻撃者は、文字のエンコード方法を変えたり、リクエストを予期しないコンテンツタイプに誘導したり、あまり使われていないHTTP動詞を使ったりして、その解釈のギャップを利用する。

よくあるパターンは、無害に見えるものだ。ペイロードはエンコードされているためWAFにとっては無害に見えるが、バックエンドはデコードしてそれに対処する。もう1つのよくあるトラブルの原因は、解析の不一致だ。WAFの動作に関する研究では、微妙な違い（例えば、マルチパートボディの処理方法や重複するパラメータの削減方法など）が、ファイアウォールのフィルターとサーバーのパーサーの間で一貫性のない結果をもたらした何百もの事例が記録されている。 これらはエキゾチックな悪用ではなく、解析ルールや前提条件の違いから生まれる、実用的で再現可能な問題なのだ。

早期に正規化を実施し、可能であれば正規化前の入力とサーバサイドの入力の両方をログに記録し、シグネチャリストのみに依存するのではなく、実際のアプリケーションの動作に対してルールを調整する。次のスニペットは、一見良さそうに見える JSON のボディが、どのようにエンコードされた値を隠しているかを示しています。生のリクエストとデコード後のアプリケーション入力の両方をログに記録することで、WAF を通過したものが、後にアプリで予期しない動作を引き起こしたかどうかを明らかにすることができます。

POST /login HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 43

{"user":"admin", "pass":"%27 OR %271%27=%271"}

要するに、回避はしばしば1つの劇的なミスの結果ではなく、小さなミスマッチが重なった結果なのだ。正規化、一貫した解析、包括的なロギングに集中することで、小さなミスマッチを盲点から診断可能な問題に変えることができる。

SQLインジェクションWAFバイパス：定義と一般的なテクニック

WAFをバイパスするSQLインジェクションとは？ SQL インジェクションは、敵対者が悪意のある SQL 文を入力フィールドに注入することで、アプリケーションの認証 を妨害し、基礎となるデータベースを直接操作する攻撃手法です。ウェブアプリケーションファイアウォール(WAF)は、SQLi に対する一般的な防御手段の一つで、ユーザとアプリケー ションの間に位置し、リクエストを検査し、データベースに到達する前に疑わしい SQL パターンをブロックします。 WAFをバイパスするSQLインジェクション とは、WAFが存在するにもかかわらず悪意のあるSQLがサーバーに到達するように、攻撃者がこれらのフィルタリングルールを回避するために使用するテクニックのことである。

このようなバイパスパターンを理解することは、防御者にとって不可欠である。攻撃者が新しいSQL構文を考案することはめったにありません。 難読化 または 変える ペイロードは、シグネチャ・ベースのチェックや素朴なヒューリスティック・チェックがマッチしないようにする。これらの難読化戦略をマッピングすることで、防御チームはこれらのギャップを埋める変異ベースのテスト・スイートと正規化ルーチンを構築することができる。

SQLi WAF回避テクニックのまとめ

1.エンコード偽装 エンコーディング・ベースのバイパスの基本的な考え方は、攻撃者が特殊な文字エンコーディングを使用して入力を変換し、WAFの検出ロジックが悪意のあるSQLを認識できないようにするというものだ。つまり、エンコーディングによる難読化は、検出可能なSQLペイロードをWAFのルールが一致しない形式に変換します。エンコーディングに基づく難読化にはいくつかの形式があります：

• (1) URLエンコーディング：例．

難読化前のオリジナルのペイロード：

SELECT * FROM users WHERE username = 'admin' or 1 = 1;--' AND password = '123456'

URLエンコード偽装後のペイロード：

SELECT%20*%20FROM%20users%20WHERE%20username%20%3D%20%27admin%27%20or%201%20%3D%201%3B--%27%20AND%20password%20%3D%20%27123456%27

• (2）Unicodeエンコード：

難読化前のペイロード：

SELECT * FROM users WHERE ユーザー名 = 'admin' OR 1=1 AND パスワード = '123456'

偽装されたペイロード：

SELECT+*+FROM+users+WHERE+username+=+'%u0061dmin'+OR+1=1%23+AND+password+=+'123456'

• (3) 16進エンコーディング：

難読化前のペイロード：

 OR 1=1 --」。

偽装されたペイロード：

27%20%4F%52%201%3D%31%20%2D%2D

• (4) 二次エンコーディング：
• 難読化前のペイロード：

-1 union select 1,2,3,4#

• 最初のエンコード後のペイロード：

%2d%31%20%75%6e%69%6f%6e%20%73%65%6c%65%63%74%20%31%2c%32%2c%33%2c%34%23

• 2回目のエンコード後のペイロード：

%25%32%64%25%33%31%25%32%30%25%37%35%25%36%65%25%36%39%25%36%66%25%36%65%25%32%30%25%37%33%25%36%35%25%36%63%25%36%35%25%36%33%25%37%34%25%32%30%25%33%31%25%32%63%25%33%32%25%32%63%25%33%33%25%32%63%25%33%34%25%32%33

2.エスケープ文字マスキング

• 難読化前のペイロード：

UNION SELECT ユーザー名, パスワード FROM users --」。

偽装されたペイロード：

\UNION SELECT ユーザー名, パスワード FROM ユーザー --」。

上記の例では、攻撃者はオリジナルのペイロードにシングルクォートを使用し、その前にバックスラッシュを付けている。 \エスケープ文字を作成する \'.しかし、多くのプログラミング環境では、バックスラッシュ自体もエスケープ文字です。バックスラッシュと単一引用符を組み合わせることで、攻撃者はSQL文の中で生の単一引用符ではなく、事実上 "エスケープされた "単一引用符を生成することができます。こうすることで、攻撃者はエスケープされていない単一引用符を探すフィルタや検証を回避することができます。

3.乱数難読化

• 難読化前のペイロード：

UNION SELECT ユーザー名, パスワード FROM users WHERE id=1

偽装されたペイロード：

UNION SELECT ユーザー名, パスワード
FROM users WHERE id=1 AND 1=(SELECT
rand() < 0.5) --。

このペイロードで攻撃者は ランド 関数で乱数を生成し、それを 0.5.それ以来 ランド は0から1の間の任意の値を返すことができるが、この比較の結果はランダムである：生成された数値が0.5未満である確率は50%であり、0.5以上である確率は50%である。

• 生成された数値が0.5未満の場合、ペイロードは以下のようになる：

UNION SELECT ユーザー名, パスワード FROM users WHERE id=1 AND 1=1

生成された数値が0.5以上の場合、ペイロードは以下のようになる：

UNION SELECT ユーザー名, パスワード FROM users WHERE id=1 AND 1=0

この2つのケースは、それぞれ悪意のあるコードの実行が成功した場合と失敗した場合に対応する。さらに、攻撃者は -- コメント記号でクエリの残りを削除し、ペイロードを検出しにくくする。

乱数ベースの難読化を採用することで、インジェクションのたびにペイロードが異なって表示されるため、WAFの検出が困難になります。さらに、乱数値の予測不可能性により、攻撃者はその結果に基づいてインジェクションが成功したかどうかを推測することができますが、WAFはこの動作を検出することができません。

1. ケース・ミキシングによる難読化 これは簡単で、攻撃者は大文字と小文字を混ぜてキーワードを偽装する。 ユニオン・セレクション.
2. 二重書き（重複）難読化 例 ユニオン・セレクト 考え方は単純で、WAFはこれらを普通の文字として扱い、パターンを見逃す一方、アプリケーションのSQLパーサーはこれらを次のように正規化する。 UNIONセレクト そしてそれに従って実行される。
3. インライン・コメント難読化 インライン・コメントSQLインジェクションは、注入されたキーワードの中にインライン・コメント・マーカーを埋め込むことで、悪意のあるSQLをファイアウォールから隠します。例えば、攻撃者は /* ... */ コメントフラグメントをペイロードに挿入することで、WAFのパターンマッチングは失敗するが、データベースパーサーは正規化されたキーワードを解釈し、注入されたコードを実行する。原文に例を示す：

ユニオン・セレクト

一般的に、SQLインジェクションのバイパス技法はデータベース/解析レイヤで動作し、データベース管理シ ステムによって解析動作が異なるため、バイパス方法はDBMSによって異なります。迂回テクニックの核となる考え方は、難読化です。つまり、WAF/フィルタのルールを逃れても、アプリケーション/データベースによって有効なSQLとして解釈されるように、ペイロードを細工するのです。迂回を成功させるには、通常、柔軟なペイロードの構築と複数回の試行が必要です。最近の WAF はますます有効になっているので、SQL インジェクションのテストは難しくなっています。

倫理的なWAFテスト：自動化のための安全かつ合法的なアプローチ

バイパス技術が進化するのと同様に、セキュリティ・チームは、安全で、自動化され、反復可能なテスト・ワークフローを採用しなければなりません。ここでは、有効な防御プロセスを構築する方法を説明します：

ラボ/テスト環境のセットアップ - 常に本番環境の安全なクローンで検証する。 テストは、同一のWAFルールとルーティングを持つミラー化されたステージング環境で行います。完全なトレース（WAF前とWAF後）をキャプチャすることで、変換を分析できます。

WAFフィンガープリンティング - 評価しているファイアウォールを理解する。 パッシブ・フィンガープリントでベンダーとモードを特定することから始めましょう。ヘッダや動作の手がかりをレポートするツールは、テストファミリーをスコープし、現実的な盲点に焦点を当てるのに役立ちます。

自動ペイロード生成とファジング - 構造化変異エンジンを使用する。 異なるエンコーディング、コンテントタイプの並べ替え、ネストされたフォーマットを生成する、コンテキストを認識するファザーに頼る。自動化により、再現性が保証され、多くのエンドポイントにわたって拡張できる。

管理されたバリデーションと証拠収集 - 双方を監査する。 テストごとにWAFのレスポンスとバックエンドの動作を保存する。この比較は、有意義な修復と監査証跡のための重要な証拠となる。

改善プレイブック - 発見された問題を優先順位をつけて修正します。 正規化を優先し、ルールセットを厳格化し、コンテンツタイプチェックを強化し、サーバーパーサーにパッチを当て、アプリレベルの検証を追加する。所有権と再テスト基準を文書化する。

継続的検証とCI/CDインテグレーション - テストを習慣化する。 サニタイズされたテスト・スイートをCI/CDパイプラインに統合することで、ルールの更新やコードの変更が自動的にマイクロバリデーションの実行のトリガーとなる。

自動化プラットフォーム Penligentのようなプラットフォームは、安全なプローブを自動化し、生のトレースと正規化されたトレースを収集し、チームがパイプラインにプッシュできる優先順位付けされた修復プレイブックを作成します。自動化を使用して、発見と検証のループを閉じる。

この段階で、Penligentのようなソリューションが付加価値を与えることができます。 「私のWAFを最新のバイパス技術でテストし、安全なレポートを提供する。そして、サニタイズされたプローブを実行し、エビデンスを取得し、優先順位付けされた修復ステップを生成します。このような自動化をCI/CDパイプラインに組み込むことで、次のことが確実になります。 継続的検証 単発のテストよりも。

稼働中のシステムにおけるWAFバイパス試行の検出と監視

たとえハード化されたWAFルールであっても、本番環境でアクティブなバイパスの試みを検出する能力は不可欠である。以下の戦略を考えてみよう：

信号	何を監視すべきか	なぜそれが重要なのか
生のリクエストログと正規化されたリクエストログ	可能であれば、WAF前とWAF後の両方のログを保存する。	何が変更されたか／許可されたかを比較できるようにする
珍しい符号化パターン	多くの%-エスケープ、Unicodeシーケンスなどを含むリクエスト。	難読化を試みている可能性がある
予期しないHTTPメソッドまたはヘッダー	PUT/TRACEの使用、X-Forwarded-Hostのようなカスタムヘッダ	標準的な検査ロジックをバイパスする可能性がある
低速だが反復的なペイロード	似たようなペイロードを間隔をあけて、時間をかけて繰り返す	緩急をつけた回避の可能性
バックエンドのエラーパターン	予期しないアプリケーションエラーまたは解析例外	WAFが "OK "と記録しているにもかかわらず、ペイロードがアプリに到達したことを示す可能性がある。

WAFログ、バックエンドログ、SIEM/EDRアナリティクスを組み合わせることで、潜在的な回避の全体像を把握することができます。グッドプラクティス：以下の場合にアラートをトリガーする 符号化の複雑性 × 非POST方式 × レアヘッダー > 閾値＞である。

WAFとウェブアプリケーションの強化徹底的な防御

回避方法と検知シグナルを理解したなら、次は環境を強化する番だ：

• 正規化と標準化の有効化:ルールマッチングとバックエンド処理の前に、すべての入力が標準的な形式になるようにする。
• ポジティブ・セキュリティ・モデルを適用する:可能であれば、既知の悪いパターンをブラックリストに入れるのではなく、受け入れられるパターンをホワイトリストに入れる。
• コンテントタイプとHTTPメソッドのバリデーションの厳格化:期待されるメソッド（例：フォーム送信のPOST）のみを許可し、コンテンツタイプを検証する（例：APIエンドポイントのapplication/jsonのみ）。
• 追加の保護を重ねる:RASP（ランタイム・アプリケーション・セルフ・プロテクション）、EDR、行動分析をWAFと併用する。
• 継続的なテストとルールの更新:脅威は変異する。ルールも同様に進化しなければならない。テストの自動化とインテリジェンス・フィードを利用する。

現実の世界では2025年に実施された大規模な調査（「WAFFLED」）では、従来のWAFが解析のミスマッチによって何度もバイパスされていることが判明し、シグネチャのみのWAFに依存するのではなく、レイヤー防御の必要性が強化された。 arXiv

オートメーションとツール研究と実戦の架け橋

バイパス試行の量と多様性を考えると、手動テストではもはや十分ではありません。攻撃シミュレーション（セーフモード）とルール検証の両方において、自動化が鍵となる。

Penligentのようなプラットフォーム（スタックで利用可能な場合）は、自然言語プロンプトがいかに安全な侵入テストを推進できるかを実証している：

• "最新の2025年バイパス手法に対するWAFのテスト"
• "パラメータ汚染とマルチパート解析の不一致をチェック"

プラットフォームはその後だ：

1. 安全に消毒されたプローブを送信
2. ブロックされたトラフィックと通過したトラフィックをキャプチャ
3. 監査準備の整ったエビデンスバンドルの生成
4. 改善プレイブックを提供 (どのルールを強化するか、どのエンドポイントを検証するか)

CI/CDパイプラインで自動化を使用すると、新しいビルド、ルールの更新、またはアプリケーションの変更のたびに、マイクロペントサイクルがトリガーされます。

結論

WAFを迂回する技術とは、侵入方法を教えることではない。 攻撃者の思考を理解するそのため、防御者はそれに応じて防御を予測し、テストし、強化することができる。Webアプリケーション・ファイアウォールは貴重なレイヤーであることに変わりはありませんが、無敵ではありません。回避テクニックを研究し、インテリジェントに監視し、テストを自動化し、レイヤード・プロテクションを適用することで、リアクティブな姿勢からプロアクティブな姿勢へと移行することができます。2025年以降、WAFはルール・ライブラリから、継続的な監視のもとで検証された動的な防御へと進化する必要があります。

先手を打つ：バイパスがどのように起こるかを知り、安全かつ頻繁にテストを行い、攻撃者に隙を突かれる前にスタックを固める。