1. 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 OWASP http://www.owasp.org Web Application Firewalls: Patch first, ask questions later Jonathan Werrett Trustwave, SpiderLabs jwerrett@trustwave.com +852 6081 1508 8 November 2011

2. OWASP 2 Overview  Web Application Firewalls  Virtual Patching  An Example Web App  Building Virtual Patches  SQL Injection Challenge Results

3. OWASP 3 Web Application Firewalls  Security device, dedicated to the web application layer  Provides context-specific protection  Can be a hardware or software Positives  High level of web ‘knowledge’  Centralised control  Mature anti-evasion Negatives  Root cause not addressed  Very specific  Won’t address Business Logic and other similar flaws

4. OWASP 4 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

5. OWASP 5 Virtual Patching  Addressing specific flaws at WAF layer  ‘Just in time patching’ Benefits  Time to patch  Flexibility  Scalability  Dealing with legacy code  Dealing with outsourced code  Reduced exposed  ‘Out of band’ patching  Patch availability  Reduce dependency on dev  Avoiding ‘re-inventing’ the wheel

6. OWASP 6 ModSecurity  Open Source Web Application Firewall  Free to use  Largest install base  Numerous mature features http://modsecurity.org/

7. OWASP 7 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

8. OWASP 8 Example Web Application http://quipr/

9. OWASP 9 Building Virtual Patches – Worked Example Cross-site Scripting

10. OWASP 10 Building Virtual Patches – Worked Example Cross-site Scripting  ‘White list’ values accepted for user[bio] parameter  Accepts: Text, with spaces, dashes and full stops accepted.  Blocks: Anything else, including punctuation characters <>$()‘”; SecRule ARGS_POST:user[bio] "!^[\w\. ]*$" "phase:2,id:00001,t:none,t:urlDecodeUni,t:lowercase"

11. OWASP 11 Demonstration

12. OWASP 12 Building Virtual Patches – Worked Example SQL Injection

13. OWASP 13 Building Virtual Patches – Worked Example SQL Injection  Best method is to ‘white list’ as we did for XSS SecRule REQUEST_FILENAME "!^[\\\w]*$ "phase:2,id:00001,t:none,t:urlDecodeUni,t:lowercase"

14. OWASP 14 Demonstration

15. OWASP 15 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

16. OWASP 16 Demonstration

17. OWASP 17 Building Virtual Patches – Worked Example Cross-site Request Forgery  Setting a unique, token per user SecRule STREAM_OUTPUT_BODY "@rsub s/ / $(function(){ $('a').each(function(){ $(this).attr('href',this.href+'?tk='+$('#mstk').val()); }); /" "phase:4,t:none,nolog,pass, setsid:%{REQUEST_COOKIES._QUIPR_SESSION}, setvar:session.csrf_token=%{UNIQUE_ID}”

18. OWASP 18 Building Virtual Patches – Worked Example Cross-site Request Forgery  Block requests without the token 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}"

19. OWASP 19 Demonstration

20. OWASP 20 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’

21. OWASP 21 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-challenge- lessons-learned.html