由于现在写入这条规则,所以不太正确,因为这条规则存在一些问题。但是认为你得到了一般概念。
要解释什么是错的规则,因为它目前为需要解释的公平位:
一起来,用于定义规则的ModSecurity语法是由几部分组成:
- SecRule
- 或多个字段,以检查
- 值来检查这些领域为
- 采取的行动
你有两套零件2 & 3这是无效的。如果你想检查两件事你需要将两条规则链接在一起,我将在稍后展示一个例子。
接下来,您正在检查脚本标记的请求标题。这不是大多数XSS攻击存在的地方,你应该检查参数 - 尽管在下面进一步讨论XSS。
另外检查<script>
不是很彻底。例如,它很容易被<script type="text/javascript">
击败。或<SCRIPT>
(应添加t:lowercase
以忽略大小写)。或者通过转义可能由您的应用程序的某些部分处理的字符。
移动的,就没有必要指定@rx
操作为,如果没有其他经营者Given公司的暗示。虽然是没有坏处明确这是一个有点奇怪,你没有给它一个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提供页面并在服务器和粘贴之间进行操作。这被称为“基于DOM的XSS”和ModSecurity的是您的服务器上,然后它不能防止这些类型的XSS攻击。
进入了很多细节,但希望能帮助解释更多一点。我发现ModSecurity Handbook是ModSecurity尽管年龄大小的最佳资源。