Half assed HTTPS; a lesson in insecurity from Santander

4 May, 2016 (unlisted)


A little over a month ago I contacted my bank (Santander), asking them why they served me their homepage insecurely.
To which they responded in an immensely helpful manner
Let's take a look at the page in question...
And here's what Chrome has got to say about the safety of the page

Why HTTPS everywhere matters

To be clear here, some of what they've said is correct. After clicking logon, and after arriving at the logon page, everything is secure. But that's not quite enough. Security is entirely dependent on arriving at the next page safely, which Santander cannot guarantee.
Let's talk about trust for a moment. A user types in the web address of their bank – correctly. They receive a page that looks identical to what they'd expect from their bank. The user, thus far, has no reason to suspect that the page they see is malicious. So the user trusts the page. Why? Because they're at the correct web address, and everything looks as it should. And after all they're not submitting any data, so they don't need to worry about HTTPS, right?
But an attacker in the network layer (on the LAN, or on the WAN) could trivially modify the insecurely served homepage – before the user had a chance to reach the secure logon page.
This is because HTTPS performs two major functions (that HTTP does not). It protects the data from being viewed in transit, and ensures the integrity of what is received.
Sure, on a lot of websites, integrity might not matter so much. But a bank... a bank is completely different. Integrity is of the highest priority here – especially when the homepage is the catalyst for a logon.
Without HTTPS, there is no way to be certain that the page you're looking at is the page the bank sent.

Exploit proof-of-concept

Using Fiddler, which acts as someone on the network would be able to; I am able to intercept the request for my bank's website, and replace it with an identical looking one – with a single change – the function of the logon button.
If I wanted to be less obvious about the change, I could buy a very similar looking domain, say "santanber.co.uk", or "santander.co.uk.securelogin.token.0nqtianudb01jb.co", and create a fake login page to capture login credentials. Since I'd own the domain, I could even set up an HTTPS certificate on it – such not to raise any red flags there.
If I didn't care about using HTTPS on my phishing site, I could just direct to any insecure location on the real "santander.co.uk", and intercept the subsequent requests to inject a login page. "santander.co.uk/login" would look very legitimate.

Manual Mitigation?

I tried manually specifying the HTTPS protocol "https://www.santander.co.uk/", let's take a look at what happened.
Okay, so it looks like they have got a valid certificate for the domain, yet they use it exclusively to drop the user back down to insecurity. What about a more aggressive approach?
Here I'm manually setting an HSTS (HTTP Strict-Transport Security) policy, telling Chrome not to allow HTTP connections to santander.co.uk
This was the result
What happened here? Well we see that Chrome (as instructed) interrupts the HTTP request, and upgrades to HTTPS
However, the response from Santander drops me right back down. Chrome gives up eventually, and refuses to load the page after too many redirects back and forth.
So where does that leave us? Well, since the login page is secure, but there is no way to get to the homepage securely (even forcefully). A sensible option would be to save a bookmark to take you straight to the login page. Not ideal, but one step more convenient than manually verifying you're still on the website you think you should be after clicking logon.

Non-login based exploits

No Santander, 'security' software should never be downloaded over HTTP.
Actually, in practice the page shown links to another page, and doesn't begin the download straight away. But there's no reason an attacker can't make it easier to install malware than the legitimate software...
Needless to say, the file that was downloaded was not the security software they intended. Luckily I chose it to be an empty .exe file, but it could have been anything.

Extra credits

If you think I'm being mean to Santander, don't worry, here are some other sites that should probably never see HTTP. Ever.


Santander makes a half assed attempt at HTTPS. They use it exclusively to secure privacy of submission, but not the integrity of the pages leading up to login. The Santander homepage is unsafe. On this page, Santander facilitates a trivial man-in-the-middle attack on their users. Not least by serving an insecure webpage, but also by encouraging the initiation of login actions from that unsafe webpage. There is no reasonable assumption that any of their users will arrive at the correct login page. If they do, it is because they have been lucky enough not to have had their requests intercepted, and not because Santander has made an effort to ensure their safety.
It is unfortunate that Santander chooses to engage in such security anti-patterns. Even more so that they represent one, in a group of banks that are similarly negligent. For a major bank, the security of customers should be paramount; and given the breadth of resources available to a bank of their size, behaviour such as this leans toward inexcusable.
Santander, fix your damn website.


Questions, clarifications, corrections? Contact me on Twitter @aidantwoods
17 Apr, 2017

Leveraging the new RPi0w to build a WiFi enabled keystroke injection tool (a.k.a. USB Rubber Ducky with WiFi)...[read more]

28 Mar, 2017

The other day I noticed something cool in Chrome. I can disable JavaScript and cookies + local storage on HTTP!...[read more]

1 Jan, 2017

Recently I've been working on a drop in class to manage certain "Secure Headers" in PHP.

By "Secure Headers", I'm of course talking about those mentioned in the OWASP Secure Headers Project.

The project, SecureHeaders is available on GitHub.


If you're familiar with PHP, you'll know that...[read more]

27 Aug, 2016

Disclosure and Google's Response

This one feels very strange writing, because the vulnerability detailed below is currently exploitable. Google has been notified of this vulnerability, yet they have chosen to do nothing.
GoogleThanks for your bug report and research to keep our users secure! We've investigated your submission and made the decision not to track it as a security bug.
In hope that public disclosure will encourage Google to do otherwise, here goes...[read more]
2 May, 2016
In this post I'll address one specific task: obtaining a manual certificate from Let's Encrypt.

Who is this for?

If you don't have direct command line access, or the necessary permissions to install Let's Encrypt on your webserver; then you won't be able to obtain a certificate using the automated process.
If you can install Let's Encrypt on your webserver, you should. It simplifies the process down to a single command. You'll also enjoy the benefits of being able to setup an auto renew process directly on the machine serving the certificate...[read more]