デフォルトのModSecurityはXSSから十分に保護しますか？
私がmodsecurityをいじってから数年になります...
デフォルトのルールを使用してパッケージをインストールするだけで、十分な検証が行われ、（正直に言えば、正直に言えば、「最も多くの」）XSSのタイプを防ぐことができますか？私の仮定はノーです...そして私たちがタイプI-反映されたXSSだけを考慮したとしても。
Core Rule Set はどうですか？ XSSに十分対応できますか？
そうでない場合、不足しているルールの種類、およびページごとに追加/カスタマイズする必要があるものは何ですか？ （うーん...）
質問の最後の部分、AJAXが重いアプリについてはどうですか？ ModSecurity、特にCRSは、AJAXリクエストをブロックせずにどのように処理しますか？実際にAJAXを解析して検証できることを期待して各パラメータは個別にtooになるでしょう...
明確にするために、入力検証と特にコンテキスト出力エンコーディングを含むすべてのXSSを削除するようにコードを修正することがもちろん最善の方法であり、実際には長期的なソリューションのみ。
しかし、私は一時的に「迅速な修正」を探していました。一時的に「迅速な修正」を行い、アプリを保護するために適切な場所にポップします。コードで、さらに検索...
XSS Street-Fight（with ModSecurity）Blackhat preso を確認してください。
XSSの次のModSecurity緩和戦略の概要を示します。
- 入力検証（ホワイトリスト/ブラックリストフィルタリング）
- 一般的な攻撃ペイロードの検出
- 不適切な出力処理の欠陥の特定（動的汚染伝播）
- アプリケーション応答プロファイリング（スクリプト/ iFrameの数の監視）
- JavaScriptサンドボックスインジェクション（ModSecurityのコンテンツインジェクション機能）
ライアン・バーネットの作品をチェックすることをお勧めしましたが、彼はすでに答えました！
純粋なホワイトリストであっても、XSSを防ぐにはデータの検証だけでは不十分です。
不適切な出力処理の識別は、すべての出力で発生する必要があります。それらはModSecurityで状況に応じて修正できるかもしれませんが、確かにこれはそれを行うアーキテクチャの間違った場所です-そのコンテンツに関して何か変更があると、エンコード/エスケープが突然役に立たなくなるためです。 Webコンテンツには、大きく変化する方法があります。
正解は、ModSecurityを使用して出力エスケープ問題を監視することです。実際には、XSS問題を別の場所で修正します。
私が最近聞いた最良のアプローチの1つは サーバーでのHTMLの構築を停止する です。特に、これは1つの石で2羽の鳥を殺します。AJAX（たとえば、DOMベースのXSS））の問題と、保存および反映されたXSSの問題を解決できます。
ただし、 OWASP ESAPI および OWASP ESAPI JS のエンコーディングライブラリを確認することを強くお勧めします。最良の修正アドバイスは、コンテキスト出力エンコーディングから得られます。 XSSの修正は多くの作業ですが、これらの問題をより長く持続し、今は修正しない場合は深刻な影響があると考えることは価値があります。
Mod Securityは関係者全員による絶対に素晴らしい仕事です。ただし、単に「設定して忘れる」ことを期待しないでください。コアルールセットから誤検知を取り除くために、インストールを微調整するのに多くの作業が必要でした。
おそらくそうではありませんが、自分でテストする必要があります。 Sitewatch 、 Acunetix 、およびW3AFはすべて無料であり、XSSのアプリケーションをテストします。さらに、攻撃者はXSSのペイロードを構築して、mod_secuirtyをバイパスすることができます。インスタンスには、W3AF用のMod_Securityバイパスモジュールがあります。したがって、このようなWAFの使用は Defense in Depth アプローチではありません。