diff --git a/doc/modsecurity2-apache-reference.xml b/doc/modsecurity2-apache-reference.xml index 0cc57332..b7105862 100644 --- a/doc/modsecurity2-apache-reference.xml +++ b/doc/modsecurity2-apache-reference.xml @@ -2077,7 +2077,8 @@ ServerAlias www.app2.com parent contexts. Syntax: SecRuleRemoveById RULEID + moreinfo="none">SecRuleUpdateActionById RULEID + ACTIONLIST Example Usage: SecRuleRemoveByID 1 2 "9000-9010" @@ -2360,12 +2361,12 @@ SecRuleUpdateActionById 12345 "t:compressWhitespace,deny,status:403,msg:'A new m Dependencies/Notes: This feature is not available on operating systems not supporting octal file modes. The - default mode (0600) only grants read/write access to the account - writing the file. If access from another account is needed (using clamd - is a good example), then this directive may be required. However, use - this directive with caution to avoid exposing potentially sensitive - data to unauthorized users. Using the value "default" will revert back - to the default setting. + default mode (0600) only grants read/write access to the account writing + the file. If access from another account is needed (using clamd is a + good example), then this directive may be required. However, use this + directive with caution to avoid exposing potentially sensitive data to + unauthorized users. Using the value "default" will revert back to the + default setting.
@@ -2488,23 +2489,23 @@ SecAction setsid:%{REQUEST_COOKIES.PHPSESSID} - Request headers (REQUEST_HEADERS) + Request headers (REQUEST_HEADERS) - Request body (REQUEST_BODY) + Request body (REQUEST_BODY) - Response headers (RESPONSE_HEADERS) + Response headers (RESPONSE_HEADERS) - Response body (RESPONSE_BODY) + Response body (RESPONSE_BODY) - Logging (LOGGING) + Logging (LOGGING) @@ -3150,7 +3151,8 @@ SecRule XML "@validateDTD /opt/apache-frontend/conf/xml.dtd" Please note that anti-evasion transformations are not applied to this variable by default. REQUEST_BASENAME will - recognise both / and \ as path separators. + recognise both / and \ as path + separators.
@@ -3158,16 +3160,25 @@ SecRule XML "@validateDTD /opt/apache-frontend/conf/xml.dtd" <literal moreinfo="none">REQUEST_BODY</literal> This variable holds the data in the request body (including - POST_PAYLOAD data). REQUEST_BODY should be used if the original order of - the arguments is important (ARGS should be used in all other cases). + POST_PAYLOAD data). REQUEST_BODY + should be used if the original order of the arguments is important + (ARGS should be used in all other cases). Example: SecRule REQUEST_BODY "^username=\w{25,}\&password=\w{25,}\&Submit\=login$" - Note - - This variable is only available if the content type is - application/x-www-form-urlencoded. + + This variable is only available if the + URLENCODED request body processor parsed a request + body. This will occur by default when an + application/x-www-form-urlencoded is detected, or + the URLENCODED request body parser is forced. As of + 2.5.7 it is possible to force the presence of the + REQUEST_BODY variable, but only when there is no + request body processor defined, using the + ctl:forceRequestBodyVariable option in the + REQUEST_HEADERS phase. +
@@ -4411,7 +4422,8 @@ SecRule REQUEST_CONTENT_TYPE ^text/xml nolog,pass,ctl:requestBodyProce - forceRequestBodyVariable + forceRequestBodyVariable @@ -4437,20 +4449,22 @@ SecRule REQUEST_CONTENT_TYPE ^text/xml nolog,pass,ctl:requestBodyProce With the exception of requestBodyProcessor and - forceRequestBodyVariable, each configuration option corresponds to - one configuration directive and the usage is identical. + forceRequestBodyVariable, each configuration option + corresponds to one configuration directive and the usage is + identical. - The requestBodyProcessor option allows you to configure the - request body processor. By default ModSecurity will use the URLENCODED and - MULTIPART processors to process an The requestBodyProcessor option allows you to + configure the request body processor. By default ModSecurity will use + the URLENCODED and MULTIPART processors to process an application/x-www-form-urlencoded and a - multipart/form-data body, - respectively. A third processor, XML, is also supported, but it is never - used implicitly. Instead you must tell ModSecurity to use it by placing - a few rules in the REQUEST_HEADERS - processing phase. After the request body was processed as XML you will - be able to use the XML-related features to inspect it. + multipart/form-data bodies, + respectively. A third processor, XML, is also + supported, but it is never used implicitly. Instead you must tell + ModSecurity to use it by placing a few rules in the REQUEST_HEADERS processing phase. After the + request body was processed as XML you will be able to use the + XML-related features to inspect it. Request body processors will not interrupt a transaction if an error occurs during parsing. Instead they will set variablesctl:requestBodyProce moreinfo="none">REQUEST_BODY phase and an appropriate action taken. - The forceRequestBodyVariable option allows you to configure the - REQUEST_BODY variable to be set even if the request body was not parsed. - This allows inspection of REQUEST_BODY even when no parser is used. - + The forceRequestBodyVariable option allows you + to configure the REQUEST_BODY variable to be set when + there is no request body processor configured. This allows for + inspection of request bodies of unknown types.
@@ -4521,10 +4535,10 @@ SecRule IP:AUTH_ATTEMPT "@gt 25" \ Note This action is currently not available on Windows based builds. - This action is extremely useful when responding to both Brute - Force and Denial of Service attacks in that, in both cases, you want to - minimize both the network bandwidth and the data returned to the client. - This action causes error message to appear in the log "(9)Bad file + This action is extremely useful when responding to both Brute Force and + Denial of Service attacks in that, in both cases, you want to minimize + both the network bandwidth and the data returned to the client. This + action causes error message to appear in the log "(9)Bad file descriptor: core_output_filter: writing data to the network"