diff --git a/doc/modsecurity2-apache-reference.xml b/doc/modsecurity2-apache-reference.xml index ea471ac2..0b9a0259 100644 --- a/doc/modsecurity2-apache-reference.xml +++ b/doc/modsecurity2-apache-reference.xml @@ -1,10 +1,12 @@ +
<trademark class="registered">ModSecurity</trademark> Reference Manual - Version 2.5.7-dev1 (August 15, 2008) + Version 2.5.7-dev1 (August 27, 2008) 2004-2008 @@ -648,8 +650,11 @@ SecAuditLogStorageDir logs/audit
<literal>SecAuditLogParts</literal> - Description: Defines the path to the main - audit log file. + Description: Defines which part of each + transaction are going to be recorded in audit log. Each part is assigned + a single letter. If a letter appears in the list then the equivalent + part of each transactions will be recorded. See below for the list of + all parts. Syntax: SecAuditLogParts PARTS @@ -1192,21 +1197,31 @@ SecAuditLogStorageDir logs/audit Version: 2.0.0 Dependencies/Notes: Rules following a - SecDefaultAction directive will inherit this setting unless a specific - action is specified for an individual rule or until another - SecDefaultAction is specified. Take special note that in the logging - disruptive actions are not allowed, but this can inadvertently be - inherited using a disruptive action in SecDefaultAction. + SecDefaultAction directive will inherit this setting + unless a specific action is specified for an individual rule or until + another SecDefaultAction is specified. Take special + note that in the logging disruptive actions are not allowed, but this + can inadvertently be inherited using a disruptive action in + SecDefaultAction. The default value is minimal (differing from previous versions): SecDefaultAction phase:2,log,auditlog,pass - Note + + SecDefaultAction must specify a disruptive + action and a processing phase and cannot contain metadata + actions. + - SecDefaultAction must specify a disruptive action and a processing - phase and cannot contain metadata actions. + + SecDefaultAction is not + inherited across configuration contexts. (For an example of why this + may be a problem for you, read the following ModSecurity Blog entry + http://blog.modsecurity.org/2008/07/modsecurity-tri.html). +
@@ -1283,11 +1298,12 @@ SecAuditLogStorageDir logs/audit <literal>SecMarker</literal> Description: Adds a fixed rule marker in the - ruleset to be used as a target in a skipAfter - action. + ruleset to be used as a target in a skipAfter action. + A SecMarker directive essentially creates a rule that + does nothing and whose only purpose it to carry the given ID. Syntax: SecMarker - id + ID Example Usage: SecMarker 9999 @@ -1309,7 +1325,8 @@ SecRule &REQUEST_HEADERS:Host "@eq 0" \ "deny,log,status:400,id:08,severity:4,msg:'Missing a Host Header'" SecRule &REQUEST_HEADERS:Accept "@eq 0" \ "log,deny,log,status:400,id:15,msg:'Request Missing an Accept Header'" -SecMarker 99 + +SecMarker 99
@@ -1793,22 +1810,85 @@ SecResponseBodyLimit 524288
+
+ Collections + + A variable can contain one or many pieces of data, depending on + the nature of the variable and the way it is used. We've seen examples + of both approaches in the previous section. When a variable can + contain more than one value we refer to it as a + collection. + + Collections are always expanded before a rule is run. For + example, the following rule: + + SecRule ARGS dirty + + will be expanded to: + + SecRule ARGS:p dirty +SecRule ARGS:q dirty + + in a requests that has only two parameters, named + p and q. + + Collections come in several flavours: + + + + Read-only + + + Created at runtime using transaction data. For example: + ARGS (contains a list of all request + parameter values) and REQUEST_HEADERS + (contains a list of all request header values). + + + + + Transient Read/Write + + + The TX collection is created (empty) + for every transaction. Rules can read from it and write to it + (using the setvar action, for example), but + the information stored in this collection will not survive the + end of transaction. + + + + + Persistent Read/Write + + + There are several collections that can be written to, but + which are persisted to the storage backend. These collections + are used to track clients across transactions. Examples of + collections that fall into this type are IP, + SESSION and USER. + + + +
+
Operators in rules In the simplest possible case you will use a regular expression pattern as the second rule parameter. This is what we've done in the examples above. If you do this ModSecurity assumes you want to use the - rx operator. You can explicitly - specify the operator you want to use by using @ as the first character in the second rule + rx (regular expression) operator. + You can also explicitly specify the operator you want to use by using + @, followed by the name of an + operator, at the beginning of the second SecRule parameter: SecRule ARGS "@rx dirty" Note how we had to use double quotes to delimit the second rule - parameter. This is because the second parameter now has a whitespace - in it. Any number of whitespace characters can follow the name of the + parameter. This is because the second parameter now has whitespace in + it. Any number of whitespace characters can follow the name of the operator. If there are any non-whitespace characters there, they will all be treated as a special parameter to the operator. In the case of the regular expression operator the special parameter is the pattern @@ -1820,6 +1900,40 @@ SecResponseBodyLimit 524288 SecRule &ARGS "!@rx ^0$"
+
+ Operator negation + + Operator results can be negated by using an exclamation mark at + the beginning of the second parameter. The following rule matches if + the word dirty does not appear + in the User-Agent request header: + + SecRule REQUEST_HEADERS:User-Agent !dirty + + You can use the exclamation mark in combination with any + parameter. If you do, the exclamation mark needs to go first, followed + by the explicit operator reference. The following rule has the same + effect as the previous example: + + SecRule REQUEST_HEADERS:User-Agent "!@rx dirty" + + If you need to use negation in a rule that is going to be + applied to several variables then it may not be immediately clear what + will happen. Consider the following example: + + SecRule ARGS:p|ARGS:q !dirty + + The above rule is identical to: + + SecRule ARGS:p !dirty +SecRule ARGS:q !dirty + + + Negation is applied to operations against individual + operations, not agains the entire variable list. + +
+
Actions in rules @@ -1897,6 +2011,18 @@ ServerAlias www.app2.com Off - do not inherit rules from the parent context. + + + Configuration contexts are an Apache concept. Directives + <Directory>, + <Files>, + <Location> and + <VirtualHost> are all used to create + configuration contexts. For more information please go to the + Apache documentation section Configuration + Sections. +
@@ -3240,7 +3366,7 @@ SecRule XML "@validateDTD /opt/apache-frontend/conf/xml.dtd"
<literal moreinfo="none">RESPONSE_PROTOCOL</literal> - This variable holds the HTTP Response Protocol information. + This variable holds the HTTP response protocol information. Example: SecRule RESPONSE_PROTOCOL "^HTTP\/0\.9" @@ -3249,7 +3375,7 @@ SecRule XML "@validateDTD /opt/apache-frontend/conf/xml.dtd"
<literal moreinfo="none">RESPONSE_STATUS</literal> - This variable holds the HTTP Response Status Code generated by + This variable holds the HTTP response status code as generated by Apache. Example: SecRule RESPONSE_STATUS "^[45]" @@ -3581,10 +3707,10 @@ SecRule REQUEST_HEADERS:Transfer-Encoding "!^$"
<literal moreinfo="none">XML</literal> - Can be used standalone (as a target for validateDTD and - validateSchema) or with an XPath expression parameter (which makes it a - valid target for any function that accepts plain text). Example using - XPath: + Can be used standalone (as a target for + validateDTD and validateSchema) or + with an XPath expression parameter (which makes it a valid target for + any function that accepts plain text). Example using XPath: SecDefaultAction log,deny,status:403,phase:2 SecRule REQUEST_HEADERS:Content-Type ^text/xml$ \ @@ -3713,8 +3839,8 @@ SecRule XML:/xq:employees/employee/name/text() Fred \ <literal>compressWhitespace</literal> It converts whitespace characters (32, \f, \t, \n, \r, \v, 160) to - spaces (ASCII 32) and then compresses multiple space characters into - only one. + spaces (ASCII 32) and then compresses multiple consecutive space + characters into one.
@@ -3797,45 +3923,52 @@ SecRule XML:/xq:employees/employee/name/text() Fred \ moreinfo="none">&gt; + + This function will convert any entity into a single byte only, + possibly resulting in a loss of information. It is thus useful to + uncover bytes that would otherwise not need to be encoded, but it cannot + do anything with the characters from the range above 255.
<literal>jsDecode</literal> - Decodes JavaScript escape sequences. If a \uHHHH code is in the - range of FF01-FF5E (the full width ASCII codes), then the higher byte is - used to detect and adjust the lower byte. Otherwise, only the lower byte - will be used and the higher byte zeroed. + Decodes JavaScript escape sequences. If a + \uHHHH code is in the range of + FF01-FF5E (the full width ASCII + codes), then the higher byte is used to detect and adjust the lower + byte. Otherwise, only the lower byte will be used and the higher byte + zeroed.
<literal>length</literal> This function converts the input to its numeric length (count of - characters). + bytes).
<literal>lowercase</literal> - This function is enabled by default. It converts all characters to - lowercase using the current C locale. + This function converts all characters to lowercase using the + current C locale.
<literal>md5</literal> This function calculates an MD5 hash from input. Note that the - computed hash is in a raw binary form and may need encoded to be usable - (EX: t:md5,t:hexEncode). + computed hash is in a raw binary form and may need encoded into text to + be usable (for example: t:md5,t:hexEncode).
<literal><literal>none</literal></literal> - This not an actual transformation function but an instruction to + Not an actual transformation function, but an instruction to ModSecurity to remove all transformation functions associated with the - current rule and start from scratch. + current rule.
@@ -3843,35 +3976,35 @@ SecRule XML:/xq:employees/employee/name/text() Fred \ This function will remove multiple slashes, self-references and directory back-references (except when they are at the beginning of the - path). + input).
<literal>normalisePathWin</literal> - Same as normalisePath, but will first convert backslash characters - to forward slashes. + Same as normalisePath, but will first convert + backslash characters to forward slashes.
<literal>parityEven7bit</literal> - This function calculates even parity of 7-bit data replacing - the 8th bit of each target byte with the calculated parity bit. + This function calculates even parity of 7-bit data replacing the + 8th bit of each target byte with the calculated parity bit.
<literal>parityOdd7bit</literal> - This function calculates odd parity of 7-bit data replacing - the 8th bit of each target byte with the calculated parity bit. + This function calculates odd parity of 7-bit data replacing the + 8th bit of each target byte with the calculated parity bit.
<literal>parityZero7bit</literal> - This function calculates zero parity of 7-bit data replacing - the 8th bit of each target byte with a zero parity bit which allows + This function calculates zero parity of 7-bit data replacing the + 8th bit of each target byte with a zero parity bit which allows inspection of even/odd parity 7bit data as ASCII7 data.
@@ -3884,7 +4017,7 @@ SecRule XML:/xq:employees/employee/name/text() Fred \
<literal>removeWhitespace</literal> - This function removes all whitespace characters. + This function removes all whitespace characters from input.
@@ -3921,12 +4054,13 @@ SecRule XML:/xq:employees/employee/name/text() Fred \
<literal>urlDecodeUni</literal> - In addition to decoding %xx like In addition to decoding %xx like urlDecode, urlDecodeUni also decodes %uXXXX encoding. If the code is in the range - of FF01-FF5E (the full width ASCII codes), then the higher byte is used - to detect and adjust the lower byte. Otherwise, only the lower byte will - be used and the higher byte zeroed. + of FF01-FF5E (the full width ASCII + codes), then the higher byte is used to detect and adjust the lower + byte. Otherwise, only the lower byte will be used and the higher byte + zeroed.
@@ -3940,7 +4074,7 @@ SecRule XML:/xq:employees/employee/name/text() Fred \ This function calculates a SHA1 hash from input. Note that the computed hash is in a raw binary form and may need encoded to be usable - (EX: t:sha1,t:hexEncode). + (for example: t:sha1,t:hexEncode).
@@ -3970,37 +4104,64 @@ SecRule XML:/xq:employees/employee/name/text() Fred \ Each action belongs to one of five groups: - - - Disruptive actions - are those actions - where ModSecurity will intercept the data. They can only appear in the - first rule in a chain. - + + + Disruptive actions - - Non-disruptive actions - can appear - anywhere. - + + Cause ModSecurity to do something. In many cases something + means block transaction, but not in all. For example, the allow + action is classified as a disruptive action, but it does the + opposite of blocking. There can only be one disruptive action per + rule (if there are multiple disruptive actions present, or + inherited, only the last one will take effect), or rule chain (in a + chain, a disruptive action can only appear in the first + rule). + + - - Flow actions - can appear only in the first - rule in a chain. - + + Non-disruptive actions - - Meta-data actions(id, - rev, severity, msg) - can only appear in the first rule in - a chain. - + + Do something, but that something does not and cannot affect + the rule processing flow. Setting a variable, or changing its value + is an example of a non-disruptive action. Non-disruptive action can + appear in any rule, including each rule belonging to a chain. + + - - Data actions - can appear anywhere; these - actions are completely passive and only serve to carry data used by - other actions. - - + + Flow actions + + + These actions affect the rule flow (for example + skip or skipAfter). + + + + + Meta-data actions + + + Meta-data actions are used to provide more information about + rules. Examples include id, + rev, severity and + msg. + + + + + Data actions + + + Not really actions, these are mere containers that hold data + used by other actions. For example, the status + action holds the status that will be used for blocking (if it takes + place). + + +
<literal>allow</literal> @@ -4071,7 +4232,7 @@ SecAction phase:3,allow response before you make changes to it (e.g. you don't want to inject stuff into images). - Action Group: Non-Disruptive + Action Group: Non-disruptive Processing Phases: 3 and 4. @@ -4086,7 +4247,7 @@ SecAction phase:3,allow Description: Marks the transaction for logging in the audit log. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: @@ -4160,7 +4321,7 @@ SecRuleUpdateActionById 1 "block" collection. Up to ten captures will be copied on a successful pattern match, each with a name consisting of a digit from 0 to 9. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: @@ -4194,16 +4355,16 @@ SecRule TX:1 "(?:(?:a(dmin|nonymous)))" SecRule REQUEST_METHOD ^POST$ chain,t:none SecRule REQUEST_HEADER:Content-Length ^$ t:none - Note - - In programming language concepts, think of chained rules somewhat - similar to AND conditional statements. The actions specified in the - first portion of the chained rule will only be triggered if all of the - variable checks return positive hits. If one aspect of the chained rule - is negative, then the entire rule chain is negative. Also note that - disruptive actions, execution phases, metadata actions (id, rev, msg), - skip and skipAfter actions can only be specified on by the chain starter - rule. + + In programming language concepts, think of chained rules + somewhat similar to AND conditional statements. The actions specified + in the first portion of the chained rule will only be triggered if all + of the variable checks return positive hits. If one aspect of the + chained rule is negative, then the entire rule chain is negative. Also + note that disruptive actions, execution phases, metadata actions (id, + rev, msg), skip and skipAfter actions can only be specified on by the + chain starter rule. +
@@ -4212,7 +4373,7 @@ SecRule REQUEST_HEADER:Content-Length ^$ t:none Description: The ctl action allows configuration options to be updated for the transaction. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: @@ -4364,7 +4525,7 @@ SecRule IP:AUTH_ATTEMPT "@gt 25" \ SecRuleScript documentation for more details on how to write Lua scripts. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: @@ -4378,17 +4539,15 @@ SecRule REQUEST_URI "^/cgi-bin/script\.pl" \ SecRule ARGS:p attack log,exec:/usr/local/apache/conf/exec.lua - This directive does not effect a primary action if it exists. - This action will always call script with no parameters, but providing - all information in the environment. All the usual CGI environment - variables will be there. You can have one binary executed per filter - match. Execution will add the header mod_security-executed to the list - of request headers. You should be aware that forking a threaded - process results in all threads being replicated in the new process. - Forking can therefore incur larger overhead in multi-threaded - operation. The script you execute must write something (anything) to - stdout. If it doesn't ModSecurity will assume execution didn't - work. + The exec action is executed independently from any disruptive + actions. External scripts will always be called with no parameters. + Some transaction information will be placed in environment variables. + All the usual CGI environment variables will be there. You should be + aware that forking a threaded process results in all threads being + replicated in the new process. Forking can therefore incur larger + overhead in multi-threaded operation. The script you execute must + write something (anything) to stdout. If it doesn't ModSecurity will + assume execution didn't work.
@@ -4398,7 +4557,7 @@ SecRule ARGS:p attack log,exec:/usr/local/apache/conf/exec.luaDescription: Configures a collection variable to expire after the given time in seconds. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: @@ -4425,7 +4584,7 @@ setvar:session.suspicious=1,expirevar:session.suspicious=3600Description: Assigns a unique ID to the rule or chain. - Action Group: Metadata + Action Group: Meta-data Example: @@ -4491,7 +4650,7 @@ setvar:session.suspicious=1,expirevar:session.suspicious=3600 - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: The following example initiates IP address tracking. @@ -4514,7 +4673,7 @@ setvar:session.suspicious=1,expirevar:session.suspicious=3600Description: Indicates that a successful match of the rule needs to be logged. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: @@ -4529,10 +4688,10 @@ setvar:session.suspicious=1,expirevar:session.suspicious=3600 <literal>logdata</literal> - Description: Allows logging a data - fragment. + Description: Allows a data fragment to be + logged as part of the alert message. - Action Group: Metadata + Action Group: Non-disruptive Example: @@ -4553,7 +4712,7 @@ setvar:session.suspicious=1,expirevar:session.suspicious=3600Description: Assigns a custom message to the rule or chain. - Action Group: Metadata + Action Group: Meta-data Example: @@ -4573,7 +4732,7 @@ setvar:session.suspicious=1,expirevar:session.suspicious=3600 - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: @@ -4595,7 +4754,7 @@ SecRule ARGS "attack" multiMatch match of the rule should not be used as criteria whether the transaction should be logged to the audit log. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: @@ -4618,7 +4777,7 @@ SecRule ARGS "attack" multiMatch Description: Prevents rule matches from appearing in both the error and audit logs. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: @@ -4665,7 +4824,7 @@ SecRule ARGS "attack" multiMatch Description: Pauses transaction processing for the specified number of milliseconds. - Action Group: Disruptive + Action Group: Non-disruptive Example: @@ -4686,7 +4845,7 @@ SecRule ARGS "attack" multiMatch Description: Places the rule (or the rule chain) into one of five available processing phases. - Action Group: Disruptive + Action Group: Meta-data Example: @@ -4712,7 +4871,7 @@ SecRule REQUEST_HEADERS:User-Agent "Test" log,deny,status:403 response before you make changes to it (e.g. you don't want to inject stuff into images). - Action Group: Non-Disruptive + Action Group: Non-disruptive Processing Phases: 3 and 4. @@ -4765,7 +4924,7 @@ SecRule REQUEST_HEADERS:User-Agent "Test" log,deny,status:403 Description: Specifies rule revision. - Action Group: Metadata + Action Group: Meta-data Example: @@ -4786,7 +4945,7 @@ SecRule REQUEST_HEADERS:User-Agent "Test" log,deny,status:403 with an asterisk) a named request argument prior to audit logging. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: @@ -4808,7 +4967,7 @@ SecRule REQUEST_HEADERS:User-Agent "Test" log,deny,status:403 argument, request header, or response header) that caused a rule match. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: This action can be used to sanitise arbitrary transaction elements when they match a condition. For example, the example below @@ -4828,7 +4987,7 @@ SecRule REQUEST_HEADERS:User-Agent "Test" log,deny,status:403 Description: Sanitises a named request header. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: This will sanitise the data in the Authorization header. @@ -4846,7 +5005,7 @@ SecRule REQUEST_HEADERS:User-Agent "Test" log,deny,status:403 Description: Sanitises a named response header. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: This will sanitise the Set-Cookie data sent to the client. @@ -4864,7 +5023,7 @@ SecRule REQUEST_HEADERS:User-Agent "Test" log,deny,status:403 Description: Assigns severity to the rule it is placed with. - Action Group: Metadata + Action Group: Meta-data Example: @@ -4923,7 +5082,7 @@ SecRule REQUEST_HEADERS:User-Agent "Test" log,deny,status:403 initialises the USER collection. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: @@ -4943,7 +5102,7 @@ SecRule REQUEST_HEADERS:User-Agent "Test" log,deny,status:403 initialises the SESSION collection. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: @@ -4970,7 +5129,7 @@ SecAction setsid:%{REQUEST_COOKIES.PHPSESSID}Description: Creates, removes, or updates an environment variable. - Action Group: Non-Disruptive + Action Group: Non-disruptive Examples: @@ -4995,7 +5154,7 @@ SecAction setsid:%{REQUEST_COOKIES.PHPSESSID}Description: Creates, removes, or updates a variable in the specified collection. - Action Group: Non-Disruptive + Action Group: Non-disruptive Examples: @@ -5020,7 +5179,7 @@ SecAction setsid:%{REQUEST_COOKIES.PHPSESSID}Description: Skips one or more rules (or chains) on successful match. - Action Group: Non-Disruptive + Action Group: Flow Example: @@ -5047,10 +5206,10 @@ SecRule &REQUEST_HEADERS:Accept "@eq 0" \ <literal>skipAfter</literal> Description: Skips rules (or chains) on - successful match resuming rule execution after the specified rule id or - marker (see SecMarker) is found. + successful match resuming rule execution after the specified rule ID or + marker (see SecMarker) is found. - Action Group: Non-Disruptive + Action Group: Flow Example: @@ -5064,11 +5223,12 @@ SecRule &REQUEST_HEADERS:Accept "@eq 0" \ Note - SkipAfter only applies to the current processing phase and not - necessarily the order in which the rules appear in the configuration - file. If you group rules by processing phases, then skip should work as - expected. This action can not be used to skip rules within one chain. - Accepts a single parameter denoting the last rule ID to skip. + SkipAfter only applies to the current + processing phase and not necessarily the order in which the rules appear + in the configuration file. If you group rules by processing phases, then + skip should work as expected. This action can not be used to skip rules + within one chain. Accepts a single parameter denoting the last rule ID + to skip.
@@ -5078,7 +5238,7 @@ SecRule &REQUEST_HEADERS:Accept "@eq 0" \ code to use with actions deny and redirect. - Action Group: Disruptive + Action Group: Data Example: @@ -5102,7 +5262,7 @@ SecRule &REQUEST_HEADERS:Accept "@eq 0" \ before they (or the results, rather) are run against the operator specified in the rule. - Action Group: Non-Disruptive + Action Group: Non-disruptive Example: @@ -5124,7 +5284,7 @@ SecRule REQUEST_COOKIES:SESSIONID "47414e81cbbef3cf8366e84eeacba091" \ Description: Assigns custom text to a rule or chain. - Action Group: Metadata + Action Group: Meta-data Example: @@ -5146,12 +5306,13 @@ tag:'WEB_ATTACK/FILE_INJECTION',tag:'OWASP/A2',severity:'2'"Description: This action should be used together with an XPath expression to register a namespace. - Action Group: Non-Disruptive + Action Group: Data Example: SecRule REQUEST_HEADERS:Content-Type "text/xml" \ - phase:1,pass,ctl:requestBodyProcessor=XML,ctl:requestBodyAccess=On,xmlns:xsd="http://www.w3.org/2001/XMLSchema" + "phase:1,pass,ctl:requestBodyProcessor=XML,ctl:requestBodyAccess=On, \ + xmlns:xsd="http://www.w3.org/2001/XMLSchema" SecRule XML:/soap:Envelope/soap:Body/q1:getInput/id() "123" phase:2,deny
@@ -5160,8 +5321,8 @@ SecRule XML:/soap:Envelope/soap:Body/q1:getInput/id() "123" phase:2,denyOperators A number of operators can be used in rules, as documented below. The - operator syntax used the "@" symbol followed by the specific operator - name. + operator syntax uses the @ symbol followed by the + specific operator name.
<literal>beginsWith</literal> @@ -5169,7 +5330,7 @@ SecRule XML:/soap:Envelope/soap:Body/q1:getInput/id() "123" phase:2,denyDescription: This operator is a string comparison and returns true if the parameter value is found at the beginning of the input. Macro expansion is performed so you may use - variable names such as %{TX.1}, etc. + variable names such as %{TX.1}, etc. Example: @@ -5482,8 +5643,8 @@ SecRule REQUEST_HEADERS:Ip-Address "!@streq %{TX.1}" <literal>validateDTD</literal> - Description: This operator requires the - request body to be processed as XML. + Description: Validates the DOM tree generated + by the XML request body processor against the supplied DTD. Example: @@ -5492,13 +5653,19 @@ SecRule REQUEST_HEADERS:Content-Type ^text/xml$ \ phase:1,t:lowercase,nolog,pass,ctl:requestBodyProcessor=XML SecRule REQBODY_PROCESSOR "!^XML$" nolog,pass,skipAfter:12345 SecRule XML "@validateDTD /path/to/apache2/conf/xml.dtd" "deny,id:12345" + + + This operator requires request body to be processed as + XML. +
<literal>validateSchema</literal> - Description: This operator requires the - request body to be processed as XML. + Description: Validates the DOM tree generated + by the XML request body processor against the supplied XML + Schema. Example: @@ -5508,7 +5675,10 @@ SecRule REQUEST_HEADERS:Content-Type ^text/xml$ \ SecRule REQBODY_PROCESSOR "!^XML$" nolog,pass,skipAfter:12345 SecRule XML "@validateSchema /path/to/apache2/conf/xml.xsd" "deny,id:12345" - This operator requires request body to be processed as XML. + + This operator requires request body to be processed as + XML. +