Directives
The following section outlines all of the Coraza directives.
If you are looking to extend OWASP Core Ruleset, check this article.
Note : It is highly encouraged that you do not edit the Core rules files themselves but rather place all changes (such as SecRuleRemoveByID, etc…) in your custom rules file. This will allow for easier upgrading as newer Core rules are released.
SecAction
Description: Unconditionally processes the action list it receives as the first and only parameter. The syntax of the parameter is identical to that of the third parameter of SecRule.
Syntax: SecAction “action1,action2,action3,…“
This directive is commonly used to set variables and initialize persistent collections using the initcol action. For example:
SecAction nolog,phase:1,initcol:RESOURCE=%{REQUEST_FILENAME}
SecArgumentSeparator
Description: Specifies which character to use as the separator for application/x-www-form- urlencoded content.
Syntax: SecArgumentSeparator character
Default: &
This directive is needed if a backend web application is using a nonstandard argument separator. Applications are sometimes (very rarely) written to use a semicolon separator. You should not change the default setting unless you establish that the application you are working with requires a different separator. If this directive is not set properly for each web application, then Coraza will not be able to parse the arguments appropriately and the effectiveness of the rule matching will be significantly decreased.
SecAuditEngine
Description: Configures the audit logging engine.
Syntax: SecAuditEngine RelevantOnly
Default: Off
The SecAuditEngine directive is used to configure the audit engine, which logs complete transactions. Coraza is currently able to log most, but not all transactions. Transactions involving errors (e.g., 400 and 404 transactions) use a different execution path, which Coraza does not support.
The possible values for the audit log engine are as follows:
- On: log all transactions
- Off: do not log any transactions
- RelevantOnly: only the log transactions that have triggered a warning or an error, or have a status code that is considered to be relevant (as determined by the SecAuditLogRelevantStatus directive)
Note : If you need to change the audit log engine configuration on a per-transaction basis (e.g., in response to some transaction data), use the ctl action. The following example demonstrates how SecAuditEngine is used:
SecAuditEngine RelevantOnly
SecAuditLog logs/audit/audit.log
SecAuditLogParts ABCFHZ
SecAuditLogType concurrent
SecAuditLogStorageDir logs/audit
SecAuditLogRelevantStatus ^(?:5|4(?!04))
SecAuditLog
Description: Defines the path to the main audit log file (serial logging format) or the concurrent logging index file (concurrent logging format). When used in combination with mlogc (only possible with concurrent logging), this directive defines the mlogc location and command line.
Syntax: SecAuditLog /path/to/audit.log
SecAuditLog "|/path/to/mlogc /path/to/mlogc.conf"
Note : This audit log file is opened on startup when the server typically still runs as root. You should not allow non-root users to have write privileges for this file or for the directory.
SecAuditLogParts
Description: Defines which parts of each transaction are going to be recorded in the audit log. Each part is assigned a single letter; when a letter appears in the list then the equivalent part will be recorded. See below for the list of all parts.
Syntax: SecAuditLogParts PARTLETTERS
Example Usage: SecAuditLogParts ABCFHZ
The format of the audit log format is documented in detail in the Audit Log Data Format Documentation.
Available audit log parts:
- A: Audit log header (mandatory).
- B: Request headers.
- C: Request body (present only if the request body exists and Coraza is configured to intercept it. This would require SecRequestBodyAccess to be set to on).
- D: Reserved for intermediary response headers; not implemented yet.
- E: Intermediary response body (present only if Coraza is configured to intercept response bodies, and if the audit log engine is configured to record it. Intercepting response bodies requires SecResponseBodyAccess to be enabled). Intermediary response body is the same as the actual response body unless Coraza intercepts the intermediary response body, in which case the actual response body will contain the error message (either the Apache default error message, or the ErrorDocument page).
- F: Final response headers (excluding the Date and Server headers, which are always added by Apache in the late stage of content delivery).
- G: Reserved for the actual response body; not implemented yet.
- H: Audit log trailer.
- I: This part is a replacement for part C. It will log the same data as C in all cases except when multipart/form-data encoding in used. In this case, it will log a fake application/x-www-form-urlencoded body that contains the information about parameters but not about the files. This is handy if you don’t want to have (often large) files stored in your audit logs.
- J: This part contains information about the files uploaded using multipart/form-data encoding.
- K: This part contains a full list of every rule that matched (one per line) in the order they were matched. The rules are fully qualified and will thus show inherited actions and default operators.
- Z: Final boundary, signifies the end of the entry (mandatory).
SecAuditLogRelevantStatus
Description: Configures which response status code is to be considered relevant for the purpose of audit logging.
Syntax: SecAuditLogRelevantStatus REGEX
Example Usage: SecAuditLogRelevantStatus “^(?:5|4(?!04))”
Dependencies/Notes: Must have SecAuditEngine set to RelevantOnly. Additionally, the auditlog action is present by default in rules, this will make the engine bypass the ‘SecAuditLogRelevantStatus’ and send rule matches to the audit log regardless of status. You must specify noauditlog in the rules manually or set it in SecDefaultAction.
The main purpose of this directive is to allow you to configure audit logging for only the transactions that have the status code that matches the supplied regular expression. The example provided would log all 5xx and 4xx level status codes, except for 404s. Although you could achieve the same effect with a rule in phase 5, SecAuditLogRelevantStatus is sometimes better, because it continues to work even when SecRuleEngine is disabled.
SecCollectionTimeout
Description: Specifies the collections timeout. Default is 3600 seconds.
Syntax: SecCollectionTimeout seconds
Default: 3600
Supported: No
SecComponentSignature
Description: Appends component signature to the Coraza signature.
Syntax: SecComponentSignature “COMPONENT_NAME/X.Y.Z (COMMENT)”
Example Usage: SecComponentSignature “core ruleset/2.1.3”
Supported: No
This directive should be used to make the presence of significant rule sets known. The entire signature will be recorded in the transaction audit log.
SecContentInjection
Description: Enables content injection using actions append and prepend.
Syntax: SecContentInjection On|Off
Example Usage: SecContentInjection On
Supported: TBI
This directive provides an easy way to control content injection, no matter what the rules want to do. It is not necessary to have response body buffering enabled in order to use content injection.
Note : This directive must ben enabled if you want to use @rsub + the STREAM_ variables to manipulate live transactional data.
SecDataDir
Description: Path where persistent data (e.g., IP address data, session data, and so on) is to be stored.
Syntax: SecDataDir /path/to/dir
Example Usage: SecDataDir /usr/local/apache/logs/data
Supported: No
This directive must be provided before initcol, setsid, and setuid can be used. The directory to which the directive points must be writable by the web server user.
Note : This directive is not allowed inside VirtualHosts. If enabled, it must be placed in a global server-wide configuration file such as your default Coraza.conf. Note : SecDataDir is not currently supported. Collections are kept in memory (in_memory-per_process) for now.
SecDebugLog
Description: Path to the Coraza debug log file.
Syntax: SecDebugLog /path/to/coraza-debug.log
Example Usage: SecDebugLog /usr/local/apache/logs/coraza-debug.log
Supported: Yes
SecDebugLogLevel
Description: Configures the verboseness of the debug log data.
Syntax: SecDebugLogLevel 0|1|2|3|4|5
Example Usage: SecDebugLogLevel 4
Supported: Yes
Messages at levels 1–3 are always copied to the Apache error log. Therefore you can always use level 0 as the default logging level in production if you are very concerned with performance. Having said that, the best value to use is 3. Higher logging levels are not recommended in production, because the heavy logging affects performance adversely.
The possible values for the debug log level are:
- 0: Fatal
- 1: Panic
- 2: Error
- 3: Warning
- 4: details of how transactions are handled
- 5: log everything, including very detailed debugging information
SecDefaultAction
Description: Defines the default list of actions, which will be inherited by the rules in the same configuration context.
Syntax: SecDefaultAction “action1,action2,action3“
Example Usage: SecDefaultAction “phase:2,log,auditlog,deny,status:403,tag:‘SLA 24/7’“
Supported: Yes
Default: phase:2,log,auditlog,pass
Every rule following a previous SecDefaultAction directive in the same configuration context will inherit its settings unless more specific actions are used. Every SecDefaultAction directive must specify a disruptive action and a processing phase and cannot contain metadata actions.
SecDisableBackendCompression
Description: Disables backend compression while leaving the frontend compression enabled.
Syntax: SecDisableBackendCompression On|Off
Supported: TBI
Default: Off
This directive is necessary in reverse proxy mode when the backend servers support response compression, but you wish to inspect response bodies. Unless you disable backend compression, Coraza will only see compressed content, which is not very useful. This directive is not necessary in embedded mode, because Coraza performs inspection before response compression takes place.
SecHashEngine
Description: Configures the hash engine.
Syntax: SecHashEngine On|Off
Example Usage: SecHashEngine On
Supported: TBI
Default: Off
The possible values are:
- On: Hash engine can process the request/response data.
- Off: Hash engine will not process any data.
Note: Users must enable stream output variables and content injection.
SecHashKey
Description: Define the key that will be used by HMAC.
Syntax: SecHashKey rand|TEXT KeyOnly|SessionID|RemoteIP
Example Usage: SecHashKey “this_is_my_key” KeyOnly
Supported: TBI
Coraza hash engine will append, if specified, the user’s session id or remote ip to the key before the MAC operation. If the first parameter is “rand” then a random key will be generated and used by the engine.
SecHashParam
Description: Define the parameter name that will receive the MAC hash.
Syntax: SecHashParam TEXT
Example Usage: SecHashParam “hmac”
Supported: TBI
Coraza hash engine will add a new parameter to protected HTML elements containing the MAC hash.
SecHashMethodRx
Description: Configures what kind of HTML data the hash engine should sign based on regular expression.
Syntax: SecHashMethodRx TYPE REGEX
Example Usage: SecHashMethodRx HashHref “product_info|list_product”
Supported: TBI
As a initial support is possible to protect HREF, FRAME, IFRAME and FORM ACTION html elements as well response Location header when http redirect code are sent.
The possible values for TYPE are:
- HashHref: Used to sign href= html elements
- HashFormAction: Used to sign form action= html elements
- HashIframeSrc: Used to sign iframe src= html elements
- HashframeSrc: Used to sign frame src= html elements
- HashLocation: Used to sign Location response header
Note : This directive is used to sign the elements however user must use the @validateHash operator to enforce data integrity.
SecHashMethodPm
Description: Configures what kind of HTML data the hash engine should sign based on string search algoritm.
Syntax: SecHashMethodPm TYPE “string1 string2 string3…”
Example Usage: SecHashMethodPm HashHref “product_info list_product”
Supported: TBI
As a initial support is possible to protect HREF, FRAME, IFRAME and FORM ACTION html elements as well response Location header when http redirect code are sent.
The possible values for TYPE are:
- HashHref: Used to sign href= html elements
- HashFormAction: Used to sign form action= html elements
- HashIframeSrc: Used to sign iframe src= html elements
- HashframeSrc: Used to sign frame src= html elements
- HashLocation: Used to sign Location response header
Note : This directive is used to sign the elements however user must use the @validateHash operator to enforce data integrity.
SecGeoLookupDb
Description: Defines the path to the database that will be used for geolocation lookups.
Syntax: SecGeoLookupDb /path/to/db
Example Usage: SecGeoLookupDb /path/to/GeoLiteCity.mmdb
Supported: Yes
Coraza relies on the free geolocation databases (GeoLite City and GeoLite Country) that can be obtained from MaxMind http://www.maxmind.com. Only .mmdb format is supported.
SecHttpBlKey
Description: Configures the user’s registered Honeypot Project HTTP BL API Key to use with @rbl.
Syntax: SecHttpBlKey [12 char access key]
Example Usage: SecHttpBlKey whdkfieyhtnf
Supported: TBI
If the @rbl operator uses the dnsbl.httpbl.org RBL (http://www.projecthoneypot.org/httpbl_api.php) you must provide an API key. This key is registered to individual users and is included within the RBL DNS requests.
SecInterceptOnError
Description: Configures how to respond when rule processing fails.
Syntax: SecInterceptOnError On|Off
Example Usage: SecInterceptOnError On
Supported: TBI
When an operator execution fails, that is it returns greater than 0, this directive configures how to react. When set to “Off”, the rule is just ignored and the engine will continue executing the rules in phase. When set to “On”, the rule will be just dropped and no more rules will be executed in the same phase, also no interception is made.
SecMarker
Description: Adds a fixed rule marker that can be used as a target in a skipAfter action. A SecMarker directive essentially creates a rule that does nothing and whose only purpose is to carry the given ID.
Syntax: SecMarker ID|TEXT
Example Usage: SecMarker 9999
Supported: Yes
The value can be either a number or a text string. The SecMarker directive is available to allow you to choose the best way to implement a skip-over. Here is an example used from the Core Rule Set:
SecMarker BEGIN_HOST_CHECK
SecRule &REQUEST_HEADERS:Host "@eq 0" \
"skipAfter:END_HOST_CHECK,phase:2,rev:'2.1.1',t:none,block,msg:'Request Missing a Host Header',id:'960008',tag:'PROTOCOL_VIOLATION/MISSING_HEADER_HOST',tag:'WASCTC/WASC-21',tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10',severity:'5',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.protocol_violation_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-PROTOCOL_VIOLATION/MISSING_HEADER-%{matched_var_name}=%{matched_var}"
SecRule REQUEST_HEADERS:Host "^$" \
"phase:2,rev:'2.1.1',t:none,block,msg:'Request Missing a Host Header',id:'960008',tag:'PROTOCOL_VIOLATION/MISSING_HEADER_HOST',tag:'WASCTC/WASC-21',tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10',severity:'5',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.protocol_violation_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-PROTOCOL_VIOLATION/MISSING_HEADER-%{matched_var_name}=%{matched_var}"
SecMarker END_HOST_CHECK
SecSensorId
Description: Define a sensor ID that will be present into log part H.
Syntax: SecSensorId TEXT
Example Usage: SecSensorId WAFSensor01
Supported: TBI
SecRemoteRules
Description: Load rules from a given file hosted on a HTTPS site.
Syntax: SecRemoteRules [crypto] key https://url
Example Usage: SecRemoteRules some-key https://www.yourserver.com/plain-text-rules.txt
Supported: Yes
This is an optional directive that allow the user to load rules from a remote server. Notice that besides the URL the user also needs to supply a key, which could be used by the target server to provide different content for different keys.
Along with the key, supplied by the users, Coraza will also send its Unique ID and the `status call’ in the format of headers to the target web server. The following headers are used:
- Coraza-status
- Coraza-unique-id
- Coraza-key
The utilization of SecRemoteRules is only allowed over TLS.
Note : A valid and trusted digital certificate is expected on the end server. It is also expected that the server uses TLS, preferable TLS 1.2.
SecRemoteRulesFailAction
Description: Action that will be taken if SecRemoteRules specify an URL that Coraza was not able to download.
Syntax: SecRemoteRulesFailAction Abort|Warn
Example Usage: SecRemoteRulesFailAction Abort
Supported: Yes
The default action is to Abort whenever there is a problem downloading a given URL.
Note : This directive also influences the behaviour of @ipMatchFromFile when used with a HTTPS URI to retrieve the remote file.
SecRequestBodyAccess
Description: Configures whether request bodies will be buffered and processed by Coraza.
Syntax: SecRequestBodyAccess On|Off
Example Usage: SecRequestBodyAccess On
Supported: Yes
This directive is required if you want to inspect the data transported request bodies (e.g., POST parameters). Request buffering is also required in order to make reliable blocking possible. The possible values are:
- On: buffer request bodies
- Off: do not buffer request bodies
SecRequestBodyInMemoryLimit
Description: Configures the maximum request body size that Coraza will store in memory.
Syntax: SecRequestBodyInMemoryLimit LIMIT_IN_BYTES
Example Usage: SecRequestBodyInMemoryLimit 131072
Supported: No
Default: 131072 (128 KB)
When a multipart/form-data request is being processed, once the in-memory limit is reached, the request body will start to be streamed into a temporary file on disk.
SecRequestBodyLimit
Description: Configures the maximum request body size Coraza will accept for buffering.
Syntax: SecRequestBodyLimit LIMIT_IN_BYTES
Example Usage: SecRequestBodyLimit 134217728
Supported: Yes
Default: 134217728 (131072 KB)
Anything over the limit will be rejected with status code 413 (Request Entity Too Large). There is a hard limit of 1 GB.
SecRequestBodyNoFilesLimit
Description: Configures the maximum request body size Coraza will accept for buffering, excluding the size of any files being transported in the request. This directive is useful to reduce susceptibility to DoS attacks when someone is sending request bodies of very large sizes. Web applications that require file uploads must configure SecRequestBodyLimit to a high value, but because large files are streamed to disk, file uploads will not increase memory consumption. However, it’s still possible for someone to take advantage of a large request body limit and send non-upload requests with large body sizes. This directive eliminates that loophole.
Syntax: SecRequestBodyNoFilesLimit NUMBER_IN_BYTES
Example Usage: SecRequestBodyNoFilesLimit 131072
Supported: No
Default: 1048576 (1 MB)
Generally speaking, the default value is not small enough. For most applications, you should be able to reduce it down to 128 KB or lower. Anything over the limit will be rejected with status code 413 (Request Entity Too Large). There is a hard limit of 1 GB.
SecRequestBodyLimitAction
Description: Controls what happens once a request body limit, configured with SecRequestBodyLimit, is encountered
Syntax: SecRequestBodyLimitAction Reject|ProcessPartial
Example Usage: SecRequestBodyLimitAction ProcessPartial
Supported: Yes
By default, Coraza will reject a request body that is longer than specified. This is problematic especially when Coraza is being run in DetectionOnly mode and the intent is to be totally passive and not take any disruptive actions against the transaction. With the ability to choose what happens once a limit is reached, site administrators can choose to inspect only the first part of the request, the part that can fit into the desired limit, and let the rest through. This is not ideal from a possible evasion issue perspective, however it may be acceptable under certain circumstances.
Note : When the SecRuleEngine is set to DetectionOnly, SecRequestBodyLimitAction is automatically set to ProcessPartial in order to not cause any disruptions. If you want to know if/when a request body size is over your limit, you can create a rule to check for the existence of the INBOUND_ERROR_DATA variable.
SecResponseBodyLimit
Description: Configures the maximum response body size that will be accepted for buffering.
Syntax: SecResponseBodyLimit LIMIT_IN_BYTES
Example Usage: SecResponseBodyLimit 524228
Supported: Yes
Default: 524288 (512 KB)
Anything over this limit will be rejected with status code 500 (Internal Server Error). This setting will not affect the responses with MIME types that are not selected for buffering. There is a hard limit of 1 GB.
SecResponseBodyLimitAction
Description: Controls what happens once a response body limit, configured with SecResponseBodyLimit, is encountered.
Syntax: SecResponseBodyLimitAction Reject|ProcessPartial
Example Usage: SecResponseBodyLimitAction ProcessPartial
Supported: Yes
By default, Coraza will reject a response body that is longer than specified. Some web sites, however, will produce very long responses, making it difficult to come up with a reasonable limit. Such sites would have to raise the limit significantly to function properly, defying the purpose of having the limit in the first place (to control memory consumption). With the ability to choose what happens once a limit is reached, site administrators can choose to inspect only the first part of the response, the part that can fit into the desired limit, and let the rest through. Some could argue that allowing parts of responses to go uninspected is a weakness. This is true in theory, but applies only to cases in which the attacker controls the output (e.g., can make it arbitrary long). In such cases, however, it is not possible to prevent leakage anyway. The attacker could compress, obfuscate, or even encrypt data before it is sent back, and therefore bypass any monitoring device.
SecResponseBodyMimeType
Description: Configures which MIME types are to be considered for response body buffering.
Syntax: SecResponseBodyMimeType MIMETYPE MIMETYPE …
Example Usage: SecResponseBodyMimeType text/plain text/html text/xml
Supported: Yes
Default: text/plain text/html
Multiple SecResponseBodyMimeType directives can be used to add MIME types. Use SecResponseBodyMimeTypesClear to clear previously configured MIME types and start over.
SecResponseBodyMimeTypesClear
Description: Clears the list of MIME types considered for response body buffering, allowing you to start populating the list from scratch.
Syntax: SecResponseBodyMimeTypesClear
Example Usage: SecResponseBodyMimeTypesClear
Supported: Yes
SecResponseBodyAccess
Description: Configures whether response bodies are to be buffered.
Syntax: SecResponseBodyAccess On|Off
Example Usage: SecResponseBodyAccess On
Supported: Yes
Default: Off
This directive is required if you plan to inspect HTML responses and implement response blocking. Possible values are:
- On: buffer response bodies (but only if the response MIME type matches the list configured with SecResponseBodyMimeType).
- Off: do not buffer response bodies.
SecRule
Description: Creates a rule that will analyze the selected variables using the selected operator.
Syntax: SecRule VARIABLES OPERATOR [ACTIONS]
Example Usage: SecRule ARGS “@rx attack” “phase:1,log,deny,id:1”
Supported: Yes
Every rule must provide one or more variables along with the operator that should be used to inspect them. If no actions are provided, the default list will be used. (There is always a default list, even if one was not explicitly set with SecDefaultAction.) If there are actions specified in a rule, they will be merged with the default list to form the final actions that will be used. (The actions in the rule will overwrite those in the default list.) Refer to SecDefaultAction for more information.
SecRuleEngine
Description: Configures the rules engine.
Syntax: SecRuleEngine On|Off|DetectionOnly
Example Usage: SecRuleEngine On
Supported: Yes
Default: Off
The possible values are:
- On: process rules
- Off: do not process rules
- DetectionOnly: process rules but never executes any disruptive actions (block, deny, drop, allow, proxy and redirect)
SecRulePerfTime
Description: Set a performance threshold for rules. Rules that spend at least the time defined will be logged into audit log Part H as Rules-Performance-Info in the format id=usec, comma separated.
Syntax: SecRulePerfTime USECS
Example Usage: SecRulePerfTime 1000
Supported: TBI
The rules hitting the threshold can be accessed via the collection PERF_RULES.
SecRuleRemoveById
Description: Removes the matching rules from the current configuration context.
Syntax: SecRuleRemoveById ID ID RANGE …
Example Usage: SecRuleRemoveByID 1 2 “9000-9010”
Supported: Partially, it supports one rule per directive.
This directive supports multiple parameters, each of which can be a rule ID or a range. Parameters that contain spaces must be delimited using double quotes.
Note : This directive must be specified after the rule in which it is disabling. This should be used within local custom rule files that are processed after third party rule sets. Example file - Coraza_crs_60_customrules.conf.
SecRuleRemoveByMsg
Description: Removes the matching rules from the current configuration context.
Syntax: SecRuleRemoveByMsg REGEX
Example Usage: SecRuleRemoveByMsg “FAIL”
Supported: Yes
Normally, you would use SecRuleRemoveById to remove rules, but that requires the rules to have IDs defined. If they don’t, then you can remove them with SecRuleRemoveByMsg, which matches a regular expression against rule messages.
Note : This directive must be specified after the rule in which it is disabling. This should be used within local custom rule files that are processed after third party rule sets.
SecRuleRemoveByTag
Description: Removes the matching rules from the current configuration context.
Syntax: SecRuleRemoveByTag REGEX
Example Usage: SecRuleRemoveByTag “WEB_ATTACK/XSS”
Supported: Yes
Normally, you would use SecRuleRemoveById to remove rules, but that requires the rules to have IDs defined. If they don’t, then you can remove them with SecRuleRemoveByTag, which matches a regular expression against rule tag data. This is useful if you want to disable entire groups of rules based on tag data. Example tags used in the OWASP Coraza CRS include:
- AUTOMATION/MALICIOUS
- AUTOMATION/MISC
- AUTOMATION/SECURITY_SCANNER
- LEAKAGE/SOURCE_CODE_ASP_JSP
- LEAKAGE/SOURCE_CODE_CF
- LEAKAGE/SOURCE_CODE_PHP
- WEB_ATTACK/CF_INJECTION
- WEB_ATTACK/COMMAND_INJECTION
- WEB_ATTACK/FILE_INJECTION
- WEB_ATTACK/HTTP_RESPONSE_SPLITTING
- WEB_ATTACK/LDAP_INJECTION
- WEB_ATTACK/PHP_INJECTION
- WEB_ATTACK/REQUEST_SMUGGLING
- WEB_ATTACK/SESSION_FIXATION
- WEB_ATTACK/SQL_INJECTION
- WEB_ATTACK/SSI_INJECTION
- WEB_ATTACK/XSS
Note : This directive must be specified after the rule in which it is disabling. This should be used within local custom rule files that are processed after third party rule sets. Example file - Coraza_crs_60_customrules.conf.
SecRuleUpdateActionById
Description: Updates the action list of the specified rule.
Syntax: SecRuleUpdateActionById RULEID[:offset] ACTIONLIST
Example Usage: SecRuleUpdateActionById 12345 “deny,status:403”
Supported: TBI but it’s supported by CTL
This directive will overwrite the action list of the specified rule with the actions provided in the second parameter. It has two limitations: it cannot be used to change the ID or phase of a rule. Only the actions that can appear only once are overwritten. The actions that are allowed to appear multiple times in a list, will be appended to the end of the list.
SecRule ARGS attack "phase:2,id:12345,t:lowercase,log,pass,msg:'Message text'"
SecRuleUpdateActionById 12345 "t:none,t:compressWhitespace,deny,status:403,msg:'New message text'"
The effective resulting rule in the previous example will be as follows:
SecRule ARGS attack "phase:2,id:12345,t:lowercase,t:none,t:compressWhitespace,deny,status:403,msg:'New Message text'"
The addition of t:none will neutralize any previous transformation functions specified (t:lowercase, in the example).
Note : If the target rule is a chained rule, you must currently specify chain in the SecRuleUpdateActionById action list as well. This will be fixed in a future version.
SecRuleUpdateTargetById
Description: Updates the target (variable) list of the specified rule.
Syntax: SecRuleUpdateTargetById RULEID TARGET1[,TARGET2,TARGET3] REPLACED_TARGET
Example Usage: SecRuleUpdateTargetById 12345 “!ARGS:foo”
Supported: TBI but it’s supported by CTL
This directive will append (or replace) variables to the current target list of the specified rule with the targets provided in the second parameter.
Explicitly Appending Targets
This is useful for implementing exceptions where you want to externally update a target list to exclude inspection of specific variable(s).
SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "[\;\|\`]\W*?\bmail\b" \
"phase:2,rev:'2.1.1',capture,t:none,t:htmlEntityDecode,t:compressWhitespace,t:lowercase,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'958895',tag:'WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.command_injection_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%
{tx.0}"
SecRuleUpdateTargetById 958895 !ARGS:email The effective resulting rule in the previous example will append the target to the end of the variable list as follows:
SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/*|!ARGS:email "[\;\|\`]\W*?\bmail\b" \
"phase:2,rev:'2.1.1',capture,t:none,t:htmlEntityDecode,t:compressWhitespace,t:lowercase,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'958895',tag:'WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.command_injection_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%
{tx.0}"
Note that is is also possible to use regular expressions in the target specification:
SecRuleUpdateTargetById 981172 "!REQUEST_COOKIES:/^appl1_.*/"
Explicitly Replacing Targets
You can also entirely replace the target list to something more appropriate for your environment. For example, lets say you want to inspect REQUEST_URI instead of REQUEST_FILENAME, you could do this:
SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "[\;\|\`]\W*?\bmail\b" \
"phase:2,rev:'2.1.1',capture,t:none,t:htmlEntityDecode,t:compressWhitespace,t:lowercase,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'958895',tag:'WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.command_injection_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%
{tx.0}"
SecRuleUpdateTargetById 958895 REQUEST_URI REQUEST_FILENAME
The effective resulting rule in the previous example replaces the target in the begin of the variable list as follows:
SecRule REQUEST_URI|ARGS_NAMES|ARGS|XML:/* "[\;\|\`]\W*?\bmail\b" \
"phase:2,rev:'2.1.1',capture,t:none,t:htmlEntityDecode,t:compressWhitespace,t:lowercase,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'958895',tag:'WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.command_injection_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%
{tx.0}"
Note : You could also do the same by using the ctl action with the ruleRemoveById directive. That would be useful if you want to only update the targets for a particular URL, thus conditionally appending targets.
SecRuleUpdateTargetByMsg
Description: Updates the target (variable) list of the specified rule by rule message.
Syntax: SecRuleUpdateTargetByMsg TEXT TARGET1[,TARGET2,TARGET3] REPLACED_TARGET
Example Usage: SecRuleUpdateTargetByMsg “Cross-site Scripting (XSS) Attack” “!ARGS:foo”
Supported: TBI
This directive will append (or replace) variables to the current target list of the specified rule with the targets provided in the second parameter.
Explicitly Appending Targets
This is useful for implementing exceptions where you want to externally update a target list to exclude inspection of specific variable(s).
SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "[\;\|\`]\W*?\bmail\b" \
"phase:2,rev:'2.1.1',capture,t:none,t:htmlEntityDecode,t:compressWhitespace,t:lowercase,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'958895',tag:'WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.command_injection_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%
{tx.0}"
SecRuleUpdateTargetByMsg "System Command Injection" !ARGS:email
The effective resulting rule in the previous example will append the target to the end of the variable list as follows:
SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/*|!ARGS:email "[\;\|\`]\W*?\bmail\b" \
"phase:2,rev:'2.1.1',capture,t:none,t:htmlEntityDecode,t:compressWhitespace,t:lowercase,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'958895',tag:'WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.command_injection_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%
{tx.0}"
Explicitly Replacing Targets You can also entirely replace the target list to something more appropriate for your environment. For example, lets say you want to inspect REQUEST_URI instead of REQUEST_FILENAME, you could do this:
SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "[\;\|\`]\W*?\bmail\b" \
"phase:2,rev:'2.1.1',capture,t:none,t:htmlEntityDecode,t:compressWhitespace,t:lowercase,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'958895',tag:'WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.command_injection_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%
{tx.0}"
SecRuleUpdateTargetByMsg "System Command Injection" REQUEST_URI REQUEST_FILENAME
The effective resulting rule in the previous example will append the target to the end of the variable list as follows:
SecRule REQUEST_URI|ARGS_NAMES|ARGS|XML:/* "[\;\|\`]\W*?\bmail\b" \
"phase:2,rev:'2.1.1',capture,t:none,t:htmlEntityDecode,t:compressWhitespace,t:lowercase,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'958895',tag:'WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.command_injection_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%
{tx.0}"
SecRuleUpdateTargetByTag
Description: Updates the target (variable) list of the specified rule by rule tag.
Syntax: SecRuleUpdateTargetByTag TEXT TARGET1[,TARGET2,TARGET3] REPLACED_TARGET
Example Usage: SecRuleUpdateTargetByTag “WEB_ATTACK/XSS” “!ARGS:foo”
Supported: TBI
This directive will append (or replace) variables to the current target list of the specified rule with the targets provided in the second parameter.
Explicitly Appending Targets
This is useful for implementing exceptions where you want to externally update a target list to exclude inspection of specific variable(s).
SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "[\;\|\`]\W*?\bmail\b" \
"phase:2,rev:'2.1.1',capture,t:none,t:htmlEntityDecode,t:compressWhitespace,t:lowercase,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'958895',tag:'WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.command_injection_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%
{tx.0}"
SecRuleUpdateTargetByTag "WASCTC/WASC-31" !ARGS:email
The effective resulting rule in the previous example will append the target to the end of the variable list as follows:
SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/*|!ARGS:email "[\;\|\`]\W*?\bmail\b" \
"phase:2,rev:'2.1.1',capture,t:none,t:htmlEntityDecode,t:compressWhitespace,t:lowercase,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'958895',tag:'WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.command_injection_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%
{tx.0}"
Explicitly Replacing Targets
You can also entirely replace the target list to something more appropriate for your environment. For example, lets say you want to inspect REQUEST_URI instead of REQUEST_FILENAME, you could do this:
SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "[\;\|\`]\W*?\bmail\b" \
"phase:2,rev:'2.1.1',capture,t:none,t:htmlEntityDecode,t:compressWhitespace,t:lowercase,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'958895',tag:'WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.command_injection_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%
{tx.0}"
SecRuleUpdateTargetByTag "WASCTC/WASC-31" REQUEST_URI REQUEST_FILENAME
The effective resulting rule in the previous example will append the target to the end of the variable list as follows:
SecRule REQUEST_URI|ARGS_NAMES|ARGS|XML:/* "[\;\|\`]\W*?\bmail\b" \
"phase:2,rev:'2.1.1',capture,t:none,t:htmlEntityDecode,t:compressWhitespace,t:lowercase,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'958895',tag:'WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.command_injection_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%
{tx.0}""
SecUnicodeMap
Description: Defines which Unicode code point will be used by the urlDecodeUni transformation function during normalization.
Syntax: SecUnicodeMap CODEPOINT
Example Usage: SecUnicodeMapFile 20127
Supported: Yes
SecUploadDir
Description: Configures the directory where intercepted files will be stored.
Syntax: SecUploadDir /path/to/dir
Example Usage: SecUploadDir /tmp
Supported: Yes
This directory must be on the same filesystem as the temporary directory defined with SecTmpDir. This directive is used with SecUploadKeepFiles.
SecUploadFileLimit
Description: Configures the maximum number of file uploads processed in a multipart POST.
Syntax: SecUploadFileLimit number
Example Usage: SecUploadFileLimit 10
Supported: Yes
The default is set to 100 files, but you are encouraged to reduce this value. Any file over the limit will not be extracted and the MULTIPART_FILE_LIMIT_EXCEEDED and MULTIPART_STRICT_ERROR flags will be set. To prevent bypassing any file checks, you must check for one of these flags.
Note : If the limit is exceeded, the part name and file name will still be recorded in FILES_NAME and FILES, the file size will be recorded in FILES_SIZES, but there will be no record in FILES_TMPNAMES as a temporary file was not created.
SecUploadFileMode
Description: Configures the mode (permissions) of any uploaded files using an octal mode (as used in chmod).
Syntax: SecUploadFileMode octal_mode|“default”
Example Usage: SecUploadFileMode 0640
Supported: Yes
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.
Note : The process umask may still limit the mode if it is being more restrictive than the mode set using this directive.
SecUploadKeepFiles
Description: Configures whether or not the intercepted files will be kept after transaction is processed.
Syntax: SecUploadKeepFiles On|Off|RelevantOnly
Example Usage: SecUploadKeepFiles On
Supported: TBI
This directive requires the storage directory to be defined (using SecUploadDir).
Possible values are:
- On - Keep uploaded files.
- Off - Do not keep uploaded files.
- RelevantOnly - This will keep only those files that belong to requests that are deemed relevant. (Not implemented)
SecWebAppId
Description: Creates an application namespace, allowing for separate persistent session and user storage.
Syntax: SecWebAppId “NAME”
Example Usage: SecWebAppId “WebApp1”
Supported: Yes
Default: default
Application namespaces are used to avoid collisions between session IDs and user IDs when multiple applications are deployed on the same server. If it isn’t used, a collision between session IDs might occur.