パラメータ汚染を悪用する新たな XSS 手法：代表的な WAF での回避状況をテストした

Web Application Firewall Bypassed via JS Injection with Parameter Pollution

2025/09/08 gbhackers — 最近の自律型ペンテストにおいて、厳格な Web Application Firewalls (WAF) さえも回避する、新たなクロスサイト・スクリプティング (XSS) 手法が発見された。Ethiack のセキュリティ研究者たちが実施したテストは、厳格にコンフィグされた WAF で保護された ASP.NET アプリケーションを対象とするものであり、従来からの XSS ペイロードは、シングルクォートで囲まれた JavaScript 文字列から抜け出す手法を用いたが、即座にブロックされた。

しかし、研究チームは、HTTP パラメータ汚染を悪用することで、悪意のコードを複数のクエリ・パラメータに分割し、構文的に有効な JavaScript に組み込むことに成功した。この手法による侵害は、WAF には検出できなかった。

この PoC GTFO シナリオにおいて、研究者たちにとって必要だったことは解析の差異への理解であり、それらは、WAF／ASP.NET のパラメータ解析器／ブラウザの JavaScript インタープリタの間などに存在するものだった。

過去の調査経験から、研究者たちは、ASP.NET の HttpUtility.ParseQueryString() が、重複パラメータをコンマで連結する動作を思い出した。

この特性により、以下のようなクエリは・・・

text/?q=1'&q=alert(1)&q='2

・・・文字列 1′,alert(1),’2 に変換される。これを・・・

jsuserInput = '…';

・・・に挿入すると、次のように有効なコードが生成される。

jsuserInput = '1',alert(1),'2';

ここで JavaScript のコンマ演算子は、最後の値を返す前に alert(1) を実行する。この手法は完全に機能するが、シグネチャベースのパターン・マッチングでは検出されない。

HTTP パラメータ汚染は、それぞれのフレームワーク間で、重複パラメータ処理が統一されていない点を悪用する。ASP.NET と従来の ASP は値をコンマで連結するが、Golang や Python の Zope などは配列を生成する。研究者たちは、出力に全値を取り込むフレームワークを除外し、ASP.NET のコンマ連結挙動に焦点を当てた。

その結果として判明したのは、JavaScript コードを複数の “q” パラメータに分割することで、従来の単一パラメータ XSS シグネチャに一切一致することなく、インジェクションが成立することだった。

一般的な WAF のテスト

AWS WAF／Google Cloud Armor／Azure WAF／open-appsec／Cloudflare／Akamai／F5／FortiWeb／NGINX App Protect などの、17 種類の WAF コンフィグを対象に、次の ４種類のペイロードをテストした。

• 単純なインジェクション：q=’;alert(1)
• セミコロンによるパラメータ汚染
• 改行によるパラメータ汚染
• ヒューリスティック・ベースのエンジン・ペイロード

その結果、Google Cloud Armor (ModSecurity rules)／Azure WAF Default Rule Set 2.1 ／open-appsec の３段階の感度レベルのみが、３つのペイロードをブロックした。その一方で、AWS WAF Managed／Cyber Security Cloud／F5 Rule Set では、すべてが回避された。

回避率は単純なインジェクションで 17.6% にとどまったが、ペイロードの複雑さが増すにつれ、最も高度なパラメータ汚染ペイロードでは 70.6% に上昇した。

続いて研究者たちは、無敗の WAF 群に対して、自律型ハッキング・ボットを投入した。

• Azure WAF：エスケープ処理の不一致を突く “test’;alert(1);//” によるバイパスを発見した。これは WAF のパターン・マッチングと、JavaScript 解析の差異を悪用したものである。
• Google Cloud Armor：徹底的な試行にもかかわらず、バイパスは発見されなかった。ただし、サーバ側のパラメータ解析が、大文字と小文字を判別しないことが判明し、ハッキング・ボットによる将来の探索の方向性が示唆された。
• open-appsec：30 秒以内という短時間で、重要なコンフィグ・バイパスを発見した。初期ペイロードがブロックされるとボットは適応し、”alert” から “confirm” へとモードを切り替え、最終的に “q=’+new Function(‘a’+’lert(1)’)()+'” のようなペイロードを生成した。

これらの結果は、人間の研究者が見落としがちなバリエーションを顕在化させるものであり、自動化が手動テストを補完する力を持つことを示している。

影響と推奨事項

• WAF の限界：従来からのシグネチャ・ベース WAF は、複数パラメータに分割されたペイロードの検出が困難である。効果的な防御には、フレームワーク固有の詳細な解析とコンテキスト考慮型 JavaScript 解析が必要であるが、プロキシ・レベルのソリューションは非現実的である。
• 機械学習の留意点：ML ベース WAF は有望であるが、適応型攻撃ボットが無害なトラフィックを学習すると、容易に突破される恐れがある。
• 多層防御：不安全なコード対策の代替として、WAF に依存すべきではない。厳格な入力検証／コンテキストに基づくエンコード／安全な開発プラクティスが、依然として不可欠である。
• 自動化の相乗効果：人間の創造性とハッカー・ボットの効率性を組み合わせることで、斬新な手法と単純な回避策の双方を明らかにできる。その結果として際立つのは、継続的かつ自動化されたセキュリティ評価の重要性である。

パラメータ汚染の落とし穴が示すのは、最も洗練された WAF コンフィグでさえ、微妙な解析ミスにより無効化され得ることである。ハッカー・ボットの台頭は脅威を増幅させ、多層防御と安全なコーディング基準の重要性を改めて認識させる。

XSS 攻撃における新しい回避手法が解説されています。原因は、ASP.NET が HTTP パラメータを処理する際の特殊な挙動にあります。特に HttpUtility.ParseQueryString() が重複したパラメータをコンマで連結する仕様を持っているため、攻撃者は悪意のコードを複数のパラメータに分割して送信し、それを組み合わせて有効な JavaScript として動作させることが可能になります。この仕組みを悪用する攻撃は、通常の WAF シグネチャでは検出できず、任意のコード実行につながると、この記事は指摘しています。よろしければ、WAF で検索も、ご参照ください。