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-%28v2.x%29#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.