Transcript OWASP Plan

Web Application Firewalls:
Patch first, ask questions later
Jonathan Werrett
Trustwave, SpiderLabs
[email protected]
OWASP
+852 6081 1508
8 November 2011
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org
Overview
 Web Application Firewalls
 Virtual Patching
 An Example Web App
 Building Virtual Patches
 SQL Injection Challenge Results
OWASP
2
Web Application Firewalls
 Security device, dedicated to the web application layer
 Provides context-specific protection
 Can be a hardware or software
Positives
Negatives
High level of web ‘knowledge’
Root cause not addressed
Centralised control
Very specific
Mature anti-evasion
Won’t address Business Logic and
other similar flaws
OWASP
3
Web Application Firewalls
Reasons NOT to use a WAF
 A standard told you to (Eg. PCI DSS Req. 6.6)
 To avoid active testing
 To avoid dealing with developers
 Your auditor / vendor tells you to
Reasons to use a WAF
 Segregate security and development functions
 Minimise expose windows
 Provide `base security` across many apps
OWASP
4
Virtual Patching
 Addressing specific flaws at WAF layer
 ‘Just in time patching’
Benefits
 Time to patch
 Reduced exposed
 Flexibility
 ‘Out of band’ patching
 Scalability
 Patch availability
 Dealing with legacy code
 Reduce dependency on dev
 Dealing with outsourced code
 Avoiding ‘re-inventing’ the wheel
OWASP
5
ModSecurity
 Open Source Web Application Firewall
 Free to use
 Largest install base
 Numerous mature features
http://modsecurity.org/
OWASP
6
Building Virtual Patches – Key Steps
Preparation
Make sure you’re running ModSecurity!
Clearly establish roles
Create a suitable test environment
Identification & Analysis
Number of sources (active assessments, vulnerability notifications)
Identify key features. Whitelist or Blacklist approach?
Deploy & Test
Make sure it doesn’t stop legitimate traffic
OWASP
7
Example Web Application
http://quipr/
OWASP
8
Building Virtual Patches – Worked Example
Cross-site Scripting
OWASP
9
Building Virtual Patches – Worked Example
Cross-site Scripting
‘White list’ values accepted for user[bio] parameter
<Location /user/>
SecRule ARGS_POST:user[bio] "!^[\w\. ]*$"
"phase:2,id:00001,t:none,t:urlDecodeUni,t:lowercase"
</Location>
Accepts: Text, with spaces, dashes and full stops accepted.
Blocks: Anything else, including punctuation characters <>$()‘”;
OWASP
10
Demonstration
OWASP
11
Building Virtual Patches – Worked Example
SQL Injection
OWASP
12
Building Virtual Patches – Worked Example
SQL Injection
Best method is to ‘white list’ as we did for XSS
<Location /user/>
SecRule REQUEST_FILENAME "!^[\\\w]*$
"phase:2,id:00001,t:none,t:urlDecodeUni,t:lowercase"
</Location>
OWASP
13
Demonstration
OWASP
14
Building Virtual Patches – Worked Example
SQL Injection
 However, we can also leverage the OWASP Common Ruleset
 Numerous generic rules for various issues
 Well tested and comprehensive
 SQL Injection alone has 179 tests
 Sophisticated scoring process, rather than straight forward matching
OWASP
15
Demonstration
OWASP
16
Building Virtual Patches – Worked Example
Cross-site Request Forgery
Setting a unique, token per user
SecRule STREAM_OUTPUT_BODY "@rsub s/<\/body>/
<input type=\"hidden\" id=\"mstk\” value=\"%{unique_id}\">
<script>$(function(){
$('a').each(function(){
$(this).attr('href',this.href+'?tk='+$('#mstk').val());
});
});
<\/script><\/body>/"
"phase:4,t:none,nolog,pass,
setsid:%{REQUEST_COOKIES._QUIPR_SESSION},
setvar:session.csrf_token=%{UNIQUE_ID}”
OWASP
17
Building Virtual Patches – Worked Example
Cross-site Request Forgery
Block requests without the token
<LocationMatch "^/(user|quips)/”>
SecRule &ARGS:tk "!@eq 1"
"phase:2,t:none,log,deny,setsid:%{REQUEST_COOKIES._QUIPR_S
ESSION},msg:'No CSRF Token Detected.'”
SecRule ARGS:tk "!@streq %{session.csrf_token}"
"phase:2,t:none,log,deny,
setsid:%{REQUEST_COOKIES._QUIPR_SESSION},
msg:%{session.csrf_token}"
</LocationMatch>
OWASP
18
Demonstration
OWASP
19
ModSecurity SQL Injection Challenge
 650 Participants
 Tested the OWASP ModSecurity Core Ruleset
 4 Demo Sites for Vendors
(Acunetix, Cenzic, HP, IBM)
 9 “Winners”
 Improvements fed into the Core Ruleset
Results
 Black listing is hard
 WAFs increase ‘hack resistance’ but will never ‘hack proof’
OWASP
20
Summary
 Virtual Patching helps makes security fast
 Reduces your exposure
 Leaves developers the space and time to find the best fix
 Centralises security and provides a global `base`
Further Reading
 ModSecurity – http://modsecurity.org
 OWASP ModSecurity Core Rule Set
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rul
e_Set_Project
 ModSecurity SQL Injection Challenge
http://blog.spiderlabs.com/2011/07/modsecurity-sql-injection-challengelessons-learned.html
OWASP
21