The other side of webapp security Luka Kladaric Sekura Collective luka@sekura.io @kll 1
Slide 1
Slide 2
What this talk is about Securing users, their browsers and computers. 2
Slide 3
What this talk isn’t about Securing your servers or the data on them. 3
Slide 4
Quick poll • Who here runs a website? • Does it support HTTPS? • Does it enforce HTTPS? • Does it have HSTS headers set? 4
Slide 5
HTTPS / SSL / TLS These mean subtly different things. In the context of web development A method of encrypting traffic to and from a web server using a server-provided certificate. 5
Slide 6
HTTPS (2) If the certificate is signed by a trusted party it also gives us a degree of confidence that the server we’re communicating with is actually authorized to speak on behalf of the website we’re trying to visit. Certificates can also be self-signed, or otherwise signed by an untrusted party. These are mostly worthless. 6
Slide 7
HTTPS (3) Once you’ve established the other side possesses a trusted 1 certificate, the chance you’re being MitM -ed or spied on drops by orders of magnitude. 1 MitM - Man in the Middle attack 7
Slide 8
Forcing HTTPS and pitfalls Forcing HTTPS means redirecting any plaintext traffic to HTTPS. It’s good in that it redirects people to the secure site, and you should definitely do that. 8
Slide 9
But it’s bad in many ways. 9
Slide 10
Forcing HTTPS - gotchas (1) Obscures/hides the fact that certain things still point to your plaintext address. Like... login form or oAuth callback pointed at http Users are successfully logged in, but the credentials are transmitted unencrypted first, before getting redirected to https. 10
Slide 11
Forcing HTTPS - gotchas (2) Takes people to the right place which means they will never update their bookmarks. 11
Slide 12
Forcing HTTPS - gotchas (3) Doesn’t usually work for non-human visitors - mobile apps and other clients, which generally construct each request from scratch rather than pick a link from the page they were served. So, if it works at all it just duplicates traffic where every single request is initiated over HTTP first and then bounced to HTTPS. 12
Slide 13
Forcing HTTPS - gotchas (4) Breaks POST requests which cannot be redirected. 13
Slide 14
Forcing HTTPS - gotchas (5) The redirect itself is not secure. An MitM attack could happen at this point, with the user continuing to browse the http site while the attacker proxies requests back and forth for the user over https with neither side being aware that anything is off. 14
Slide 15
Enter HSTS The magic bullet? 15
Slide 16
HSTS? HTTP Strict Transport Security 16
Slide 17
A response header that says "don’t even attempt to contact me over plaintext HTTP for X seconds." Strict-Transport-Security: max-age=31536000 17
^ What do browsers do instead? They rewrite all requests for http assets to https.
Slide 18
Include all subdomains The header can optionally apply to all subdomains, too. Strict-Transport-Security: max-age=31536000;↵ includeSubDomains 18
Slide 19
HSTS preload HSTS + long timeout + includeSubDomains + preload = win! Strict-Transport-Security: max-age=31536000;↵ includeSubDomains; preload 19
^ All major browsers ship with a list of domains that should never be accessed over plaintext.
Slide 20
HSTS gotchas (1) If you can’t force HTTPS, you can’t enable HSTS. 20
Slide 21
HSTS gotchas (2) If you have subdomains which don’t support HTTPS, or still need to receive plaintext traffic, you can’t enable “includeSubdomains”. 21
Slide 22
HSTS gotchas (3) If you can’t include subdomains, you can’t enable preload. Which means you still have that first request for users typing in your domain name or following an old link that is vulnerable. 22
Slide 23
HSTS is a must Start rolling it out today. It will hurt, but it will pay off. 23
^ It might take you a year to get to "preload". That is fine.
Slide 24
Secure cookies Cookies are used for various tracking and storage purposes, but the most critical use is to keep logged in state. To leak these is to let other people impersonate a legitimate user in their interaction with your website / application. 24
Slide 25
Secure cookies Absolutely make sure that all the cookies you are sending to your users have the “Secure” flag set on them, so that even if a plaintext HTTP request ever happens, they are not transmitted. 25
Slide 26
XSS XSS is bad. Don’t let XSS happen to you. The end. j/k 26
Slide 27
CSP Content Security Policy is an HTTP response header that reduces the risk of XSS in modern browsers by declaring which inline or external resources are allowed. 27
^ It lets you define which hosts the browser should whitelist for Javascript, CSS and image resources, AJAX requests, fonts etc, while blocking all others.
Slide 28
CSP It also lets you block all inline scripts except the ones explicitly whitelisted by several available methods. The combination of these two things makes XSS unusable on your website, despite any backend code flaws. 28
Slide 29
CSP - nonces A nonce can be used to whitelist inline scripts which contain no dynamic content. A single nonce can be used for all static inline scripts.
USE A DIFFERENT NONCE FOR EACH REQUEST! 29
^ Important: The scripts whitelisted this way can be of any content, so make sure you're not outputting any user input there.
Slide 30
CSP - hashes For scripts that are static but trusted, we can use hashes. 30
^ Crudest and simplest way to generate the necessary hashes is to let the browser yell at you (through the developer console) that you’re missing that specific hash.
Slide 31
CSP - final 31
Slide 32
CSP Report-Only Use Content-Security-Policy-Report-Only to log issues (to report-uri and console) without blocking any content while rolling out. 32
Slide 33
Questions? Luka Kladaric Sekura Collective luka@sekura.io @kll 33
Slide 34
Thank you! Luka Kladaric Sekura Collective luka@sekura.io @kll 34
