The other side of webapp security
A presentation at Webcamp Zagreb in in Zagreb, Croatia by Luka Kladaric
The other side of webapp security Luka Kladaric Sekura Collective luka@sekura.io @kll 1
What this talk is about Securing users, their browsers and computers. 2
What this talk isn’t about Securing your servers or the data on them. 3
Quick poll • Who here runs a website? • Does it support HTTPS? • Does it enforce HTTPS? • Does it have HSTS headers set? 4
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
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
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
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
But it’s bad in many ways. 9
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
Forcing HTTPS - gotchas (2) Takes people to the right place which means they will never update their bookmarks. 11
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
Forcing HTTPS - gotchas (4) Breaks POST requests which cannot be redirected. 13
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
Enter HSTS The magic bullet? 15
HSTS? HTTP Strict Transport Security 16
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.
Include all subdomains The header can optionally apply to all subdomains, too. Strict-Transport-Security: max-age=31536000;↵ includeSubDomains 18
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.
HSTS gotchas (1) If you can’t force HTTPS, you can’t enable HSTS. 20
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
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
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.
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
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
XSS XSS is bad. Don’t let XSS happen to you. The end. j/k 26
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.
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
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.
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.
CSP - final 31
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
Questions? Luka Kladaric Sekura Collective luka@sekura.io @kll 33
Thank you! Luka Kladaric Sekura Collective luka@sekura.io @kll 34
Protecting your backend and database is fine, but what about the users? How do we protect them, their browsers and computers?
There's a lot of focus on backend security, best practices, how to store passwords, how to do password recovery, encryption at rest, etc. But to exploit any of those someone needs to target a website specifically, and put a lot of effort into it.
But the users of those websites are exposed every day, and they access them through various insecure networks, including hotel and coffee shop wifi.
In this talk we will cover the usual suspects: HTTPS and certificates, but also talk about some newer tech like HSTS and CSP.
Video
Buzz and feedback
Here’s what was said about this presentation on social media.
