我开始了解range(num-5, num) + range(num, num+5)和规则创建，所以说我知道网页应用中的网页容易受到跨网站脚本的攻击。为了论证，可以说page /blah.html容易出现XSS。
有问题的规则会是这样的吗？：
ModSecurity是否可以为该特定页面创建配置文件（或者甚至可以这样做？）或者更好地说是否可以为特定URL创建规则？
答案 0 :(得分：1)
不太正确，因为这条规则的一些问题正如现在所写的那样。但是你认为你得到了一般概念。
要解释规则有什么问题，因为它目前的情况需要相当多的解释：
首先，用于定义规则的ModSecurity语法由几个部分组成：
你有两套零件2＆amp; 3无效。如果你想检查你需要将两个规则链接在一起的两件事，我将在稍后展示一个例子。
接下来，您将检查脚本标记的请求标头。这不是大多数XSS攻击存在的地方，您应该检查参数 - 但请参阅下面有关XSS的进一步讨论。
同时检查<script>并不是很彻底。例如，它很容易被<script type="text/javascript">击败。或<SCRIPT>（应添加t:lowercase以忽略大小写）。或者通过转义可能由您的应用程序部分处理的字符。
接下来，如果没有给出其他运算符，则无需指定@rx运算符。虽然没有任何明显的伤害，但有点奇怪，你没有给blah但是为<script>位做了。
建议指定阶段而不是使用默认值（通常是阶段2）。在这种情况下，您需要第2阶段，即所有请求标题和请求正文部分都可用于处理，因此默认可能是正确的，但最好是明确的。
最后404是“找不到页面”的响应代码。 500或503可能是更好的回应。
因此，您的规则将更好地重写为：
SecRule REQUEST_URI "/blah.html" id:101,phase:2,msg: ‘XSS Attack’,severity:ERROR,deny,status:500,chain
SecRule ARGS "<script" "t:lowercase"
尽管如上所述，这仍然无法解决您为脚本标记进行的基本检查的所有方法。 OWASP Core Rule Set是一套免费的ModSecurity规则，它随着时间的推移而构建，并且其中包含一些您可以查看的XSS规则。虽然要警告他们的一些正则表达式会变得非常复杂！
ModSecurity作为更通用的检查也更好，所以想要保护这样的一个页面（虽然不是完全闻所未闻）是不寻常的。如果您知道某个页面容易受到特定攻击，那么通常最好对该页面或其处理方式进行编码以修复漏洞，而不是使用ModSecurity来处理它。在源头修复问题而不是修补问题，在可能的情况下始终是一个很好的口头禅。例如，您可以通过从输入中清理和转义输入HTML代码来实现此目的。
在处理更正确的长期修复时，使用ModSecurity规则快速修复通常是一个很好的短期解决方案 - 这称为“虚拟修补”。虽然有时他们倾向于成为长期解决方案，但没有人有时间来解决核心问题。
如果您想要对任何页面的任何参数中的“脚本”进行更通用的检查，那么这就是ModSecurity更常用的内容。这有助于在正确编码的应用程序中添加额外的保护，作为备份和额外的防线。例如，如果有人通过清理用户输入而忘记保护一页中的一页。
因此，最好放弃此规则的第一部分，只需按照以下步骤检查所有页面：
SecRule ARGS "<script" id:101,phase:2,msg: ‘XSS Attack’,severity:ERROR,deny,status:500,"t:lowercase"
最后XSS is quite a complex subject。在这里，我假设您要检查请求页面时发送的参数。因此，如果它使用用户输入来构建页面并显示输入，那么您希望保护它 - 称为“反射XSS”。但是还有其他XSS漏洞。例如：
如果错误数据存储在数据库中并用于构建页面。被称为“存储的XSS”。要解决此问题，您可能需要检查阶段4中RESPONSE_BODY参数中页面返回的结果，而不是第2阶段中ARGS参数中发送到页面的输入。尽管处理响应页面通常较慢且资源密集程度较高对于通常要小得多的请求。
您可以在不通过服务器的情况下执行XSS，例如如果加载外部内容，如第三方评论系统。或者页面通过http提供，并在服务器和cling之间进行操作。这被称为“基于DOM的XSS”，并且由于ModSecurity在您的服务器上，因此无法防范这些类型的XSS攻击。
在那里已经进入了很多细节，但希望有助于解释一下。我发现ModSecurity Handbook是教你自己ModSecurity的最佳资源，尽管它已经很久了。