View
287
Download
0
Category
Preview:
Citation preview
© Zühlke 2016
Harness the power of HTTP headers to secure your web Apps
Drag picture to placeholder or click icon to add
Slide 1
© Zühlke 2016
whoami
Daniel GartmannSenior Software Engineer @ Zuhlke Engineering LtdMy job: Software Engineering ∩ SecurityTwitter: @daniel_gartmann Email: daniel.gartmann@zuhlke.com
Slide 2
© Zühlke 2016
Agenda
• What’s wrong with the Web?• HTTP Strict Transport Security (HSTS) • HTTP Public Key Pinning (HPKP) • Content Security Policy (CSP)• Conclusion
Slide 3
© Zühlke 2016
What’s wrong with the Web?
• It’s the most popular app-delivery platform we ever had• Core communication protocols are insecure• Web security is often misunderstood
Slide 4
© Zühlke 2016
What’s wrong with the Web?
Slide 5
1) Request some resources
2) Deliver some code3) Code is executed on the fly by the browser!
Browsers Remote Code Execution engines
© Zühlke 2016
What’s wrong with the Web?
Slide 6
© Zühlke 2016
Origin matters…
What are HTTPS security guarantees?• Authenticity verifying identities• Confidentiality keeping secret• Integrity safe transport
Slide 7
© Zühlke 2016
How to test/debug your config?
Slide 10
https://www.ssllabs.com/ssltest/
© Zühlke 2016
HTTP Strict Transport Security (HSTS)
Mitigate following UA TLS implementation weaknesses:• [no scheme]foo.com defaults to http://foo.com and not https://foo.com
( SSL Stripping)• Possibility to click through certificate errors
(expired, wrong host, self-signed, untrusted root,…, MITM)• Allow mixed content (to some extent – active vs passive)• Cookies not subject to SOP (redirect attacks – no secure flag)
HSTS Rewrite all HTTP requests to HTTPSHSTS All certificate errors are considered fatal
Slide 11
© Zühlke 2016
Without HSTS
Slide 12
© Zühlke 2016Slide 13
© Zühlke 2016
With HSTS
Slide 14
© Zühlke 2016
How does HSTS work?
Slide 15
1) Request a resource over HTTP
2) Redirect (302) to HTTPS
5) Cached by UA
6) Subsequent requests are all secure!
3) Execute redirect to HTTPS
4) Sets HSTS header: Strict-Transport-Security: max-age=31536000
© Zühlke 2016
HTTP request on HSTS enabled website
Slide 16
2) HTTP request
4) HTTPS request
3) Local redirect (307)
5) Response
1) HSTS cached by UA
© Zühlke 2016
Secure all your subdomains (if you can!)
Slide 17
a.foo.com
foo.com
b.foo.com
Strict-Transport-Security: max-age=31536000; includeSubDomains
© Zühlke 2016
How to (partially) revoke HSTS?
Slide 18
Strict-Transport-Security: max-age=0
chrome://net-internals/#hsts
© Zühlke 2016
Trust On First Use (TOFU)
• First request is at risk• Mitigation hardcode HSTS into UAs
• https://hstspreload.appspot.com/
Slide 19
Strict-Transport-Security: max-age=10886400; includeSubDomains; preload
© Zühlke 2016
HSTS deployment best practices
Low risk approach:• Configure redirection of all HTTP traffic to HTTPS • Add HSTS header with a low max-age (e.g. 1min) value• Extend policy with includeSubDomains (if possible!) • Ensure that all works fine and increase progressively the max-age (e.g.
to 12 months?)• Submit domain to be preloaded into UAs
Slide 20
© Zühlke 2016
HTTP Strict Transport Security (HSTS)
http://caniuse.com/#search=HSTS
Slide 21
© Zühlke 2016
HTTP Public Key Pinning (HPKP)
Protect against:• Rogue Certificate Authorities (CA) – Put everyone at risk• Compromised CAs – Put everyone at risk• MITM attacks
HPKP Limit your circle your trust!
Slide 22
© Zühlke 2016
How is trust established on the Web?
Slide 23
Certificate Authority
1) Identification “Alice”
2) PublicKeyAlice
3) thumbprintAlice = Sign(Alice || PublicKeyAlice, PrivateKeyCA)
4) CertificateAlice = [Alice, PublicKeyAlice, thumbprintAlice]
[PrivateKeyAlice, PublicKeyAlice]
[PrivateKeyCA, PublicKeyCA]
Verify(Alice || PublicKeyAlice, thumbprintAlice, PublicKeyCA)
1) CertificateAlice
© Zühlke 2016
Do you trust them all?
Slide 24
© Zühlke 2016
How bulletproof is the web trust model?
• Millions of certs are issued every year• Commercial Security (CAs profit, UAs vendors marketshare) • Any CA can issue certs for any domain (without asking permission)• The security is as good as the weakest link
Slide 25
© Zühlke 2016
How does HPKP work?
Slide 26
1) HTTPS request
3) Pins cached by UA
2) Sets HPKP header
Public-Key-Pins: max-age=5184000;pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18=";pin-sha256="K87oWBWM9UZfyddvDfoxL+8lpNyoUB2ptGtn0fv6G2Q=";includeSubDomains
Next connection/handshake – UA validates the certs using the cached pins!
© Zühlke 2016
What to pin? pin = base64(sha256(SPKI))
Slide 27
© Zühlke 2016
How to pin?
Slide 28
© Zühlke 2016
Where to pin?
Slide 29
No pinning accept all certs signed by all CAs present in the trust store
Pin the root cert accept all certs signed by a given CA
Pin the intermediary cert accept all certs signed by the given intermediate cert
Pin the leaf cert accept only a single cert – your cert!
© Zühlke 2016
Report pin-validation failures
Public-Key-Pins: max-age=2592000;pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ="; report-uri="http://example.com/pkp-report"
Slide 30
© Zühlke 2016
Deployment without enforcement
Public-Key-Pins-Report-Only: max-age=2592000;pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ="; report-uri="http://example.com/pkp-report"
Slide 31
© Zühlke 2016
Awesome tools out there – use them!https://report-uri.io/
Slide 32
© Zühlke 2016
HPKP deployment best practices
Low risk approach:• Define your pins (at least 2 – pin of current cert + backup cert), max-age,
report-uri, includeSubDomains …• Deploy HPKP using report only• Ensure that all works fine and remove the “-Report-Only”
Slide 33
© Zühlke 2016
HTTP Public Key Pinning (HPKP)
http://caniuse.com/#search=HPKP Slide 34
© Zühlke 2016
Content Security Policy (CSP)
CSP gives you the power to define a policy that restricts how your web apps get executed.
Protects against:• Code injection attacks - XSS• Clickjacking• Malicious content sources• More…
Slide 35
© Zühlke 2016
How does CSP work?
Slide 36
1) Request
2) Response with CSP header Content-Security-
Policy: policy3) CSP compliant
UAenforces policy on the fly
© Zühlke 2016
How does a CSP policy look like?
Content-Security-Policy: default-src 'none'; base-uri 'self'; block-all-mixed-content; child-src render.githubusercontent.com; connect-src 'self' uploads.github.com status.github.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com wss://live.github.com; font-src assets-cdn.github.com; form-action 'self' github.com gist.github.com; frame-ancestors 'none'; frame-src render.githubusercontent.com; img-src 'self' data: assets-cdn.github.com identicons.github.com collector.githubapp.com github-cloud.s3.amazonaws.com *.githubusercontent.com; media-src 'none'; object-src assets-cdn.github.com; plugin-types application/x-shockwave-flash; script-src assets-cdn.github.com; style-src 'unsafe-inline' assets-cdn.github.com Slide 37
© Zühlke 2016
Whitelist trusted sources
default-src directive defines the default list of trusted sources / schemes for the app being executed by the UA.
Slide 38
Content-Security-Policy: default-src 'self' ; Same origin policyContent-Security-Policy: default-src 'none' ;Content-Security-Policy: default-src http://foo.com;Content-Security-Policy: default-src http://foo.com http://boo.com ;Content-Security-Policy: default-src * ; Please don’t do that!
© Zühlke 2016
Whitelist trusted sources
default-src applies the defined policy to following directives (that can be overwritten for more specific behaviour):• script-src <script> • connect-src XMLHttpRequest, WebSocket and
EventSource• child-src <frame> and <iframe>. • font-src @font-face• img-src images and favicons• media-src <audio> and <video> • object-src <object>, <embed> and <applet> • style-src Stylesheets
Slide 39
© Zühlke 2016
Example 1/2
Slide 40
© Zühlke 2016
Example 2/2
Slide 41
© Zühlke 2016
Why is XSS so scary?
XSS enables an attacker to execute malicious code in victims browser’s context in order to:
• Steal users credentials• Hijack user session• Steal, modify or delete user’s data• Arbitrary code execution
Slide 42
1) Link with XSS payload
2) Click the link
3) Request with XSS payload
4) XSS payload “Reflected”
5) XSS payload is executed
© Zühlke 2016
What can CSP do against XSS?Examples of malicious injected payloads:
Primary defence against XSS is to always output encode untrusted data.
Consider CSP only as an additional layer of defence against XSS Think about no/partially CSP compliant UAs.
Once CSP is enabled it prevents execution of:• Inline scripts• Inline event handlers• Inline styles• Functions that generate code out of strings
Slide 43
© Zühlke 2016
CSP prevents inline JS / Event handlers
Slide 44
Injected payload
© Zühlke 2016
CSP prevents unsafe JS functions (string code)
Slide 45
Injected payload
© Zühlke 2016
Lax CSP
Slide 46
Avoid if possible!
© Zühlke 2016
What if you badly need an inline script?
Slide 47
1) hash = base64(sha256(alert(1);))2) add it to the script-src directive
Or use: https://report-uri.io/home/hash/
© Zühlke 2016
What if you badly need an inline style?
Slide 48
1) hash = base64(sha256(body {…}))2) add it to the style-src directive
Or use: https://report-uri.io/home/hash/
© Zühlke 2016
What can CSP do against XSS?
The reflected-xss directive configures the UA built in XSS filter against reflected attacks.Possible values:• Allow - Allows reflected XSS attacks• Filter - Filter the reflected XSS attack• Block - Block reflected XSS attacks Maximum security
Does not deprecate: X-XSS-Protection: 1; mode=block headerSlide 49
Content-Security-Policy: default-src 'self' ; reflected-xss block;
© Zühlke 2016
What can CSP do against Clickjacking?
Slide 50
© Zühlke 2016
What can CSP do against Clickjacking?
Mitigation Prevent malicious websites to frame your web app
Slide 51
Content-Security-Policy: default-src 'self' ; frame-ancestors * ;Content-Security-Policy: default-src 'self' ; frame-ancestors 'self' ;Content-Security-Policy: default-src 'self' ; frame-ancestors http://foo.com;Content-Security-Policy: default-src 'self' ; frame-ancestors 'none' ; Does not deprecate: X-Frame-Options: DENY | SAMEORIGIN |
ALLOW-FROM
© Zühlke 2016
CSP Reporting
Slide 52
Content-Security-Policy: default-src 'self' ; report-uri http://foo.com ;
© Zühlke 2016
Deploying CSP without breaking things
1) Define your policy e.g default-src 'self'2) Define your monitoring endpoint e.g report-uri http://foo.com3) Deploy in report only mode
Content-Security-Policy-Report-Only: default-src 'self' ; report-uri http://foo.com;
4) Ensure that all works fine5) Deploy without “-Report-Only”
Content-Security-Policy: default-src 'self' ; report-uri http://foo.com;6) Monitor when you get attacked
Content-Security-Policy:
Slide 53
© Zühlke 2016
Content Security Policy (CSP 1.0)
Slide 54
http://caniuse.com/#search=csp
© Zühlke 2016
Content Security Policy (CSP 2.0)
Slide 55http://caniuse.com/#search=csp
© Zühlke 2016
Content Security Policy (CSP 3.0)
Slide 56https://www.w3.org/TR/CSP3/
© Zühlke 2016
Specifications
Slide 57
© Zühlke 2016
Web platform is maturing towards a secure Web Platform
• HSTS, HPKP, CSP significantly reduce the attack surface• Use them with caution – don’t DoS yourself!• CSP is less risky than HSTS, HPKP• Security for FREE!• Start using them today!
Slide 58
Recommended