自从我与 modsecurity 混在一起已经有几年了...
简单地安装具有默认规则的包是否会提供足够的验证来防止任何（好吧，说实话 - 我们最好希望是“大多数”）类型的 XSS？我的假设是否定的……即使我们只考虑 Type I - Reflected XSS。
那么核心规则集呢？是否足够防 XSS？
如果没有，缺少什么样的规则，我应该添加/自定义什么，也许是在每页的基础上？（呃……）
问题的最后一部分，重 AJAX 的应用程序呢？ModSecurity，尤其是 CRS，如何在不阻塞的情况下处理 AJAX 请求？我认为希望它实际上能够解析出 AJAX 并分别验证每个参数将是太希望了......
澄清一下，修复代码以删除所有 XSS，包括输入验证，尤其是上下文输出编码，当然是最好的方法，也是唯一的长期解决方案。
但是，我一直在寻找一个临时的“快速修复”，以暂时保护应用程序，同时他们去修复代码中的 XSS，并搜索更多...
您应该查看XSS Street-Fight (with ModSecurity) Blackhat preso
它概述了以下针对 XSS 的 ModSecurity 缓解策略：
我打算建议您查看 Ryan Barnett 的工作，但他已经回答了！
数据验证不足以防止 XSS，即使它是一个纯白名单。
必须在所有输出上识别不正确的输出处理。它们可能能够通过 ModSecurity 进行上下文修复，但当然这是架构中的错误位置——因为如果该内容发生任何变化——编码/转义将突然变得无用。Web 内容有很大的变化。
正确的答案是使用 ModSecurity 监控输出转义问题——并在其他地方实际修复 XSS 问题。
我最近听到的最好的方法之一是停止在服务器上构建 HTML。特别是，这将是一箭双雕：您可以解决 AJAX 的问题（例如基于 DOM 的 XSS）以及存储和反射的 XSS 问题。
但是，我强烈建议您查看OWASP ESAPI和OWASP ESAPI JS中的编码库。最好的补救建议来自上下文输出编码。修复 XSS 需要大量工作，但如果我们现在不修复这些问题，则值得考虑这些问题会持续更长时间并且会产生严重影响。
Mod Security 绝对是所有相关人员的出色工作。但是，不要期望只是“设置并忘记”。我们花了很多工作来微调安装以消除核心规则集中的误报。