1. The OWASP Foundation OWASP http://www.owasp.org XSS Remediation Cassia Martin cmartin@cigital.com Romain Gaucher rgaucher@cigital.com April 7 th, 2011

2. OWASP 2 What is XSS?  XSS is an attacker injecting JavaScript into your page  The 3 types:  Stored –  attacker stored payload in your app  Reflected –  attacker cons user into clicking link with payload  DOM based –  Like reflected, but payload never hits server

3. OWASP 3 How do we fix it?  Only two choices – use both  Input Validation  Output Encoding  My religion:  No WAF solution  No blacklist

4. OWASP 4 Input Validation  Input Validation  Limit the attack surface by constraining input  Whitelist: If a field in an app is intended to be a zip code, no need to increase the attack surface by accepting arbitrary input.  Just limit to 5 numbers  "Picklist": Only accept states  Blacklist: Reject '<>";  Sure, you can block  What about onLoad(), eval()  You can block " '  What about %3C, &#60, \x3C, \u003c

5. OWASP Input Validation (cont’d)  Client side input validation is evil  Do validation checks server side  In JSP, You entered zipcode:  Not: You entered zipcode: validateZip(zipcode)  Why client side validation?  Save time and bandwidth  Improve UI  Won’t prevent attacks. 5

6. OWASP Input Validation (cont’d)  Implement both syntactic and semantic validation checks  Syntactic  Often charset checking  i.e., in Credit card field, Only allow numbers  Semantic  Well, what else do we know about credit cards…  15 or 16 characters  Pass the “Luhn” check  If user selected Visa, starts with a 4  Etc. 6

7. OWASP 7 Output Encoding  Often, you can’t narrowly constrain input  Boss’s name: O’Malley  Even if you can, aim for defense in depth  “Separate data plane from control plane”  Output Encoding is the name for transforming control characters into data  Different encoding required for different contexts

8. OWASP HTML Context  HTML code: alert(1)  In an HTML context, HTML encoding is the answer! 8

9. OWASP HTML Context Fix – HTML Encoding  Transform possible html code into data  Turns < into > 9 alert(1) <script>aler t(1)</script&gt

10. OWASP HTML Attribute context  HTML attributes (JavaScript events): " onmouseover="alert('w00t') 10

11. OWASP HTML Attribute Context fix  HTML Attribute encoding  Very similar to HTML Encoding, larger scope  OWASP recommendation  Any ASCII character under 256 should be rewritten to &#xHH;  Most common mistake:  not encoding " and ' 11

12. OWASP HTML URI location context  HTML URI locations: click me  Base64 decode:  " alert('woot') " 12

13. OWASP HTML URI location control fix  URI:  Full control of the URI: whitelist  Also protects against Open Url Redirect  Partial control (inject in the path, etc.): URL encoding  Transforms ' -> %27 13 action.php?para m= alert (1) action.php%3fparam %3d%3cscript%3ealer t(1)%3c%2fscript%3e

14. OWASP Javascript/JSON context  JavaScript/JSON: ");alert('w00t');/* or "};alert('w00t');/* 14

15. OWASP Javascript/DOM context  JavaScript/DOM Vulnerable code: document.write(location.hash. substring(1));  Attack Url: http://example.com/page# alert(/1/) 15

16. OWASP Javascript context fix  JavaScript context:  Inside strings: use Unicode strings (\u003e\u004f)  Outside strings: don’t blacklisting _"()+[ ]-{}'/. is currently okay, probably. not good security philosophy and not futureproof. If you need this, whitelist. e.g., /[\w]+/  DOM: same as above, but in JavaScript: tainted.replace(/[^\w]/g, "")  JSON:  Need not to be JSON-injectable, plus safe JSON parsing function e.g., not eval() 16

17. OWASP var a = " alert('xss'); "; http://erlend.oftedal.no/blog/?blogid=91 17

18. OWASP CSS context  CSS: border:1px solid; expression(alert('w00t'))}/* 18

19. OWASP CSS context fix  CSS:  Consider this to be: JavaScript context, outside strings  Alternatively, block expression, using a full CSS parser  Don’t just block expression  CSS accepts html encoded keywords + comments  exp/**/ression will evade your blacklist. 19

20. OWASP Other contexts  Flash, XML, SVG, PDF, GIF comments, etc.  Client-side technologies such as Flash, Silverlight, etc. need to employ the same validation/encodings schemes 20

21. OWASP Libraries  ESAPI  Reference implementations for: Java,.NET, PHP, Classic ASP, Cold Fusion, Python, and Haskell.  http://www.owasp.org/index.php/XSS_(Cross_Site_Sc ripting)_Prevention_Cheat_Sheet http://www.owasp.org/index.php/XSS_(Cross_Site_Sc ripting)_Prevention_Cheat_Sheet  Reform  Java,.NET v1/v2, PHP, Python, Perl, JavaScript, ASP  http://www.owasp.org/index.php/Category:OWASP_E ncoding_Project http://www.owasp.org/index.php/Category:OWASP_E ncoding_Project  AntiXSS Microsoft Web Protection Library –.Net  http://wpl.codeplex.com/ http://wpl.codeplex.com/  Platform specific solutions 21

22. OWASP ESAPI Functions  ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) );  ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) );  ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" ) );  ESAPI.encoder().encodeForCSS( request.getParameter( "input" ) );  ESAPI.encoder().encodeForURL( request.getParameter( "input" ) ); 22

23. OWASP Further thoughts  We only talked about first-order encodings here (what happens when your payload goes through an XML based WS?)  Finally, XSS is easy to fix in one location, difficult across one application 23