from：https://www.freebuf.com/articles/web/258952.html
OWASP Core Rule Set (CRS)
https://www.modsecurity.org/CRS/Documentation/
https://github.com/SpiderLabs/owasp-modsecurity-crs/releases crs规则更新
crs 官网 https://coreruleset.org/
ModSecurity依赖于可从Google GSB API http://code.google.com/apis/safebrowsing/获取的免费Google安全浏览数据库。
curl "http://cert.placuna.cn/?<IMG SRC=’vbscript:msgbox(“XSS”)’></STYLE><UL><LI>"
Phase Request Headers
Rules in this phase are processed immediately after Apache completes reading the request headers (post-read-request phase). At this point the request body has not been read yet, meaning not all request arguments are available.
Phase Request Body
This is the general-purpose input analysis phase. Most of the application-oriented rules should go here. In this phase you are guaranteed to have received the request arguments (provided the request body has been read). ModSecurity supports three encoding types for the request body phase:
- application/x-www-form-urlencoded - used to transfer form data
- multipart/form-data - used for file transfers
- text/xml - used for passing XML data
Other encodings are not used by most web applications.
Note : In order to access the Request Body phase data, you must have SecRequestBodyAccess set to On.
Phase Response Headers
This phase takes place just before response headers are sent back to the client. Run here if you want to observe the response before that happens, and if you want to use the response headers to determine if you want to buffer the response body. Note that some response status codes (such as 404) are handled earlier in the request cycle by Apache and my not be able to be triggered as expected. Additionally, there are some response headers that are added by Apache at a later hook (such as Date, Server and Connection) that we would not be able to trigger on or sanitize. This should work appropriately in a proxy setup or within phase:5 (logging).
Phase Response Body
This is the general-purpose output analysis phase. At this point you can run rules against the response body (provided it was buffered, of course). This is the phase where you would want to inspect the outbound HTML for information disclosure, error messages or failed authentication text.
Note : In order to access the Response Body phase data, you must have SecResponseBodyAccess set to On
Phase Logging
This phase is run just before logging takes place. The rules placed into this phase can only affect how the logging is performed. This phase can be used to inspect the error messages logged by Apache. You cannot deny/block connections in this phase as it is too late. This phase also allows for inspection of other response headers that weren't available during phase:3 or phase:4. Note that you must be careful not to inherit a disruptive action into a rule in this phase as this is a configuration error in ModSecurity 2.5.0 and later versions
crs规则详细说明：
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#query_string
https://github.com/sqlmapproject/sqlmap/wiki/Usage
crs规则变量说明：
https://blog.csdn.net/zhao_s/article/details/51745050
https://www.jianshu.com/p/d22f3914d153
SecHttpBlKey
描述：配置用户注册的Honeypot Project HTTP BL API密钥以与@rbl一起使用。
句法： SecHttpBlKey [12 char access key]
用法示例： SecHttpBlKey whdkfieyhtnf
SecInterceptOnError
描述：配置规则处理失败时的响应方式。
句法： SecInterceptOnError On|Off
SecReadStateLimit
说明：建立每个IP地址限制，允许在SERVER_BUSY_READ状态下允许的连接数。
句法： SecReadStateLimit LIMIT
用法示例：SecReadStateLimit 50
范围：主要
版本：2.5.13，截至v2.8.0已废弃。
在libModSecurity上受支持：否（已弃用）
默认值： 0（无限制）
对于v2.8.0或最新版本，请参阅SecConnReadStateLimit。
SecConnReadStateLimit
说明：建立每个IP地址限制，允许在SERVER_BUSY_READ状态下允许的连接数。
句法： SecConnReadStateLimit LIMIT OPTIONAL_IP_MATCH_OPERATOR
用法示例：SecConnReadStateLimit 50 "!@ipMatch 127.0.0.1"
范围：主要
版本：v2.8.0-2.9.x（仅限Apache）
libModSecurity支持： TBI
默认值： 0（无限制）
此措施对于来自单个IP地址的Slowloris式攻击是有效的，但对于通过缓慢发送请求正文内容而起作用的修改攻击可能不太好。这是因为一旦读取了请求头，Apache就会将状态切换到SERVER_BUSY_WRITE。作为替代方案，考虑mod_reqtimeout（Apache的2.2.15部分），预计对两种攻击类型都有效。请参阅博客文章，了解缓解缓慢的DoS攻击 - http://blog.spiderlabs.com/2010/11/advanced-topic-of-the-week-mitigating-slow-http-dos-attacks.html。v2.8.0和newest支持@ipMatch，@ ipMatchF和@ipMatchFromFile运算符及其负数（例如！@ipMatch），这些运算符用于创建可疑或白名单。当通知可疑列表时，将仅过滤属于该列表的IP。通过使用SecConnReadStateLimit的多个定义，可以组合使用可疑和白名单，但请注意，限制将始终由其后继者覆盖。
注意：此功能仅适用于Apache。
注意2：在使用此功能之前，请确保参考手册#secconnengine已打开。
SecRequestBodyAccess
描述：配置ModSecurity是否缓冲和处理请求主体。
句法： SecRequestBodyAccess On|Off
用法示例：SecRequestBodyAccess On
SecRequestBodyInMemoryLimit
描述：配置ModSecurity将在内存中存储的最大请求主体大小。
句法： SecRequestBodyInMemoryLimit LIMIT_IN_BYTES
用法示例： SecRequestBodyInMemoryLimit 131072
SecRequestBodyLimit
描述：配置ModSecurity接受缓冲的最大请求体大小。
句法： SecRequestBodyLimit LIMIT_IN_BYTES
用法示例： SecRequestBodyLimit 134217728
SecRequestBodyNoFilesLimit
描述：配置ModSecurity接受缓冲的最大请求体大小，不包括请求中传输的任何文件的大小。当某人发送非常大的请求主体时，此指令可用于降低对DoS攻击的敏感性。需要文件上载的Web应用程序必须将SecRequestBodyLimit配置为较高的值，但由于大型文件流式传输到磁盘，因此文件上载不会增加内存消耗。但是，某人仍然可以利用大的请求正文限制并发送大型正文的非上传请求。该指令消除了这个漏洞。
句法： SecRequestBodyNoFilesLimit NUMBER_IN_BYTES
用法示例： SecRequestBodyNoFilesLimit 131072
SecRequestBodyLimitAction
描述：控制遇到使用SecRequestBodyLimit配置的请求正文限制时发生的情况
句法： SecRequestBodyLimitAction Reject|ProcessPartial
用法示例： SecRequestBodyLimitAction ProcessPartial
SecResponseBodyLimit
描述：配置将被接受用于缓冲的最大响应体大小。
句法： SecResponseBodyLimit LIMIT_IN_BYTES
用法示例： SecResponseBodyLimit 524228
SecResponseBodyLimitAction
描述：控制在遇到使用SecResponseBodyLimit配置的响应正文限制时发生的情况。
句法： SecResponseBodyLimitAction Reject|ProcessPartial
用法示例： SecResponseBodyLimitAction ProcessPartial
SecResponseBodyMimeType
描述：配置响应主体缓冲要考虑的MIME类型。
句法： SecResponseBodyMimeType MIMETYPE MIMETYPE ...
用法示例：SecResponseBodyMimeType text/plain text/html text/xml
SecResponseBodyMimeTypesClear
描述：清除为响应主体缓冲考虑的MIME类型列表，允许您从头开始填充列表。
句法： SecResponseBodyMimeTypesClear
用法示例： SecResponseBodyMimeTypesClear
SecResponseBodyAccess
描述：配置是否要缓冲响应主体。
句法： SecResponseBodyAccess On|Off
用法示例： SecResponseBodyAccess On
SecRule
描述：创建一个规则，使用选定的运算符分析所选变量。
句法： SecRule VARIABLES OPERATOR [ACTIONS]
用法示例： SecRule ARGS "@rx attack" "phase:1,log,deny,id:1"
SecRuleInheritance
描述：配置当前上下文是否将从父上下文继承规则。
句法： SecRuleInheritance On|Off
用法示例： SecRuleInheritance Off
SecRuleEngine
描述：配置规则引擎。
句法： SecRuleEngine On|Off|DetectionOnly
用法示例： SecRuleEngine On
可能的值是：
- 开：流程规则
- 关：不处理规则
- DetectionOnly：处理规则但从不执行任何破坏性操作（阻止，拒绝，删除，允许，代理和重定向）
SecRulePerfTime
描述：设置规则的性能阈值。至少花费定义时间的规则将以标识id = usec，逗号分隔的格式记录到审计日志H部分中作为Rules-Performance-Info。
句法： SecRulePerfTime USECS
用法示例： SecRulePerfTime 1000
SecRuleRemoveById
描述：从当前配置上下文中删除匹配规则。
句法： SecRuleRemoveById ID ID RANGE ...
用法示例： SecRuleRemoveByID 1 2 "9000-9010"
SecRuleRemoveByMsg
描述：从当前配置上下文中删除匹配规则。
句法： SecRuleRemoveByMsg REGEX
用法示例： SecRuleRemoveByMsg "FAIL"
ARGS是一个集合，可以单独使用（表示所有参数，包括POST Payload），带有静态参数（匹配带有该名称的参数），或带有正则表达式（匹配所有带有与正则表达式匹配的名称的参数） 。要仅查看查询字符串或正文参数，请参阅ARGS_GET和ARGS_POST集合。
一些变量实际上是集合，它们在运行时扩展为更多变量。以下示例将检查所有请求参数：
SecRule ARGS dirty "id:7"
但是，有时您只想查看集合的某些部分。这可以通过选择运算符（冒号）来实现。以下示例仅查看名为p的参数（请注意，通常，请求可以包含多个具有相同名称的参数）：
SecRule ARGS:p dirty "id:8"
也可以指定排除。下面将检查单词dirty的所有请求参数，除了名为z的那些（同样，可以有零个或多个名为z的参数）：
SecRule ARGS|!ARGS:z dirty "id:9"
有一个特殊的运算符，允许您计算集合中有多少变量。如果请求中的参数多于零，则会触发以下规则（暂时忽略第二个参数）：
SecRule &ARGS !^0$ "id:10"
有时您需要查看一组参数，每个参数的名称略有不同。在这种情况下，您可以在选择运算符本身中指定正则表达式。以下规则将查看名称以id_开头的所有参数：
SecRule ARGS:/^id_/ dirty "id:11"
ARGS_COMBINED_SIZE
包含所有请求参数的组合大小。文件将从计算中排除。例如，此变量可用于创建规则以确保参数数据的总大小低于特定阈值。以下规则检测到参数长度超过2500字节的请求：
SecRule ARGS_COMBINED_SIZE "@gt 2500" "id:12"
ARGS_GET
ARGS_GET类似于ARGS，但仅包含查询字符串参数。
ARGS_GET_NAMES
ARGS_GET_NAMES类似于ARGS_NAMES，但仅包含查询字符串参数的名称。
ARGS_NAMES
包含所有请求参数名称。您可以搜索要检查的特定参数名称。在积极的策略方案中，您还可以将（使用带有感叹号的反转规则）列入白名单（仅使用受感知的参数名称）。此示例规则仅允许两个参数名称：p和a：
SecRule ARGS_NAMES "!^(p|a)$" "id:13"
ARGS_POST
ARGS_POST is similar to ARGS, but only contains arguments from the POST body.
ARGS_POST_NAMES
ARGS_POST_NAMES is similar to ARGS_NAMES, but contains only the names of request body parameters.
