Webアプリケーションファイアウォールの反XSSルールはビジネスロジックを壊しますか？
MOOCのWebアプリケーションファイアウォールについて読みましたが、提供されている例では、WAFが?user=<scriptのようなリクエストを除外して、潜在的なXSS攻撃を回避できるようになっています。
しかし、アプリケーションのWebページが（IDベースではなく）view_user?name=...のようなかなりの方法でユーザーのプロファイルを表示できるとしたらどうでしょう。登録フォームなどで名前を<scriptに設定すると、ページが正当にview_user?name=<scriptになり、WAFが拒否するため、誰も私のプロフィールを見ることができなくなります。
このようなユーザー名は奇妙に聞こえますが、一部のアプリケーションではプロファイルにアクセスできないようにすることは有利です。それらを編集/禁止するためにユーザーのページにアクセスする必要があるフォーラムなど.
より一般的に言えば、ビジネスロジックを破壊するWAFルールの副作用を回避できますか？どうやって？
一般的な意味で、WAFは歴史的に悪意のあるものとして悪名が高く、非ブロッキングモードのときに正当な要求に対してアラートを発行し、アプリケーションのエッジケースが破損すると、非本番環境でのブロックモードの再現が困難または不可能になります。
その結果、全体的なスペースは、実際にはアプリケーションの責任であるシグネチャや細かいリクエスト固有のアラートから進化しており、レピュテーション分析、統計的異常検出、および攻撃者の行動に関するプールされたインテリジェンスの提供へと移行しています。 。