Boosting Security With HTTP Headers (NDC Oslo 2015)

Boosting Security With HTTP Headers (NDC Oslo 2015)

Bf3b9a6082fa3a5318ce25b623d600d8?s=128

André N. Klingsheim

June 19, 2015
Tweet

Transcript

  1. 1.

    NDC OSLO — 19. June 2015 André N. Klingsheim @klingsen

    / #ndcoslo BOOSTING SECURITY WITH HTTP HEADERS 1
  2. 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. 3.
  4. 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. 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
  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/
  7. 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
  8. 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
  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
  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
  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”
  12. 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
  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>
  14. 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
  15. 16.
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 26.
  22. 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
  23. 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
  24. 29.
  25. 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
  26. 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
  27. 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
  28. 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
  29. 35.
  30. 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
  31. 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
  32. 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