Modsecurity 使用特定 URL 的规则创建配置文件
Modsecurity create config file with rules for specific URL
我开始学习 ModSecurity 和规则创建，所以说我知道网络应用程序中的页面容易受到跨站点脚本攻击。为了争论起见，假设页面 /blah.html 容易受到 XSS 攻击。
有问题的规则看起来像这样吗？：
SecRule ARGS|REQUEST_URI "blah" REQUEST_HEADERS “@rx <script>” id:101,msg: ‘XSS Attack’,severity:ERROR,deny,status:404
是否可以为该特定页面创建配置文件（或者这样做是否明智？）或者更好地说是否可以为特定 URL 创建规则？
不太正确，因为现在编写的这条规则有一些错误。但是认为您已经掌握了一般概念。
要解释目前的规则有什么问题需要相当多的解释：
首先，用于定义规则的 ModSecurity 语法由几个部分组成：
- 安全规则
- 要检查的一个或多个字段
- 检查这些字段的值
- 要采取的行动
您有两组无效的第 2 部分和第 3 部分。如果你想检查 2 件事，你需要将两个规则链接在一起，我将在后面展示一个例子。
接下来您要检查脚本标记的请求 Headers。这不是大多数 XSS 攻击存在的地方，您应该检查参数 - 尽管请参阅下面关于 XSS 的进一步讨论。
同时检查 <script> 不是很彻底。例如，它很容易被 <script type="text/javascript"> 打败。或 <SCRIPT>（应添加 t:lowercase 以忽略大小写）。或者通过转义可能由您的应用程序部分处理的字符。
继续，如果没有给出其他运算符，则无需指定 @rx 运算符，因为这是隐含的。虽然明确无害，但您没有为 blah 提供它但为 <script> 位提供它有点奇怪。
还建议指定一个阶段而不是使用默认值（通常是阶段 2）。在这种情况下，您需要阶段 2，即所有 Request Headers 和 Request Body 片段都可用于处理时，因此默认值可能是正确的，但最好是明确的。
最后 404 是 "page not found" 响应代码。此处回复 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 规则快速修复通常是一个很好的短期解决方案，而您正在处理更正确的长期修复 - 这称为 "virtual patching"。尽管有时他们倾向于成为长期解决方案，但因为没有人有时间解决核心问题。
但是，如果您想在 any 页面的 any 参数中对 "script" 进行更通用的检查，那么这就是 ModSecurity更常用于。这有助于为正确编码的应用程序中已经应该存在的内容添加额外的保护，作为备份和额外的防线。例如，如果有人忘记通过清理用户输入来保护一页中的一页。
因此最好删除此规则的第一部分，只使用以下内容来检查所有页面：
SecRule ARGS "<script" id:101,phase:2,msg: ‘XSS Attack’,severity:ERROR,deny,status:500,"t:lowercase"
终于XSS is quite a complex subject。在这里，我假设您想检查请求页面时发送的参数。因此，如果它使用用户输入来构建页面并显示输入，那么您需要保护它 - 称为 "reflective XSS." 但是还有其他 XSS 漏洞。例如：
如果坏数据存储在数据库中并用于构建页面。被称为"stored XSS"。要解决此问题，您可能需要检查阶段 4 中 RESPONSE_BODY 参数中页面返回的结果，而不是阶段 2 中 ARGS 参数中发送到页面的输入。虽然处理响应页面通常较慢并且与通常小得多的请求相比，资源占用更多。
您也许可以在不通过服务器的情况下执行 XSS，例如如果加载第三方评论系统等外部内容。或者页面通过 http 提供并在服务器和 cling 之间进行操作。这被称为 "DOM-based XSS"，由于 ModSecurity 在您的服务器上，因此它无法防止这些类型的 XSS 攻击。
那里介绍了很多细节，但希望能帮助您解释更多。我发现 ModSecurity Handbook 是自学 ModSecurity 的最佳资源，尽管它很老了。
我开始学习 ModSecurity 和规则创建，所以说我知道网络应用程序中的页面容易受到跨站点脚本攻击。为了争论起见，假设页面 /blah.html 容易受到 XSS 攻击。
有问题的规则看起来像这样吗？：
SecRule ARGS|REQUEST_URI "blah" REQUEST_HEADERS “@rx <script>” id:101,msg: ‘XSS Attack’,severity:ERROR,deny,status:404
是否可以为该特定页面创建配置文件（或者这样做是否明智？）或者更好地说是否可以为特定 URL 创建规则？
不太正确，因为现在编写的这条规则有一些错误。但是认为您已经掌握了一般概念。
要解释目前的规则有什么问题需要相当多的解释：
首先，用于定义规则的 ModSecurity 语法由几个部分组成：
- 安全规则
- 要检查的一个或多个字段
- 检查这些字段的值
- 要采取的行动
您有两组无效的第 2 部分和第 3 部分。如果你想检查 2 件事，你需要将两个规则链接在一起，我将在后面展示一个例子。
接下来您要检查脚本标记的请求 Headers。这不是大多数 XSS 攻击存在的地方，您应该检查参数 - 尽管请参阅下面关于 XSS 的进一步讨论。
同时检查 <script> 不是很彻底。例如，它很容易被 <script type="text/javascript"> 打败。或 <SCRIPT>（应添加 t:lowercase 以忽略大小写）。或者通过转义可能由您的应用程序部分处理的字符。
继续，如果没有给出其他运算符，则无需指定 @rx 运算符，因为这是隐含的。虽然明确无害，但您没有为 blah 提供它但为 <script> 位提供它有点奇怪。
还建议指定一个阶段而不是使用默认值（通常是阶段 2）。在这种情况下，您需要阶段 2，即所有 Request Headers 和 Request Body 片段都可用于处理时，因此默认值可能是正确的，但最好是明确的。
最后 404 是 "page not found" 响应代码。此处回复 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 规则快速修复通常是一个很好的短期解决方案，而您正在处理更正确的长期修复 - 这称为 "virtual patching"。尽管有时他们倾向于成为长期解决方案，但因为没有人有时间解决核心问题。
但是，如果您想在 any 页面的 any 参数中对 "script" 进行更通用的检查，那么这就是 ModSecurity更常用于。这有助于为正确编码的应用程序中已经应该存在的内容添加额外的保护，作为备份和额外的防线。例如，如果有人忘记通过清理用户输入来保护一页中的一页。
因此最好删除此规则的第一部分，只使用以下内容来检查所有页面：
SecRule ARGS "<script" id:101,phase:2,msg: ‘XSS Attack’,severity:ERROR,deny,status:500,"t:lowercase"
终于XSS is quite a complex subject。在这里，我假设您想检查请求页面时发送的参数。因此，如果它使用用户输入来构建页面并显示输入，那么您需要保护它 - 称为 "reflective XSS." 但是还有其他 XSS 漏洞。例如：
如果坏数据存储在数据库中并用于构建页面。被称为"stored XSS"。要解决此问题，您可能需要检查阶段 4 中 RESPONSE_BODY 参数中页面返回的结果，而不是阶段 2 中 ARGS 参数中发送到页面的输入。虽然处理响应页面通常较慢并且与通常小得多的请求相比，资源占用更多。
您也许可以在不通过服务器的情况下执行 XSS，例如如果加载第三方评论系统等外部内容。或者页面通过 http 提供并在服务器和 cling 之间进行操作。这被称为 "DOM-based XSS"，由于 ModSecurity 在您的服务器上，因此它无法防止这些类型的 XSS 攻击。
那里介绍了很多细节，但希望能帮助您解释更多。我发现 ModSecurity Handbook 是自学 ModSecurity 的最佳资源，尽管它很老了。