1. 物語の舞台:「門番」と「本物の家」
ウェブの世界では、攻撃者(ハッカー)が本物の家(サーバー)に侵入しようとするのを防ぐために、**「門番(WAF)」**が立っています。
- 門番の役割: 訪れる人(リクエスト)が怪しいかチェックし、悪意のあるもの(攻撃コード)を排除します。
- 家の役割: 門番を通った人を受け入れ、仕事を処理します。
通常、門番と家のルールは同じはずですが、この研究では**「門番と家の『言葉の解釈』が微妙にズレている」**という弱点を突きました。
2. 核心となるアイデア:「言葉のあや(パースングの不一致)」
この研究の核心は、**「同じ文章でも、誰が読むかによって意味が変わってしまう」**という現象です。
例え話:手紙の封筒と中身
想像してください。ハッカーが「爆弾(攻撃コード)」を隠した手紙を送ります。
- 通常: 門番は「中身を開けて中身を確認する」ので、爆弾を見つけます。
- この研究の手法: ハッカーは、手紙の封筒(ヘッダー)や、中身の袋の結び方(境界線)に、**「人間には読めるが、機械には少し曖昧な書き方」**をします。
【具体的なシチュエーション】
- 門番の視点: 「この手紙の袋の結び方は『A』と書かれているな。でも、中身を見ると『B』という結び方もある。まあ、A でいいや」と思い、**「怪しくないから通す」**と判断します。
- 家の視点: 「いやいや、この手紙のルール(RFC という国際的な約束事)では、複数の結び方が書かれていたら、『B』の方が優先されるんだよ!」と解釈し、**「B で開けたら、中に爆弾(攻撃コード)が入っていた!」**と気づきます。
結果として、**「門番は『安全』と判断して通したが、家の中では『攻撃』が実行されてしまう」という状態が生まれます。これを「パースングの不一致(解釈のズレ)」**と呼びます。
3. 彼らがやったこと(実験)
研究者たちは、この「言葉のあや」を見つけるために、自動で大量の手紙(データ)を送るロボット(ファッサー)を使いました。
- 対象: 有名な門番 5 社(Cloudflare, AWS, Azure など)と、家のシステム 6 種類(Flask, Spring Boot など)。
- 手紙の種類: 主に「フォームデータ(multipart)」、「XML(構造化データ)」、「JSON(データ形式)」の 3 種類。
- 結果:
- なんと1,207 通りもの「門番をすり抜ける方法」を見つけました!
- 有名な門番の多くが、この「言葉のあや」に引っかかり、攻撃コードを通過させてしまいました。
- さらに、**「90% 以上のウェブサイト」**が、異なる形式(例:
form-data と json)を区別せずに受け付けていることが判明。つまり、この攻撃は非常に現実的で広範囲に適用できることが分かりました。
4. 解決策:「翻訳の校正機(HTTP-Normalizer)」
この弱点を直すために、研究者たちは**「HTTP-Normalizer」**という新しいツールを開発しました。
- どんなもの?: 門番と家の間に置く、**「厳格な翻訳校正機」**です。
- 仕組み:
- 届いた手紙を、国際的なルール(RFC)に厳密に従って「正しい形」に直します。
- 「A と B どちらが正しいか?」という曖昧な部分は、ルール通りに一つに統一します。
- ルールに合わない怪しい手紙は、最初から破棄します。
- 効果: この校正機を通すことで、門番も家も**「同じ解釈」**をするようになり、すべての「言葉のあや」による攻撃を防ぐことができました。
5. まとめ:何が起きたのか?
- 問題: ウェブサイトのセキュリティ門番は、データの「読み方」が厳密でなく、ハッカーに隙を与えていた。
- 発見: 研究者たちは、この「読み方のズレ」を 1,200 以上見つけ、実際に攻撃を成功させた。
- 対策: 「厳格なルールに従ってデータを整理する」ことで、この隙を塞ぐことができる。
一言で言うと:
「門番と家の『ルールの解釈』がバラバラだったせいで、ハッカーが『ごまかし』で侵入できた。でも、両方を『同じルールブック』で厳しくチェックすれば、もう防げるよ!」という研究です。
この研究は、セキュリティベンダーに修正を促し、一部の企業からは「バグバウンティ(報奨金)」を受け取るなど、実際にセキュリティを向上させる成果につながっています。
WAFFLED: Web Application Firewalls の回避におけるパース不一致の悪用
技術的サマリー(日本語)
本論文「WAFFLED」は、Web アプリケーションファイアウォール(WAF)とバックエンドの Web アプリケーションフレームワーク間のHTTP リクエストパース(解析)の不一致を悪用し、WAF を回避する新たな攻撃手法を提案・実証した研究です。
以下に、問題定義、手法、主要な貢献、結果、および意義について詳細にまとめます。
1. 問題定義:WAF とフレームワーク間の「パース不一致」
従来の WAF 回避技術は、攻撃ペイロード自体をエンコードや難読化して検知ルールをすり抜けるものでしたが、ベンダー側もこれらの対策を強化しています。
本研究が着目したのは、**「WAF がリクエストを正常と判断し通過させるが、裏側の Web アプリケーションフレームワークがそれを異なる形式(または攻撃ペイロードを含む形式)として正しく解析・実行してしまう」**という現象です。
- 核心: HTTP リクエストのヘッダーやボディ内の特定の要素(境界線、名前空間、文字列の区切りなど)を、RFC 仕様に準拠しつつも WAF とフレームワークで解釈が分かれるように「微細に変形(Mutate)」させることで、WAF の検知を回避しつつ、フレームワークには攻撃ペイロードを届けることが可能になります。
- 対象:
multipart/form-data, application/json, application/xml といった一般的なコンテンツタイプ。
2. 手法:WAFFLED のアプローチ
著者らは、この不一致を自動発見するためのファジング(Fuzzing)手法「WAFFLED」を開発しました。
- 入力生成と変異:
- 既知の攻撃ペイロード(SQL インジェクションや XSS など)を含む HTTP リクエストを生成します。
- 重要: 攻撃ペイロード自体は変更せず、ヘッダー名、境界線(boundary)、パラメータの区切り文字、空白、改行など、ペイロード以外の部分を RFC 仕様の範囲内で変異させます。
- 文法ベース(Grammar-based)かつ構造を考慮したファズターを使用。
- 検証パイプライン:
- 5 種類の主要 WAF(AWS, Azure, Google Cloud Armor, Cloudflare, ModSecurity)と、6 種類の主要 Web フレームワーク(Flask, Laravel, Spring Boot, Express など)の組み合わせに対して、変異されたリクエストを送信します。
- WAF がリクエストを通過させ、かつバックエンドフレームワークが攻撃ペイロードを正しくパースして実行できた場合を「成功(Bypass)」と判定します。
- 実世界での妥当性検証:
- PublicWWW を用いた調査により、多くの Web サイトが
application/x-www-form-urlencoded と multipart/form-data を互換的に扱っていることを確認し、攻撃の現実的な適用可能性を証明しました。
3. 主要な貢献
- 新たな回避アプローチの提示: ペイロードの難読化ではなく、「コンテンツパースの不一致」を利用した WAF 回避の概念を確立しました。
- 自動化された発見手法: ブラックボックスファジングを用いて、不一致に基づく新たな回避ベクトルを自動的に発見するパイプラインを設計・実装しました。
- 大規模な実証実験: 5 つの主要 WAF と 7 つのフレームワーク、およびそれらが使用するパースライブラリを対象に、1,207 件のユニークな回避事例を特定しました。
- 防御ツールの提案(HTTP-Normalizer):
- 発見された脆弱性を防ぐためのプロキシツール「HTTP-Normalizer」を開発しました。
- このツールは RFC 仕様に厳密に準拠したパースを行い、不正な構造や曖昧な要素を正規化(Normalizing)または拒絶することで、WAF とフレームワーク間の解釈のズレを解消します。
4. 実験結果と分析
- 回避事例の数: 5 つの WAF と複数のフレームワークの組み合わせで、合計1,207 件のユニークな回避を特定しました。
- WAF 別の結果:
- Cloudflare, Azure, Google Cloud Armor, ModSecurity: すべてで多数の回避事例が確認されました。
- AWS WAF: 本手法による回避は確認されませんでした(これは AWS WAF のパース実装が厳格である可能性を示唆)。
- コンテンツタイプ別の分類:
- Multipart (351 件): 境界線(boundary)の操作、ヘッダーの改ざん、改行コードの削除など。
- XML (299 件): DOCTYPE の閉じ忘れ、スキーマの操作、余計なフィールドの追加など。
- JSON (557 件): フィールド名のハック(
\x00 などの挿入)、ダブルクォートの置換、Content-Type ヘッダーの削除など。
- 実世界への影響: 調査対象の Web サイトの 90% 以上が、
application/x-www-form-urlencoded と multipart/form-data の両方を互換的に受け入れることが判明。これは、multipart に関する回避手法が広範な Web アプリケーションで有効であることを意味します。
5. 意義と結論
- セキュリティへの影響: WAF は「攻撃をブロックしている」という誤った安心感を与えている可能性があります。実際には、パースの不一致により攻撃が裏側のアプリケーションに到達し、実行されてしまうリスクが極めて高いことが示されました。
- ベンダーへの対応: 著者らは発見した脆弱性を各ベンダーに報告し、すべてが認められました。
- Google Cloud Armor はバグバウンティを支給。
- Cloudflare は修正中と発表。
- Microsoft Azure は CRS 3.0 の廃止と DRS 2.1 への移行で対応。
- ModSecurity は CRS 3.3 で対応を認めています。
- 解決策: 本研究は、WAF が単なるルールマッチングだけでなく、RFC 仕様に厳密に準拠したパース(正規化)を行うことが、これらの攻撃を根本的に防ぐ有効な手段であることを実証しました。提案された「HTTP-Normalizer」は、その実用性を示す PoC として機能しています。
結論として、WAFFLED は Web セキュリティの分野において、WAF とバックエンド間のパース整合性の重要性を浮き彫りにし、より堅牢な防御体制の構築に向けた具体的な指針を提供した画期的な研究です。
毎週最高の computer science 論文をお届け。
スタンフォード、ケンブリッジ、フランス科学アカデミーの研究者に信頼されています。
受信トレイを確認して登録を完了してください。
問題が発生しました。もう一度お試しください。
スパムなし、いつでも解除可能。
週刊ダイジェスト — 最新の研究をわかりやすく。登録