Secure Connections. How Do They Work?
Modern browsers play a big part in web application security. They are responsible for establishing a secure connection with the web application, managing and verifying SSL certificates, warning users of potential security issues and securely storing session tokens. This represents a large attack surface, wherein many things can go wrong. This is one of the reasons why most browsers run in a security sandbox, which can help limit the impact of security vulnerabilities. But that’s another article.
One downside to these security controls is that many of them must be manually set by an application (or web server). Some via HTTP response headers, others via specific Cookie flags. Unfortunately, this means that many developers who aren’t security-conscious simply don’t know about them. Not knowing about the controls means they won’t implement them, leaving their users unprotected. This is Bad™.
In this article we’ll take a brief look at two specific security controls and how they work together. In case you hadn’t guessed, we will be looking at the Strict-Transport-Security HTTP header and the Secure Cookie flag.
Strict-Transport-Security
The HTTP Strict-Transport-Security response header (HSTS) is an HTTP response header which tells the user’s browser to perform all subsequent requests to a site using HTTPS instead of HTTP. This means that the browser will not send any data to an unsecured version of the site, until the Strict-Transport-Security header expires.
Secure Cookie Flag
The Secure flag is an option which can be set on cookies when they are issued by a website. This flag ensures that the cookie in question is only ever sent when it has been encrypted, such as when using HTTPS.
Do you see where we’re going yet?
Holy Union
Now. Lacking either one of these security controls individually isn’t TOO serious of an issue. However, if neither of them are set, then problems can arise.
On an unsecured or shared connection (such as a coffee shop, London Underground WiFi, etc) bad guys who can intercept network traffic may be able to capture information exposed in the first unencrypted request to an HTTP URL.
When you type in onlyfans.com, your browser will send an HTTP request to ‘onlyfans.com’ – which will then redirect you to ‘https://onlyfans.com’. In this first request, you can leak sensitive data on an unencrypted connection. Without either of the above security controls implemented, a hacker can abuse this to steal session cookies and hijack your account.
Story Time
Scenario! A user is at home, browsing the internet. On their phone, the absolute animal. Anyway. Dear user decides to visit the Next website, to buy some wavy garms. They register to the website and fill out their details; full name, mothers’ maiden name, address, favourite colour, postcode – the works.
Note: www.next.co.uk is an arbitrary URL that we picked from a hat. No hard feelings. Don’t sue us.
Hmm! Does this site have any security in place? Our user is indifferent, but us hackers are a curious lot. Let’s look at the HTTP response we get after logging in (trimmed for brevity):
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html; charset=utf-8
Location: https://www.next.co.uk/secure/account/myaccount
Content-Security-Policy: frame-ancestors 'self' iguidewebapp.next-uk.next.loc/ end-duws02.next-uk.next.loc/ end-dpws02.next-uk.next.loc/ studio.mgmt.qa.test/ studio.mgmt.next-uk.next.loc/
Set-Cookie: Next-AP=accountEmail=[..]&Version=[..]; expires=Tue, 08-Apr-2070 09:27:02 GMT; path=/; HttpOnly
Set-Cookie: NextSaleAuth=AccountNo=[..]&Version=[..]&AuthToken=[..]&Timestamp=[..]&SourceSite=Main&ReadVIPSalePopUpModal=False; path=/; HttpOnly
Set-Cookie: bm_sv=[..]; Domain=.next.co.uk; Path=/; Max-Age=4523; HttpOnly
[..]
Now, there are couple things to point out about this response:
- three cookies have been set by the application; “Next-AP”, “NextSaleAuth”, and “bm_sv”
- they’ve implemented the
HttpOnly control on all cookies - they’re using a
Content-Security-Policy header. Good stuff!
However:
- the
Strict-Transport-Security header is missing - the
Secure flag has not been set on any of the cookies.
Back to the story. Let’s say our user visits their local coffee shop. They order a super soy express macchiato, to drink in. Because, well..:
While at the coffee shop, our user connects to the free WiFi and decides to continue their shopping. The user enters www.next.co.uk into their browser.
- SUDDEN CUT TO BLACK -
The Issue
Here is the problem. If the user types the address into their browsers’ address bar as above, their browser will send the first request to the site over HTTP instead of HTTPS. (yes, there are exceptions, stop interrupting.)
This request will include all the login cookies that the user has stored.
Ahem. This request will include all the login cookies that the user has stored.
As the Strict-Transport-Security header hasn’t been set for the site, the browser will allow the request to be made over HTTP. In addition, as the site didn’t set the Secure flag on cookies, those login cookies will be sent over the unsecured connection.
Unbeknownst to the user, a hacker is sitting in a dark corner of the coffeeshop with his hoody on. Our hacker is connected to the same WiFi. He is intercepting all network traffic and looking at the data scroll by in big green letters, matrix-style.
When our poor user attempts to load www.next.co.uk on his phone, the phone sends a request to www.next.co.uk over HTTP. That request is captured by the hacker. Because that request is not sent over a secure channel (HTTPS), the hacker can easily read the contents of the request – including session information.
The following screenshot shows the full request captured by our friendly neighbourhood hacker (using tcpdump):
The hacker can now use this session information and authenticate to the application, impersonating the victim and gaining access to their private information.
Conclusions
So, what is one to do? Some may argue that a user attempting to connect to their site over an unsecured connection is “not my problem”. This is missing the point. Existing protections are available and easy to implement.
Let’s Encrypt, a service which lets you generate SSL certificates for your websites, is FREE. And that’s a great price! Also, users don’t care if they’re at fault for a security breach, they will want you to fix it. It’s prudent to implement strong security controls to protect your brand’s reputation.
Web application security is a vast and complicated topic. Each aspect of application security is as important as the others. Use the tools you have available! On that note, there are other security flags you can apply to cookies – expect an article on the SameSite cookie flag soon.
For further reading, consult the amazing Mozilla Developer Network for information about how to correctly implement HSTS and the Secure cookie flag.