AWS WAFでファイルアップロード時に発生したXSS誤検知の原因と対処方法
目次
こんにちは。堀部です。
今回は、AWS環境で運用しているWebアプリケーションにおいて、AWS WAFによるXSS誤検知が発生した事例についてまとめます。実際の運用の中で遭遇した事象をベースに、「なぜ誤検知が起きたのか」「どのように判断したのか」「最終的にどのように対応したのか」を整理しています。
AWS WAFを使っている方で、同様の事象に悩んでいる場合の参考になればと思います。
AWS WAFのXSS誤検知とは何か
まず前提として、AWS WAFはシグネチャベースでリクエストを検査し、攻撃と疑われるパターンを検知します。そのため、実際の攻撃でなくても「攻撃と疑われる文字列」が含まれているだけで検知されるケースがあります。
特にXSS対策ルールでは、以下のような文字列が検知対象になります。
- <script>
- <?(スクリプト開始タグに類似)
- HTMLタグ風の文字列
今回の事象も、この仕様に起因するものでした。
AWS WAFのファイルアップロード時に発生した事象
問題が発生したのは、ファイルアップロード機能です。ユーザーがファイルをアップロードした際、正常なリクエストであるにも関わらず、AWS WAFによってブロックされました。
ログを確認すると、以下の特徴がありました。
- リクエストボディ内のデータがXSSルールにヒット
- 検知された文字列は「<?」
- 対象はアップロードされたファイルのバイナリデータ
つまり、ファイルの中身として正常なバイナリデータが、XSS攻撃と誤認識されたという状況です。

AWS WAFでXSS誤検知が発生した原因
結論から言うと、原因は「バイナリデータ内の偶然の文字列一致」です。AWS WAFはリクエストボディを文字列として評価するため、ファイルの中身であっても例外ではありません。
今回のケースでは、以下の条件が重なりました。
- ファイル内に「<?」というバイト列が存在
- その文字列がXSS検知ルールに一致
- 文脈を考慮しないため攻撃と判断
さらに厄介だったのは再現性の低さです。ファイルの保存タイミングや内容によってバイナリが微妙に変化するため、毎回発生するわけではありませんでした。
誤検知として扱ってよいのかの判断
ここが最も重要なポイントです。
単純に「業務上問題ないから許可する」という判断は危険です。今回は以下の観点でリスク評価を行いました。
- アップロードファイルはブラウザで実行されるか
- HTMLとしてレンダリングされる可能性はあるか
- アプリケーション側で制御されているか
- ユーザー入力として再利用されるか
その結果、以下の仕様であることを確認しました。
- ファイルはダウンロード用途のみ
- ブラウザ上で実行されない
- HTMLとして描画されない
これにより、XSSとして成立するリスクは低いと判断しました。
AWS WAFのXSS誤検知への対応方法
最終的な対応として、該当ルールのアクションをBlockからCountへ変更しました。選択肢としては以下がありました。
- ルール除外
- ルール無効化
- Countモード
その中でCountモードを選んだ理由は以下です。
1. セキュリティレベルを維持したかった
完全に無効化すると、本来検知すべきXSSも見逃す可能性があります。
2. 除外条件の設計が難しい
バイナリ依存のため、特定条件での除外が現実的ではありませんでした。
3. まずは影響範囲を観測したい
Countにすることで、ブロックせずにログは取得できます。
対応後の運用ポイント
Countモードに変更した後は、継続的な監視が重要です。具体的には以下を確認しています。
- 検知頻度の把握
- 他のリクエストへの影響
- 想定外のパターンの有無
必要に応じて、以下のような追加対応も検討可能です。
- アップロードAPI単位での制御
- スコープダウン設定
- アプリ側の入力制御強化
AWS WAFのXSS誤検知に関するFAQ
Q. ルール除外はすぐに実施してもよい?
A. 推奨しません。セキュリティリスクの評価を先に行うべきです。
Q. Countモードに変更すれば安全?
A. ブロックはしないためリスクは残りますが、検知は継続されるため状況把握には有効です。
Q. なぜファイルでも検知される?
A. AWS WAFはバイナリも含めて文字列として評価するためです。
まとめ
今回の事象から得られた重要なポイントは以下です。
- バイナリデータでもXSS誤検知は発生する
- WAFは文脈を理解しない
- 判断はリスクベースで行う必要がある
- Countモードは有効な運用手段の1つ
AWS WAFを利用している場合、誤検知は避けて通れません。そのため、安易に除外するのではなく、観測と判断を繰り返しながらチューニングしていくことが重要です。
《関連記事》
シニアマネージャー Horibe 技術ブログを中心に小ネタを書いています。たまにはライフスタイルも書いてみようかな。


