Boosting Security With HTTP Headers (NDC Oslo 2015)

Transcript

1. NDC OSLO — 19. June 2015 André N. Klingsheim @klingsen / #ndcoslo BOOSTING SECURITY WITH HTTP HEADERS 1
2. OUTLINE • HTTP headers • Why use security headers? • Web application attacks and security headers • Injection attacks — Content Security Policy (CSP) • Iframe attacks — X-Frame-options (XFO) • SSL stripping++ — HTTP Strict Transport Security (HSTS) • Middleperson attacks with certificates from rogue CA — Public Key Pinning (HPKP) • On the horizon • NWebsec 2
3. DEMO 3
4. WHY SECURITY HEADERS? • Opt-in to modern browser security features • Mitigates well known attacks • Ease of use • Library support • Can be added through config • Or a single line of code when generating a web response • Low cost • CSP can be more challenging, might require rewrite of existing applications 4
5. CONTENT SECURITY POLICY Injection attacks 5
6. INJECTION ATTACKS • 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. CONTENT SECURITY POLICY (CSP) • Policy for where content in your webpages can be loaded from • Restrictions on script execution • Headers • Content-Security-Policy – enforces policy • Content-Security-Policy-Report-Only – Won’t break your site, but reports • Supported in Opera 29, Chrome 25, Firefox 31, Safari 7, iOS Safari 7.1, (Android/Chrome) • Support underway in Edge! • Comes in «two versions» • CSP 1.0, supported by most browsers (not IE, coming in Edge) • CSP level 2 is “brand new”, so partial support in browsers (Opera, Chrome, Firefox) 7 http://www.w3.org/TR/CSP1/ http://www.w3.org/TR/CSP2/
8. CSP DIRECTIVES AND SOURCES 8 • A CSP policy consists of one or more directives with sources • Content-Security-Policy: directive1 source1 source2; directive2 source3
9. CSP 1.0 DIRECTIVES • default-src — Specifies the fallback for sources not specified • script-src • style-src • object-src — plugins • img-src • media-src — video/audio • frame-src • font-src • connect-src • report-uri — Relative URI where CSP violations can be reported 9
10. CSP 2 DIRECTIVES • base-uri • child-src - applies to “nested browsing contexts” (e.g. iframe) and Worker execution contexts. • Replaces frame-src from CSP 1.0 • frame-src - now deprecated • form-action • frame-ancestors – Intended to replace X-Frame-Options • plugin-types – Whitelists media types for <embed> and <object> • sandbox – mandatory support (was optional in CSP 1.0) • report-uri — Relative or absolute URL where CSP violations can be reported 10
11. CSP SOURCES (FOR THE DIRECTIVES) • Content-Security-Policy: script-src 'none' • Content-Security-Policy: script-src 'self' • Content-Security-Policy: script-src 'unsafe-inline' — Supported by style-src (inline css) and script-src (inline script) • Content-Security-Policy: script-src 'unsafe-eval' — Supported by script-src • Content-Security-Policy: script-src * • Content-Security-Policy: script-src https: • Content-Security-Policy: script-src *.nwebsec.com • Content-Security-Policy: script-src https://www.nwebsec.com 11
12. DIRECTIVES WITH SPECIAL SOURCES 12 • sandbox • allow-forms • allow-pointer-lock • allow-popups • allow-same-origin • allow-scripts • allow-top-navigation • plugin-types • E.g. “application/pdf”
13. THE DEFAULT-SRC • Content-Security-Policy: default-src 'self'; script-src 'self' scripts.nwebsec.com • Sources not listed fall back to 'self‘ (style-src, img-src…) • script-src is defined, overrides default-src • In effect, stylesheets, images, flash animations, Java applets etc can only be loaded from the same origin as the page • This policy denies inline scripts and CSS! 13
14. CSP 2 HASHES AND NONCES 14 • Lets apps with inline script/style benefit from CSP 2.0 • Nonce – “number once” • Nonces are used to whitelist inline scripts and styles • Nonce included in header and in script element: <script nonce=“somenonce”> • Prevents XSS – attacker must guess correct nonce in header to inject valid content • Hashes • Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=‘ • Lets this execute: <script>alert('Hello, world.');</script>
15. CSP REPORTING • You can specify a "report-uri" in the CSP header • Must be a relative or absolute URI • Posts JSON violation reports • Content-Security-Policy-Report-Only • Will not block scripts or resources violating the policy • Will report them to the web application 15
16. DEMO 16
17. IFRAME ATTACKS X-Frame-Options 17
18. 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 18
19. CLICKJACKING Evil site Click me! Vulnerable site Delete something! 19
20. OTHER INTERESTING FRAME ATTACKS • Framesniffing (2012) • You could 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 could be detected with JavaScript • Note: This was later fixed in browsers 20
21. X-FRAME-OPTIONS • X-Frame-Options: Deny | SameOrigin | (Allow-From https://nwebsec.com) • 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 • Always send the header unless you intend to be “iframed” • Mitigates the entire class of iframe attacks • MVC 5 protection is tied to AntiForgery (CSRF) • Remember: The request is still sent to — and prosessed by — the web server! 21
22. HTTPS STRIPPING Strict-Transport-Security 24
23. 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/ 25
24. HOW "SECURE BROWSING" USUALLY WORKS www.onlinebank.com (unprotected) Redirect: https://www.onlinebank.com (unprotected) https://www.onlinebank.com (protected) Online bank 26
25. HTTPS STRIPPING (http://)www.onlinebank.com (unprotected) Response (unprotected) https://www.onlinebank.com (protected) Online bank Attacker Response (protected) http://www.onlinebank.com (unprotected) https://www.onlinebank.com (protected) Response (protected) Response (unprotected) 27
26. DEMO 28
27. HTTP STRICT TRANSPORT SECURITY (HSTS) • TOFU (Trust On First Use) • 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 • Browser support: Chrome 4+, Firefox 4+, Opera 12, Safari • IE 11 added support last patch tuesday! 29 - XSS (Cross Site Scripting) Prevention Cheat Sheet - OWASP Top 10 for JavaScript – A2: Cross Site Scripting – XSS
28. HSTS (CONT.) 30 • HSTS was recently updated with a “preload” directive • Strict-Transport-Security: max-age=31536000; includeSubdomains; preload • Lets you register your domain as “HSTS-always” • Max-age must be 18 weeks • Must include “includeSubdomains” token • Must include (new) “preload” token • Submit your site at: https://hstspreload.appspot.com • Preload list is used by Opera, Chrome, Firefox, and IE • Demo
29. DEMO 31
30. LIMITING BROWSER TRUSTED CA’S Public-Key-Pins 32
31. PROBLEMS WITH BROWSER TRUST • Browsers have a long list of trusted CA certificates • A cert issued by ANY of these CA’s for your site -> trusted by browser • One compromised CA -> most sites on the web can be impersonated in a middleperson attack • Famous example, Diginotar (2011). • Fraudulent certs for google services, Yahoo!, Mozilla, Wordpress, The Tor project • Google detected fraudulent certs due to their built-in pinning in Chrome • Diginotar trust revoked by all browser -> Diginotar out of business 33
32. PUBLIC KEY PINNING (PKP) 34 • TOFU (Trust On First Use) • Public-Key-Pins: max-age=3000; pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=" • Pin value: the hash over the Subject Public Key Info element in the certificate -> identifies the key type and the public key • Browser checks site’s certificate chain • TLS connection fails if none of the certs have a pinned key • Browser support: Chrome, (Opera?), Firefox. Edge «under consideration» - http://tools.ietf.org/html/rfc7469
33. PKP (CONT.) 35 • You can only pin certs with “public trust anchors” • This means the stock list of CA’s in your browser • Pinning certs with “private trust anchors” are not supported • Reasoning is that these are “friendly middlepersons” • “Data loss prevention appliances” • Firewalls • Content filters • Fortunately, this setting can be overridden in Firefox, enables internal testing
34. PKP DEPLOYMENT CONSIDERATIONS 36 • Must include two pins to be valid • You pin the public key for (at least) one active certificate • MUST provide at least one backup pin • Securely stored (offline) certificate/csr for disaster recovery • Do this wrong, and you shoot yourself in the foot
35. DEMO 37
36. NWEBSEC Security headers for everyone 40
37. WHAT NWEBSEC PROVIDES 41 • Lets you configure and set security headers through • Web.config (HTTPModule) • OWIN middleware • MVC filter attributes • Set global policy by web.config or middleware • Full or partial override through attributes • Validates configuration • Sets syntactically correct headers - a simple typo voids protection • Particularly useful for CSP
38. SECURITY HEADER LIBRARIES 42 • Nwebsec (ASP.NET) • helmet (express/node) • secureheaders (rails/sinatra/padrino/ruby) • highlines (j2ee/java) • secureheader (go) • laravel-secureheaders (php) • django-csp + commonware (Django/Python) • Dancer-Plugin-SecureHeaders (Perl) • ring-secure-headers (Clojure) • mod_secure_headers (apache) Thanks to @ndm, Neil Matatall, for sharing this list with me
39. A FEW 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 • https://github.com/NWebsec/NWebsec • https://www.nuget.org/packages?q=nwebsec • The application used for demo here • https://github.com/klings/NDC-Oslo-2015 43
40. THANK YOU! @klingsen 44 SO, GO ENABLE THOSE HEADERS!