Really!?
I thought people were moving away from allowing CORS due to the magnitude of problems it causes down the line
1 Like
Nothing wrong with a properly secured CORS endpoint. I’d prefer it to JSONP anyway, you have far greater control over the allowed origins and HTTP methods in use.
2 Likes
Ah fair enough. I’ve always preferred JSONP but I mainly do backend anyway.
By not adding the header, security is not improved.
By adding the header, at the very least, you improve security, and there are no side effects to this header, provided you aren’t using non-HTTPS anywhere on your site.
It’s such a trivial thing to add, isn’t it worth having just for the sake of argument?
You’re not wrong, and the header should absolutely be added… but it’s not anywhere near as big a risk as the scary red page suggests.
Firstly, HSTS without preload is still going to be trust on first use. Given most browsers cache the 301 from HTTP → HTTPS there’s going to be some protection against sslstrip there anyway. And “without the user’s knowledge” is incredibly misleading. You’re not going to be able to present a valid certificate for api.monzo.com so you’ll either get a huge scary certificate warning or you’ll just serve it in plaintext over HTTP which gives me a nice red Connection is not secure warning in Firefox.
I also have no idea which session cookie you’re talking about. Auth to the API is done by sending an Authorization header with a bearer token. Can you clarify what you mean?
There’s generally a reason why all of the bug bounty programmes I’ve seen won’t pay for reports that consist solely of missing security headers, and that’s because there’s not actually an interesting or practical vulnerability being disclosed that presents a risk for them to worry about
I’ve just re-read the report and it looks like it’s a Cloudflare tracking cookie.
Set-Cookie __cfduid=db9c(trunc)671844; expires=Mon, 22-Oct-18 11:30:44 GMT; path=/; domain=.monzo.com; HttpOnly
So probably not worried too much about that one.
2 Likes
Why does CloudFlare need to include these?! Unless they are handling the analytics for the site I see no real reason for them to create cookies of their own.
This refers to the API usage within the app itself. For example, I’m in the Android app, and I request to send some money, the API request is MITM intercepted and re-directed to a HTTP-request, which wouldn’t necessarily be seen as invalid due to the missing HSTS flag, and the redirected HTTP request can then be modified in transit.
If the client is preventing redirects from the API, and checking the server certificate on each request, then you are correct, the HSTS header will be largely irrelevant - but if any third parties are talking to your API, they may have not implemented the same client-side precautions.
Sure, but the SSL pinning and hardcoded HTTPS URL make this purely theoretical in the official app.
As for other apps, the Monzo API docs explicitly use HTTPS URLs consistently throughout the entire documentation. You’d have to be a special kind of stupid to deliberately change it back to a HTTP URL and somehow get that through code review 
And even if HSTS was there, do any Java REST clients support it? I’m not convinced this would help given your threat model. As @TonyHoyle has stated, you’d need to implement the HSTS support yourself and given you’re not using secure URLs in the first place you probably have no idea what you’re doing.
1 Like
I think it’s one of the methods they use to detect bots, and is possibly used in request throttling, and maybe also persistent-endpoint load balancing. So a continuation (session) request will be repeatedly redirected to the same IP in a situation where multiple IPs are available to serve a single domain.
2 Likes
If they haven’t implemented basic certificate checks it’s unlikely they’ll be checking HSTS either…
I would assume the majority of users won’t be talking to the API directly, there will be ways to do it properly in a multitude of languages… not least because of the things you point out - not everyone is aware of how to write secure code.
1 Like
lol, I think you’ve missed how MITM works here - the client will make a request to connect to https://api.monzo.com - that’s all groovy. The problem is when a MITM attack injects packets into the connection during the DNS resolution request and the SSL/TLS handshake, downgrading the request to a HTTP one (it’s a bit more complex than that, but you get the idea) and redirecting the website traffic to an endpoint of the hacker’s choice.
That’s what HSTS is designed to prevent - if the browser (or client) knows that the website is only allowed to be served over HTTPS, then this trivial attack becomes impossible.
1 Like
Of course this has issues - if your SSL certificate expires or you muck up the configuration your website becomes completely inaccessible because there is no downgrade to HTTP. But it is generally a very good idea.
In the WPA2 vuln demo, SSL strip was used as a demonstration on Match.com to downgrade to HTTP - if they had implemented HSTS this wouldn’t have been possible.
Ah yes, but a number of clients will potentially be using Javascript, through a browser. Especially with Progressive Web Apps on the horizon. So they will assume this functionality is part of the security baked into standard browser webkits.
Secondly, if Monzo doesn’t provide the header, then the client can’t implement it, and its Monzo’s fault.
If Monzo does provide the header and the client doesn’t implement it, then Monzo has limited liability.
1 Like
I’m not seeing what HSTS brings to the table there. If you’re talking to the monzo API through HTTPS you’re going to expect a valid certificate back, and normally checking that it has the same fingerprint as the api certificate you were expecting (checking for simple validity not really being sufficient, this being a banking application). If something has MITMed your connection you won’t get any certificate back at all, or you’ll get a different one, so that will fail.
No, I don’t get the idea.
If the URL is HTTPS, the client will connect on port 403 and negotiate a secure connection. There’s nothing you can do with DNS that will downgrade it.
Can you provide a link to the paper describing the attack you’re talking about so I can understand exactly what you’re suggesting?
Here’s the slide describing sslstrip from Blackhat '09:
Note it’s just rewriting URLs that are referenced from a site served in plaintext. There’s no way it’d be able to rewrite URLs in a client application that were hardcoded to use https://api.monzo.com.
2 Likes
Downgrading to HTTP is never a workaround for a bad certificate. Worst case scenario, you can get a free certificate in under 5 minutes from Let’s Encrypt, while you work out how to get a better one.
Easier than that, you throw up a ‘Maintenance Page’ - which is one of the features provided by Cloudflare, which still serves over HTTPS, and doesn’t touch your servers in the meantime.
1 Like
A banking app in javascript?
…
Anyway, it doesn’t absolve the developer for responsibility for checking the connection is properly secured and they have the right certificate. Even if HSTS was implemented you’d do that.
Totally agree - but this is sometimes what ends up happening.
10 years ago that quote would have been “A banking app?”
Check out Progressive Web Apps. They are websites that use ServiceWorkers and manifests to allow the website to be “installed” to the desktop. Currently only available on Chrome and Android.
1 Like