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
   

   View Slide

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
   

   View Slide

3. DEMO
   3
   

   View Slide

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
   

   View Slide

5. CONTENT SECURITY POLICY
   Injection attacks
   5
   

   View Slide

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
   

   View Slide

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/
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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

    View Slide

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
    

    View Slide

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”
    

    View Slide

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
    

    View Slide

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: <br/>• Prevents XSS – attacker must guess correct nonce in header to inject valid content<br/>• Hashes<br/>• Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=‘<br/>• Lets this execute: <script>alert('Hello, world.');
    

    View Slide

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
    

    View Slide

16. DEMO
    16
    

    View Slide

17. IFRAME ATTACKS
    X-Frame-Options
    17
    

    View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

22. HTTPS STRIPPING
    Strict-Transport-Security
    24
    

    View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

26. DEMO
    28
    

    View Slide

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
    

    View Slide

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
    

    View Slide

29. DEMO
    31
    

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

35. DEMO
    37
    

    View Slide

36. NWEBSEC
    Security headers for everyone
    40
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide