0% found this document useful (0 votes)
12 views10 pages

Chuleta SecRule

Uploaded by

Eliana Dias
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
0% found this document useful (0 votes)
12 views10 pages

Chuleta SecRule

Uploaded by

Eliana Dias
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
You are on page 1/ 10
Table 5.2. Request variables Variable Description ARGS Request parameters (tead-only collection) ARGS_COMBINED_STZE Total sizeof al request parameters combined ARGS NAMES, Request parameters’ names (cllection ARGS GET (Query string parameters (read-only coletion) ARGS_GET_NAMES Avery string parameter’ names (ead-only collection) ARGS_POST Request body parameters (read-only collection) ARGS_POST_NAMES Request body parameters’ names (read-only collection) FILES File names (read-only collection) FILES_COMBINED_SIZE FILES_TWPNAHES PATH_INFO ‘uery_sraine RENOTE_USe REQUEST _BASENAME REQUEST_s00¥ REQUEST_cooKIES REQUEST _COOKIES_ NAMES REQUEST FILENAME REQUEST. REQUEST. REQUEST_LINE REQUEST_METHOD REQUEST_pROTOCOL REQUEST_URI REQUEST _URI_RAw Combined size ofall uploaded files File parameter names (read-only collection) ‘list of file sizes (read-only collection) ‘list of temporary file names (read-only collection) Extra path information Request querystring Remote user Request URI basename Request body Request cookies (read-only collection) Request cookies’ names (read-only collection) Request URI filename/path Request headers (collection, read-only) Request headers’ names (read-only collection) Request line Request method Request protocol Request URI, convert to exclude hostname Request URI, as it was presented in the request Server variables Server variables contain the pieces of information available to the server, most of them valid only for the transaction being processed at the moment they are evaluated. Server variables 68 hylis J. Henderson Table 5.3. Server variables Variable Description ‘UTH_IVPE ‘Authentication type REMOTE_ADDR Remate address REMOTE HOST Remate host REMOTE_PoRT Remote port SCRTPT_BASENAME Script basename SCRIPT_FILENAME Script flename/path scarPT 1D Script group 1D SCRLPT_GROUPNAME Script group name SCRIPT_ODE Script permissions scart UID Script user ID SCRIPT_USERNAME Script user name SERVER_ADDR Sewer address SERVER_NAME Server name SERVER_PORT Sewer port Response variables Response variables are those extracted from the response part of the transaction that is being inspected. Most response variables will be available in phase 3. The arguably most impor- tant response variable, RESPONSE_BODY, is only available in phase 4 (the phase is also called RESPONSE_BODY). Table 5.4. Response variables Variable Description RESPONSE_BODY Response body RRESPONSE_CONTENT_LENGTH Response content length RESPONSE_CONTENT_TYPE Response content type RESPONSE_HEADERS. Response headers (read-only collection) RRESPONSE_HEADERS_NAMES Response headers’ names (read-only collection) RESPONSE_PROTOCOL Response protocol RESPONSE_STATUS Response status code 70 Chapter 5: Rule Language Overview perty of Phyls J. Henderson Miscellaneous variables Miscellaneous variables are exactly what they are called: they are the variables that couldn’t fit in any other category. Variable Description NIGHEST_SEVERITY ATCHED_VAR MATCHED_VAR_NAME moosec_suito SESSIONID UsERID WeBAPPID EBSERVER_ERROR_LOG Highest severity encountered Contents ofthe last variable that matched Name ofthe last variable that match ModSecurity build version fg, 02050102) Session ID associated with current transaction User I associated with cutet transaction ‘Web application ID associated with current transaction Enor messages generated by Apache during current transaction Parsing flags Parsing flags are used by ModSecurity to signal important parsing events. The idea is to avoid taking implicit action (e.g., blocking in response to an invalid request), but allow the rules to decide what to do. Table 5.6. Request body parsing v les Variable Description ‘MILTIPART_BOUNDARY_QUOTED MILTIPART_BoUNDARY_HHITESPACE MILTIPART_CRLF_LF_LINES MILTIPART_DATA BEFORE MILTIPART_DATA_AFTER MILTIPART_HEADER_FOLDING MILTIPART_LF_LINE MILTIPART_SEMICOLON_MISSING MILTIPART_STRICT_ERROR MULTIPART_UNMATCHED_BOUNDARY REQBODY PROCESSOR REQBODY_PROCESSOR_FRROR REQBODY_PROCESSOR_ERROR_MSG Multipart parsing error: quoted boundary encountered Multipart parsing error: whitespace in boundary Mutipart parsing error: mined tne endings used Mutipart parsing error: seen data before first boundary Muttipart parsing error: seen data after last boundary Multipart parsing error: header folding used Mutipart parsing error: LF tine ending detected Multipart parsing errr: missing semicolon before boundary ‘At least one multipart ertor except MULTIPART_UNVATCHED_BOUNDARY occurred Mutipart parsing errr: unmatched boundary detected (prane to false positives) Request processor that handled request body Request processor eror lag (0 or 1) Request processor error message Miscellaneous variables 7 hylis J. Henderson Collections Collections are the special kind of variables that can contain other variables. With exception of the persistent collections, all collections are essentially one-off, special variables that give access to the information to which ModSecurity has access. Table 5.7. Special collections Variable Descrintion ew Environment variables (read-only clleton, although t's possible to use set var to change ceo Geo lookup information fromthe lst egeoLockup invocation (read-only calles tion) GLOBAL Global information, shared by all processes (read/write collection) ra IP address data storage readrte colton) * Transient transaction data (‘ear eleton) RULE Curent rule metadata (ead-onycoleton) sesston Session date storage rad/witeclleton use User data storage (read/write callestion) xa XI DOM tre (read-only calleton Time variables ‘Time variables all represent the moment in time when the transaction that ModSecurity is processing began. Table 5.8. Time variables Variable Description TINE Time (HHMMSS) TINE_pAY Day of the month (1-31) ‘TINE_gPocH Seconds since January 1, 1970 (e.g, 1251029017) TINE_HouR Hour ofthe day (0-23) TINe_HIN Minute of the hour (0-89) TINE_How Month of the year (0-11) Tane_sec Seoond ofthe minute (0-58) ‘TINe_WoAY Wook day (0-8) TIME_YEAR Year n Chapter 5: Rule Language Overview Property of Phyllis J. Henderson Operators In the examples so far the assumption was that we are always going to use regular pat- tern matching against input. While regular expressions are very useful, there are often times when you want to do something else. That is when operators come to play. The truth is that ModSecurity always uses an operator, but that it assumes that you want to use regular patterns matching unless you specify an operator in a rule. So, to start with, here’s a rule that explicitly specifies an operator- -the regular pattern matching one! SecRule ARGS:usernane "@rx *(adnin|xoct)$* ‘The above rule which checks if the requested username is adnin or root. You may have noticed a few things: + Operators begin with a @ character. + Operators are always placed at the beginning of the second SecRule token. + There's always a space after an operator. Whatever follows the space is the single op- erator parameter. In the case of the @rx operator, the parameter is a regular expres- sion, + When you have a rule with an explicit operator you'll need to use double quotes around the token, because there’s always going to be a space character inside the to- ken. Omitting double quotes would only confuse Apache and cause it to complain. ‘The power of the operators comes from the extensive functionality on offer. String oper- ators, shown in Table 5.9, “String matching operators”, are most often used. You've seen plenty examples using regular pattern matching so far. In addition to the simple matching operators (@beginsWith, @endsWith, etc.), ModSecurity supports parallel matching, where a large number of patterns can be matched at once. That is what @pm and @pnFronFile are for. String matching operators String matching operators all take a string on input and attempt to match it to the provided parameter. The @rx and épm operators are the ones commonly used, because of their versa- tility (@x) and speed (@pn), but the remaining operators are also useful, especially if you need variable expansion, which neither @x nor @pm support. Operators 3 Property of Phyllis J. Henderson Miscellaneous operators And, finally, there’s the miscellaneous category (Table 5.12, “Miscellaneous operators”), which offers some very useful functionality. Table 5.12. Miscellaneous operators Operator Description egealookip Determines the physica location ofan P adress @inspectFile Invokes an external script to inspect a file en Looks paameter against aRBL (alte blacklist) averifyCc Checks if the parameter is a valid credit card number Actions Actions make ModSecurity tick. They make it possible to react to events and, more impor- tantly, they are the glue that hold everything else together and make the advanced features, possible. They are also the most overloaded element of the rule language. Because of the constraints of the Apache configuration syntax, within the rule language exists, actions are used to carry everything other than variables and operators. Actions can be split into 7 cat- egories. Disruptive actions Disruptive actions (Table 5.13, “Disruptive actions”) specify what a rule wants to do on a match, Each rule must be associated with exactly one disruptive action. The pass action is the only exception, as it will allow processing to continue when a match occurs. All other actions from this category will block in some specific way. Table 5.13. Disruptive actions Aetion Description allow ‘Stop processing of one or more remaining phases block Indicates that a rule wants to block deny Block transaction with an eror page drop Close network connection pass Do not block, goto the next rule proxy Proxy request to @ backend web server redirect Redirect request to some other web server Miscellaneaus operators 8 Property of Phyllis J. Henderson Flow actions Flow actions (Table 5.14, “Flow actions”) alter the way rules are processed within a phase. Table 5.14, Flow actions Action Description chain Connect two or more rules into a single logical rule skip Skip over one or more rules that follow skipafter Skip to the rule or marker wth the provided 1D Metadata actions Metadata actions (Table 5.15, “Metadata actions”) provide additional information about rules. The information is meant to accompany the error messages to make it easier to un- derstand why they occurred. Table 5.15. Metadata actions Aetion Description id Assign unique ID toa rule phase Phase fora rule torunin sg Message string rev Revision number severity Severity tag Tag Variable actions Variable actions (Table 5.16, “Variable actions”) deal with variables. They allow you to set, change and remove variables. 16 (Chapter 6; Rule Language O Property of Phyllis J. Henderson Table 5.16, Variable actions Action Description capture Capture results into one or more variables deprecatevar Decrease numerical variable value overtime cexpirevar Remove variable after atime period initeol Creat anew persistent cllection setenv Set orremove an environment variable setvar Set, remove, increment or desrement a variable setuid Associate current transaction with an application user ID (sername) setsid Associate current transaction wth an application session ID Logging actions Logging actions (Table 5.17, “Logging actions”) influence the way logging is done. The ac- tions that influence if logging takes place (auditlog, log, noauditlog, and nolog) only con- trol current rule affects logging if it matches. ‘To control logging for the transaction as a whole you'll need to use the ct] action. Table 5.17. Logging actions sation Description auditlog Tog curent transaction te aut og log Log ror message; implies auditog logéata Log supplied data as part of eror message noautitlog Do nt log current transection to aut og neleg Dont lg enor messege; implies noouditlog sanitisenrg Remove request parameter om ait og sanitiseMatched Remove parameter in which a match occurred from audit log sanitiseRequstHeader Remove request header fram aut og sanitiseResponseHeader Remove response header from audit log Special actions Special actions (Table 5.18, “Special actions”) are gateways of sort; they provide access to another class of functionality. The ct1 action has several sub-actions of its own and allows engine configuration to be changed only the current transaction. The multiMatch rule acti- vates a special way of matching in which the rule operator is run after every transformation Logging actions 7 perty of Phyls J. Henderson (normally, the operator is run only once after all transformations). The t action is used to specify zero or more transformations that will be applied to variables before an operator isrun. Table 5.18. Special actions Action Description etl Change configuration of curent transaction rmultiMatch ‘Activate mutti-matching, where an operator runs after every transformation t Specify transformation functions to apply to variables before matching Miscellaneous actions Miscellaneous actions (Table 5. belong in any of the groups. Table 5.19. Miscellaneous actions 9, “Miscellaneous actions”) contain the actions that don’t Action Description append ‘Append content to response body exec Execute extemal script pause Pause transaction prepend Prepend content o response body Specityrespanse status code to use with deny and redirect Specity name space for use with XPath expressions 78 Chapter 5: Rule Language Overview hylis J. Henderson

You might also like