事例研究：XML属性ひとつで約159本のWAFルールをすり抜ける

私はJoeです。今回はクライアント案件ではなく、リサーチの記録です。OWASP Core Rule Set で見つけた二つのバイパスを、メンテナに報告し、CVE-2026-62971 および CVE-2026-33691 として公開しました。いずれもすでに修正済みです。ここで取り上げるのは、それらを見つけた手法、すなわち「エンジンが決してパースしない部分は何か」を問う姿勢が、このルールセットに限らず、あなたが運用するあらゆるフィルタリング技術に応用できるからです。

1. WAFは柵ではなく、フィルタである

   私がテストするほぼすべての組織がWebアプリケーションファイアウォールを導入しており、そのほぼすべてが同じ言い方をします。「うちは対策済みです」。WAFは、自身がパースの仕方を知っているリクエストの部分を検査し、パターンと照合します。パースしない部分は、定義上、WAFからは見えません。ですから興味深い問いは「どのルールが有効か」ではなく、「エンジンが決して見ないリクエストの部分はどこか」です。この問いが、本稿の二つのCVEを生みました。

2. 死角 ― XML属性値

   OWASP Core Rule Set は世界で最も広く導入されているルールセットです。ModSecurity、Coraza、あるいはマネージドWAFを使っているなら、その下にCRSがある可能性は高いでしょう。CRSはXMLボディを処理する際、要素のテキストは検査していましたが、属性値は検査していませんでした。そのため、属性の中に置かれたペイロード（たとえば javascript: URI）はそのまま通過し、同じペイロードを要素テキストに置いた場合はブロックされる、という状態になっていました。ルール自体は書かれたとおりに動作していたのです。ただ、そのデータを一度も見せられていなかっただけでした。

3. 報告前に、影響を正しく測る

   バイパスは、それがどれだけの範囲に及ぶかを示せて初めて注釈以上のものになります。私は、同一のペイロード集合を二つの位置（要素テキストと属性値）に対して、すべてのパラノイアレベルで送信し、どのルールが発火したかを差分比較するハーネスを作りました。結果は、9つのルールファミリーにまたがる約159ルールが、すべてのパラノイアレベルで影響を受けるというものでした。多くの利用者が最も頼りにしているインジェクション系とクロスサイトスクリプティング系のファミリーも含まれます。この数値こそが、報告を「エッジケース」から CVSS 7.2 の CVE-2026-62971 へと変えたものです。

4. 二つ目は、たった一つの空白だった

   同じ発想から、ファイルアップロードのルールでも二つ目の発見がありました。CRSはファイル名の末尾を照合することで危険な拡張子をブロックしますが、そのチェックの前に空白の正規化を行っていませんでした。「shell. php」のように、ドットと拡張子の間に空白を入れたファイル名はパターンに一致せずに通過してしまい、一方で後段の多くのスタックは、それを実行可能な名前へと平然と整形し直します。たった1文字。CVE-2026-33691 として登録され、CRS 3.3.9 および 4.25.0 で修正されました。

5. ローカルではなく、上流で直す

   一社のためにカスタムルールを書いて次に進むこともできました。しかし、それをCRSのメンテナに上流報告したことで、私を雇った組織だけでなく、そのルールセットを導入しているすべての環境に修正が届きました。メンテナの対応は迅速かつプロフェッショナルで、パッチはタグ付きリリースに取り込まれ、アドバイザリは影響を受けるバージョン範囲を明示して公開されました。オープンソースのセキュリティ活動とはこうあるべきだと思いますし、私が発見を抱え込まずに還元し続けている理由でもあります。

6. これはあなたのWAFにとって何を意味するか

   実務上の示唆は三つあります。第一に、ルールセットのバージョンは、アプリケーションの依存関係と同じように固定し追跡すること。2年遅れのWAFは、既知のバイパスがあるルールを動かしているということです。第二に、攻撃者と同じやり方でWAFをテストすること。同じペイロードを、複数のエンコーディングと複数の位置で試し、実際にどれが発火するかを記録します。第三に、WAFを唯一の防御にしないこと。ここで挙げた二つのバイパスは、自分自身で入力を検証しているアプリケーションに対しては無害です。その仕事を外部に丸投げしたアプリケーションに対しては、致命的になります。