WAFの限界って？

はじめに

最近の自律型侵入テストにおいて、高度に制限されたWebアプリケーションファイアウォール（WAF）さえも迂回する、新たなクロスサイトスクリプティング（XSS）の回避手法が発見されました。この画期的な手法は、HTTPパラメータ汚染とJavaScriptインジェクションを組み合わせることで、従来のシグネチャベースのWAFが検知できない攻撃パスを切り開きました。セキュリティ研究者たちは、厳しく設定されたWAFによって保護されたASP.NETアプリケーションを標的とし、一般的なXSSペイロードがブロックされる中で、WAF、ASP.NETのパラメータパーサー、そしてブラウザのJavaScriptインタプリタ間における解析の不一致を悪用することで、悪意のあるコードの実行に成功しました。

この研究は、WAFが単一のパラメータで完結する攻撃パターンに対しては有効であるものの、複数のパラメータに分割されたり、アプリケーション側の特定の処理挙動を利用するような巧妙な攻撃に対しては、その防御が十分に機能しないことを浮き彫りにしています。特に、従来のシグネチャベースのWAFは、ペイロードが細分化されると、定義されたパターンと一致しないために検出をすり抜けてしまいます。この状況は、現在のWAF技術が直面している本質的な課題を示しており、より深いアプリケーション層の理解とコンテキスト認識がなければ、進化する脅威に対処できないことを示唆しています。

WAFが回避されてしまう方法

WAFの回避手法の詳細：HTTPパラメータ汚染とJavaScriptインジェクション

この研究で採用された主要なWAF回避手法は、HTTPパラメータ汚染とJavaScriptインジェクションの組み合わせです。この手法は、Webアプリケーションフレームワークが重複するHTTPパラメータをどのように処理するかの違いを悪用します。

1. HTTPパラメータ汚染の悪用:

   • 多くのWebフレームワークは、同じ名前のクエリパラメータが複数存在する際に、その値をどのように処理するかについて一貫性がありません。
   • ASP.NETアプリケーションでは、HttpUtility.ParseQueryString() 関数が重複するパラメータの値をコンマで連結するという特定の挙動を示します。
   • 例えば、/?q=1'&q=alert(1)&q='2 というクエリは、ASP.NETによって 1',alert(1),'2 という一つの文字列に変換されます。

2. JavaScriptインジェクションの巧妙な仕掛け:

   • 上記の連結された文字列が、もしアプリケーション内で js userInput = '…'; のようなJavaScript文字列リテラルとして挿入されると、結果として js userInput = '1',alert(1),'2'; という有効なJavaScriptコードが生成されます。
   • ここで重要なのは、JavaScriptのコンマ演算子の挙動です。この演算子は、左側の式（ここでは alert(1)）を実行してから、右側の式（ここでは '2'）の値を返します。これにより、WAFのシグネチャベースのパターンマッチングでは見破れない形で alert(1) が実行されてしまいます。なぜなら、悪意のあるコード（alert(1)）が単一のパラメータ内に完全に存在せず、複数のqパラメータに分割されているため、従来のXSSシグネチャとは一致しないからです。

人気WAFのテスト結果とハックボットによる回避

研究チームは、この手法を用いてAWS WAF、Google Cloud Armor、Azure WAF、Cloudflare、Akamai、F5、FortiWeb、NGINX App Protectなど、17種類のWAF構成をテストしました。

• 手動ペイロードによるテスト:

  • 最も単純なインジェクションから、セミコロンや改行を使ったパラメータ汚染ペイロード、そしてヒューリスティックベースのペイロードまで、4種類のペイロードでテストが行われました。
  • その結果、Google Cloud Armor (ModSecurityルール)、Azure WAF Default Rule Set 2.1、そしてopen-appsecの3つの感度レベルのみが、全ての手動ペイロードをブロックすることに成功しました。
  • 一方で、AWS WAFのManaged、Cyber Security Cloud、F5のルールセットは常に回避されてしまいました。ペイロードの複雑さが増すにつれて、回避率は単純なインジェクションの17.6%から、最も高度なパラメータ汚染ペイロードでは70.6%にまで上昇しました。

• 自動化されたハックボットによるWAF回避:

  • 手動テストで「無敗」だったWAFに対しては、自律型ハックボットが投入されました。
  • Azure WAF: ハックボットは、エスケープされたバックスラッシュ (test\\';alert(1);//) を利用した回避策を発見しました。これは、WAFのパターンマッチングとJavaScriptの解析におけるエスケープ処理の不一致を悪用したものです。
  • Google Cloud Armor: 徹底的な努力にもかかわらず、回避策は見つかりませんでした。ハックボットは、サーバーのパラメータ解析が大文字と小文字を区別しないことを指摘し、今後の探索経路を示唆しました。
  • open-appsec: ハックボットは、Critical設定に対して30秒未満で回避策を発見しました。最初のペイロードがブロックされると、alert から confirm へ、最終的には q='+new Function('a'+'lert(1)')()+' のようなペイロードを生成するなど、適応的な攻撃を実行しました。
  • これらの結果は、自動化が手動テストを補完する強力なツールであり、人間の研究者が見落とす可能性のある多くのバリエーションを発見できることを示しています。

現在のWAFの限界と課題

この研究は、現代のWAFが抱える複数の課題を浮き彫りにしています。

1. シグネチャベースWAFの限界: 従来のシグネチャベースのWAFは、パラメータ間で分割されたペイロードの検出に大きな困難を抱えています。定義された攻撃パターンと完全に一致しないため、巧妙に設計された攻撃を見逃してしまいます。
2. 深い解析とコンテキスト認識の欠如: 効果的な防御には、Webアプリケーションフレームワーク固有の深い解析と、JavaScriptのコンテキストを認識した分析が必要とされます。しかし、ほとんどのプロキシレベルのWAFソリューションにとって、このような詳細な分析は非現実的であり、パフォーマンスの低下を招く可能性があります。
3. 機械学習（ML）ベースWAFの脆弱性: MLベースのWAFは将来性がある一方で、適応的な攻撃ボットによって容易に無力化される可能性があります。ボットは、WAFが無害なトラフィックパターンを学習し始めると、その学習パターンを逆手に取り、検出を回避するようにペイロードを調整します。
4. WAFに対する過信: WAFは、セキュアでないコードに対する万能薬として頼るべきではありません。この研究は、たとえ最も洗練されたWAF設定であっても、微妙な解析の不一致によって無力化され得ることを示しています。
5. ハックボットの脅威の増幅: 自動化された攻撃ツールの台頭は、この脅威をさらに増幅させます。ハックボットは、人間では発見が困難な無数の攻撃バリエーションを迅速に生成し、WAFの防御を突破する能力を持っています。

おわりに

この一連の研究は、WebアプリケーションセキュリティにおけるWAFの役割と限界について、重要な洞察を提供しています。HTTPパラメータ汚染とJavaScriptインジェクションを組み合わせたこの新たなXSS回避手法は、WAFとアプリケーション、そしてブラウザの間に存在する解析の不一致が、いかに洗練された防御メカニズムをも無力化し得るかを示しました。特に、ASP.NETのコンマ連結挙動やJavaScriptのコンマ演算子のような、一見無害に見える特性が悪用されることで、従来のシグネチャベースのWAFは、分割されたペイロードを効果的に検出できないことが明らかになりました。

さらに、自動化されたハックボットの能力が、人間が見落とすような複雑な回避策を短時間で発見し、適応的な攻撃を仕掛けることで、WAFの限界を加速させています。Azure WAFやopen-appsecがハックボットによって突破された事例は、MLベースを含むWAFが、絶えず進化する攻撃者に対して常に一歩先を行くことが、いかに困難であるかを物語っています。

この結果は、「WAFさえあれば安全」という誤った認識を改め、多層防御（Defense in Depth）の重要性を再認識させるものです。WAFは重要な防御層の一つに過ぎず、それ単独でアプリケーションを完全に保護することはできません。真に強固なセキュリティ態勢を築くためには、以下の対策が不可欠です。

• 厳格な入力検証: アプリケーションレベルで、信頼できない全ての入力を厳しく検証し、無効なデータを拒否する。
• コンテキストアウェアなエンコーディング: ユーザー提供データをHTML、JavaScript、URLなどの異なるコンテキストに表示する際に、適切なエスケープ処理を適用する。
• セキュアな開発実践: 開発ライフサイクル全体でセキュリティを考慮し、脆弱性のないコードを記述する。
• 継続的な自動化されたセキュリティ評価: 人間の創造性とハックボットの効率性を組み合わせ、既知および未知の脆弱性を発見するための継続的なテストを実施する。

WAFは進化を続ける必要がありますが、それと同時に、アプリケーション開発者とセキュリティ専門家は、WAFの限界を理解し、より包括的なアプローチでWebアプリケーションのセキュリティに取り組むことが求められています。この「いたちごっこ」は今後も続くでしょうが、解析の不一致を最小限に抑え、多層的な防御を構築することが、未来の脅威に対する最も効果的な戦略となるでしょう。