Securing your web application through HTTP headers

1,215 views

Published on

These are my slides for my workshop at the Booster conference 2013.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Securing your web application through HTTP headers

  1. 1. SECURING YOUR WEB APPLICATION THROUGH HTTP HEADERS Booster — 14. March 2013 André N. Klingsheim (@klingsen) AppSec AS 1
  2. 2. OUTLINE• HTTP headers• Attacks and security headers • Cross site scripting (XSS) — Content Security Policy • Clickjacking — X-Frame-options • SSL stripping++ — HTTP Strict Transport Security • Session hijacking — Cookie security settings • MIME type attacks — X-Download-Options, X-Content-Type-options 2
  3. 3. DEMO 3
  4. 4. HYGIENE: VERSION HEADERS• Web servers and web application frameworks tend to include version headers in the HTTP responses• There really is no reason to leak this information to an attacker• Get rid of them and save the bandwith!• Demo 4
  5. 5. Cross site scripting (XSS)CONTENT SECURITY POLICY 5
  6. 6. CROSS SITE SCRIPTING (XSS)• Reflected • User controlled data from the request is included in the response• Persistent • Attacker is able to store the attack server side, the stored attack is later included in response(s)• DOM based • Does not involve the server, happens on the client side- XSS (Cross Site Scripting) Prevention Cheat Sheet- OWASP Top 10 for JavaScript – A2: Cross Site Scripting – XSS 6
  7. 7. DEMO 7
  8. 8. CONTENT SECURITY POLICY (CSP)• Lets you specify a policy for where content in your webpages can be loaded from• Lets you put restrictions on script execution• Headers • Content-Security-Policy – Chrome 25 • X-Content-Security-Policy – Firefox 4+ • X-WebKit-Csp – WebKit browsers (Chrome/Safari)• W3C Candidate recommendation • Will end up being a proper standard! 8
  9. 9. CSP DIRECTIVES• default-src — Specifies the default for other sources• script-src• style-src• object-src — plugins• img-src• media-src — video/audio• frame-src• font-src• connect-src• report-uri — Specifies where CSP violations can be reported 9
  10. 10. CSP SOURCES (FOR THE DIRECTIVES)• none — No content of this type is allowed (All directives)• self — Content of this type can only be loaded from the same origin (no content from other sites) (All directives)• unsafe-inline — Allows unsafe inline content. • Supported by style-src (inline css) and script-src (inline script)• unsafe-eval — Allows script functions considered unsafe (such as eval()) • Supported by script-src• And you can specify custom sources: • * — Allow content from anywhere • https: — Scheme only, load only content served over https • *.nwebsec.com — Wildcard host, allow content from any nwebsec.com sub-domain. • www.nwebsec.com:81 — You can specify a port number • https://www.nwebsec.com — You can of specify an absolute URI for a host (path has no effect though) 10
  11. 11. AND THEN IT ALL COMES TOGETHER• Content-Security-Policy: default-src self; script-src self scripts.nwebsec.codeplex.com• This policy sets a default source of self for all directives.• script-src defines its own sources, replacing the default (hence the inclusion of self)• In effect, scripts, stylesheets, images, flash animations, Java applets etc can only be loaded from the same origin as the page• Scripts can also be loaded from scripts.nwebsec.codeplex.com• This policy denies inline scripts and CSS! 11
  12. 12. THE "SPECIAL" SOURCES• unsafe-inline can allow inline scripts (script-src) and styles (style-src)• unsafe-eval allows certain JavaScript functions considered high risk (eval())• Use these special sources with care 12
  13. 13. CSP REPORTING• You can specify a "report-uri" in the CSP header• Must be a relative URI• Will post violation reports as JSON back to the web application• Content-Security-Policy-Report-Only • Will not block scripts or resources violating the policy • Will report them to the web application 13
  14. 14. XSS SUMMARIZED• Make sure you validate your inputs• Make sure you encode everything you output • Input to the web application • Data from backend systems • EVERYTHING!• Use CSP as an extra level of defense, its not the cure! 14
  15. 15. X-Frame-OptionsCLICKJACKING 15
  16. 16. CLICKJACKING• A malicious site loads the vulnerable site in an iframe• The iframe is invisible, and positioned in front of something the user is likely to click on• The user clicks on what appears to be an element on the malicious site • The user really clicks in the iframe, triggering some operation on the vulnerable site 16
  17. 17. CLICKJACKING DEMO Vulnerable site Evil site Delete something! Click me! 17
  18. 18. FRAMESNIFFING• You can specify an URL with an anchor when loading an iFrame• Browsers would scroll to the anchor tag, or the html element with the relevant id attribute• This scrolling can be detected with JavaScript• Note: Vulnerability has been fixed in latest versions of browsers 18
  19. 19. X-FRAME-OPTIONS• X-Frame-Options: Deny | SameOrigin• Instructs the browser to not display the page in a frame • When the page isn’t displayed, there’s nothing to click on!• Browser support: Opera 10.5, Chrome 4.1, IE 8, Firefox 3.6.9, Safari 4• Remember: The request is still sent to — and prosessed by — the web server! 19
  20. 20. X-FRAME-OPTIONS SEQUENCE DIAGRAM Attacker Target 20
  21. 21. Strict-Transport-SecurityHTTPS STRIPPING 21
  22. 22. HTTPS STRIPPING EXPLAINED• "Secure" websites use SSL/TLS to preserve the confidentiality and integrity of the communication with a browser• For usability, "secure" websites are still accessible through insecure channels (HTTP on port 80) • They’ll redirect the user to HTTPS • User enters www.onlinebank.com — and is redirected to https://www.onlinebank.com • The very first request is insecure, and open to attack!• SSL stripping is a middleperson attack • Attacker keeps the victim on HTTP, but passes requests on over HTTPS to the target website • Practical attack demoed at Black Hat in 2009 (sslstrip)http://www.thoughtcrime.org/software/sslstrip/ 22
  23. 23. HOW "SECURE BROWSING" USUALLY WORKS www.onlinebank.com (unprotected) Redirect: https://www.onlinebank.com (unprotected) https://www.onlinebank.com (protected) Online bank 23
  24. 24. HTTPS STRIPPING www.onlinebank.com (unprotected) https://www.onlinebank.com (protected) Response (unprotected) Response (protected) http://www.onlinebank.com (unprotected) https://www.onlinebank.com (protected) Attacker Online bank Response (unprotected) Response (protected) 24
  25. 25. DEMO 25
  26. 26. HTTP STRICT TRANSPORT SECURITY• Strict-Transport-Security: max-age=31536000; includeSubDomains • Max-age specifies for how many seconds the policy should be in effect • includeSubDomains — optional• Instructs the browser to only communicate to that hostname over SSL/TLS• Fails hard on certificate errors • The user does not have the option to click through certificate warnings • Browser support: Chrome 4+, Firefox 4+, Opera 12 26
  27. 27. Securing cookiesSESSION HIJACKING 27
  28. 28. SESSION HIJACKING EXPLAINED• Means getting access to a users privileged session -> steal session tokens• On the web, session tokens mean cookies• Protect the cookies!• Cookies can be marked with the "httpOnly" flag -> makes them inaccessible to JS, they wont be included in requests from applets.• Cookies can be marked with the "secure" flag -> instructs the browser to only send them with HTTPS requests 28
  29. 29. DEMO 29
  30. 30. X-Content-Type-Options: nosniffIE MIME SNIFFING 30
  31. 31. IE MIME SNIFFING• HTTP responses include a header stating what type of content is included • E.g. Content-Type: text/html; charset=utf-8• To compensate for misconfigured servers and bad programming, IE introduced MIME sniffing back in the days (IE4)• Some undesires side effects when IE guesses wrong• They introduced the "X-Content-Type-Options: nosniff " header in IE9 to disable the behaviour• Always serve your content with the correct content type, and the "X-Content-Type-Options" header• Demo! 31
  32. 32. COST/BENEFIT OF SECURITY HEADERS 32
  33. 33. ADDING HEADERS IS EASY• Benefits • Usually a single line of code in any "webpage" • Can often be added through config • Prevents well known attacks• Cost • Low • CSP can be expensive, might require rewrite of existing applications 33
  34. 34. SOME REFERENCES• Blog: Security through HTTP response headers • http://www.dotnetnoob.com/2012/09/security-through-http-response-headers.html• The NWebsec security library for ASP.NET • http://nwebsec.codeplex.com/• The NWebsec demo site • http://www.nwebsec.com/• The application used for demo here • https://github.com/klings/Booster2013 34
  35. 35. @klingsenTHANK YOU! 35

×