XSS, CSRF and similar types of web application attacks have overtaken SQL injections as the most commonly seen attacks on the internet (https://info.cenzic.com/2013-Application-Security-Trends-Report.html). A very large number of web application were written and deployed prior to the trend up in likelihood and awareness of XSS attacks. Thus, it is extremely important to have an effective method of testing for XSS vulnerabilities and mitigating them.
Changes to production code bases can be slow, costly and can miss unreported vulnerabilities quite easily. The use of application firewalls such as ModSecurity (https://github.com/SpiderLabs/ModSecurity/) become an increasingly attractive solution when faced with a decision on how to mitigate current and future XSS vulnerabilities.
Mod Security can be embedded with Apache, NGINX and IIS which is relativity straight forward. In cases where alternative web severs are being used ModSecurity can still be a viable option by creating a reverse proxy (using Apache of NGINX).
How can ModSecurity be used?
- Alerting
- Transforming
- Blocking
- and more
These functions can be enacted by rules.
A default action can be created for a group of rules using the configuration directive “SecDefaultAction”
Using the following SecDefaultAction at the top of rule set that we want enable blocking and transforming on is a blunt method of protection. Redirection can also be used as a method of blocking.
Example of a default action to be applied by ruleset (note defaults cascade through the ruleset files):
SecDefaultAction “phase:2,log,auditlog,deny,status:403,tag:’Unspecified usage'”
Rulesets have been created by OWASP.
Using optional rulesets, modsecurity_crs_16_session_hijacking.conf and modsecurity_crs_43_csrf_protection.conf ModSecurity can provide protection against Cross Site Request Forgeries [CSRF]. The @rsub operators can inject a token on every form (and/or other html elements). ModSecurity can store the expected token value as a variable which is compared to the value posted via forms or other html elements. ModSecurity rules can be based on request methods and URIs etc – alongside the ability to chain rules there are a huge number of options for mitigating XSS and CSRF without impacting normal applicatioin usage.
@rsub
Requirements:
- SecRuleEngine On
- SecRequestBodyAccess On
- SecResponseBodyAccess On
## To enable @rsub
- SecStreamOutBodyInspection On
- SecStreamInBodyInspection On
- SecContentInjection On
Injecting unique request id from mod_unique_id into forms:
SecRule STREAM_OUTPUT_BODY "@rsub s/<\/form>/<input type=\"hidden\" name=\"rv_token\" value=\"%{unique_id}\"><\/form>/" \
"phase:4,t:none,nolog,pass"
Some simple rules:
<LocationMatch ".*\/<directory requiring authentication>\/.*">
# All requests submitted using POST require a token - not the validation of the token can only be completed if that variable is stored from a previous response
SecRule REQUEST_METHOD "^(?:POST)$" "chain,phase:2,id:'1234',t:none,block,msg:'CSRF Attack Detected - Missing CSRF Token when using POST method - ',redirect:/" SecRule &ARGS:token "!@eq 1" "setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/CSRF-%{matched_var_name}=%{matched_var}"
# Check referrer is valid for an authenticated area of the application
SecRule REQUEST_HEADERS:Referer "!@contains <my website>" "block,phase:2,id:'2345',t:none,block,msg:'CSRF Attack Detected - No external referers allowed to internal portal pages',redirect:/"
SecRule REQUEST_URI "@contains confirmUpdate" "chain,phase:2,id:'3456',t:none,block,msg:'CSRF Attack Detected - Missing CSRF Token. Confirmation button - ',redirect:/" SecRule &ARGS:rv_token "!@eq 1" "setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/CSRF-%{matched_var_name}=%{matched_var}"
</LocationMatch>
Pros:
- Wide capabilities for logging, alerts, blocking, redirecting, transforming
- Parses everything coming into your web server over HTTP
- Virtual patching – if a vulnerability is made public that affects your web application you can write and deploy a rule to mitigate the vulnerability much faster than re-release of application code patched
- Extended uses – the capabilities of ModSecurity can be applied to applications outside the scope of application security
Cons:
- Added complexity to your application delivery chain – another point for maintenance and failure
- Performance costs? – Though I have not had the opportunity to test the performance costs holding session information in memory and inspecting every byte of HTTP traffic can’t be free from performance cost
- Hardware costs – Particularly if using ModSecurity’s BodyAccess and BodyInspection features, memory usage will be significant
Improving deployments:
- Starting off being aggressive on warnings and very light on action is a necessity to ensure no impact on normal application usage
- From this point rules and actions need to be refined
- Understanding how the applications works allows the use of ModSecuirtys header and body inspection in effective ways
Some other notes extracted from the ModSecurity Handbook – If you decide to use ModSecurity I strongly recommend buying the handbook. It is not expensive and saves a lot of time.
### RULE STRUCTURE ###
SecRule VARIABLES OPERATOR [TRANSFORMATION_FUNCTIONS, ACTIONS]
### VARIABLES ### REQUEST_URI Request URI, convert to exclude hostname REQUEST_METHOD Request method ARGS Request parameters (read-only collection) ARGS_NAMES Request parameters’ names (collection) ARGS_GET Query string parameters (read-only collection) ARGS_GET_NAMES Query string parameters’ names (read-only collection) ARGS_POST Request body parameters (read-only collection) ARGS_POST_NAMES Request body parameters’ names (read-only collection)
### STRING MATCHING OPERATORS ### @beginsWith Input begins with parameter @contains Input contains parameter @endsWith Input ends with parameter @rsub Manipulation of request and response bodies @rx Regular pattern match in input @pm Parallel pattern matching @pmFromFile (also @pmf as of 2.6) Parallel patterns matching, with patterns read from a file @streq Input equal to parameter @within Parameter contains input
### NUMBER MATCHING OPERATORS ### @eq Equal @ge Greater or equal @gt Greater than @le Less or equal @lt Less than
### ACTIONS ### # DISRUPTIVE allow Stop processing of one or more remaining phases block Indicate that a rule wants to block deny Block transaction with an error page drop Close network connection pass Do not block, go to the next rule pause Pause for a period of time, then execute allow. proxy Proxy request to a backend web server redirect Redirect request to some other web server
# FLOW chain Connect two or more rules into a single logical rule skip Skip over one or more rules that follow skipAfter Skip after the rule or marker with the provided ID
Others.. #METADATA, #VARIABLE, #LOGGING, #SPECIAL, #MISC