NDC OSLO — 19. June 2015 André N. Klingsheim @klingsen / #ndcoslo BOOSTING SECURITY WITH HTTP HEADERS 1 

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 

DEMO 3 

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 

CONTENT SECURITY POLICY Injection attacks 5 

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 

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/ 

CSP DIRECTIVES AND SOURCES 8 • A CSP policy consists of one or more directives with sources • Content-Security-Policy: directive1 source1 source2; directive2 source3 

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 

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 and • sandbox – mandatory support (was optional in CSP 1.0) • report-uri — Relative or absolute URL where CSP violations can be reported 10 

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 

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” 

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 

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: • 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.'); 

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 

DEMO 16 

IFRAME ATTACKS X-Frame-Options 17 

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 

CLICKJACKING Evil site Click me! Vulnerable site Delete something! 19 

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 

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 

HTTPS STRIPPING Strict-Transport-Security 24 

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 

HOW "SECURE BROWSING" USUALLY WORKS www.onlinebank.com (unprotected) Redirect: https://www.onlinebank.com (unprotected) https://www.onlinebank.com (protected) Online bank 26 

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 

DEMO 28 

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 

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 

DEMO 31 

LIMITING BROWSER TRUSTED CA’S Public-Key-Pins 32 

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 

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 

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 

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 

DEMO 37 

NWEBSEC Security headers for everyone 40 

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 

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 

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 

THANK YOU! @klingsen 44 SO, GO ENABLE THOSE HEADERS!