Hacker News Reader

Comment by _jomo | Hacker News Reader

> If you’re submitting your login form over HTTPS, that’s good, but it’s not enough. You have to deliver* the form over HTTPS too.*

I'm glad they mentioned it. Too many people think their sites are secure if logged in sessions use https and everything else is http.

Their example is that an attacker could insert JavaScript to steal the password, however they could just as well change the form target from https to http which is even less noticeable.

There's also a more detailed post [0] with reasons and explanations. You can enable this setting in Firefox 44+ by setting `security.insecure_password.ui.enabled` to true.

0: https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-...

View on HN

As I understand it, if not everything is HTTPS, the attacker could just inject JavaScript that changes the page to the login page when the user clicks "Log in". That way, they can still record the password.

Yes, it's disturbing how many sites still do this. Most of the big shopping sites like amazon.com, ebay, Target, WalMart are http until you log in. Was also until recently very common on credit card sites, though all of mine are all https now.

This is because most people are browsing and not buying, so the caching advantages of unsecured catalogue pages is likely quite large.

At least for most of those the login is a separate protected page rather than a https iframe.

I wonder if even simply the overhead of setting up and encrypting the secure connections even just by itself has a measurable effect on people's buying behavior.

Uhh, what caching advantage are you talking about? Everything that can be served cached over HTTP can also be served cached over HTTPS. Unless you are talking about a caching proxy outside of the website control. In that case, they aren't needed, CDNs solved that problem in a much better way.

> Unless you are talking about a caching proxy outside of the website control. In that case, they aren't needed, CDNs solved that problem in a much better way.

There are still parts of the world where caching proxies are used to conserve limited transit bandwidth; CDNs don't solve that.

"Everything that can be served cached over HTTP can also be served cached over HTTPS. "

Only if you're taking about a browser cache. Any other cache couldn't intercept the data and cache it without alerting the browser (unless you mess around with installing SSL certs).

Yes but the "login" link, the "add to cart" link, etc. is all served over http so could be replaced by a MITM.

Amazon cares much less about your security than about the fact that tiny increases in latency decrease conversion dramatically.

You don't have to wait for the user to click anything. Just read each key press and send a message out.

Hard to believe this is still a common vulnerability. Of course, even in 2007 a significant number of bank and credit card web sites operated like this.

The Tunisia government actually did this.

http://m.theregister.co.uk/2011/01/25/tunisia_facebook_passw...

If the attacker has ability to inject code, can't they simply redirect you to non-https version of the website on their servers anyway?

They could. But how would they show the users their desired contents after login?

Doesn't matter, they've already gotten your password at that point. They can just say "login failed" and redirect you to the real login page

That's one of the reasons why HSTS [1] was invented. Basically your website itself informs the browser to never contact it though http. Then a man-in-the-middle, which can inject whatever in any http pages you visit, simply cannot inject (nor replace) your website ever, because they (supposedly) cannot fake a valid certificate covering your domain.

You can even submit your domain [2] so that current browsers automatically apply the https-only preference to your domain, even when it hasn't ever been contacted before. Cool, isn't it?

[1] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [2] https://hstspreload.appspot.com/

For too long popular a lot of popular gambling sites such as betfair and skybet have done this. I think betfair now is all https, but I'm not sure of skybet (and I can't be checking while at work).

Betfair is finally using all https. Their security was terrible because once you logged in, the site went back to http again. This meant that anyone on the same network could grab your cookies and take over your account...

That's not the half of it - if you knew what that cookie contained…

Like... login and cleartext password, to lookup your profile on each request?

$sql = "select * from user where username='".$_COOKIE['username']."'";

Came across this last year... have seen variations of it over the last 15+ years, but saw it in 'new' code last summer. :/

Sad reality of rising kids with the notion that security is about forms and passwords and not about hacking stuff.

Isn't betfair the one where the password reset email was sent to the email in a hidden input field which you could change yourself....?

Is there a caching story to tell, here? In other words, is it possible that most web infrastructure is set up in such a way that caching is used to mitigate much of the load on the servers, and moving too many things to HTTPS too quickly would result in a MUCH greater content generation load?

That kind of caching is actually extremely rare in my experience. It's difficult to set up for all but the most simple static sites, and since it isn't available by default the vast majority of sites don't bother.

The times I've implemented full-page caching (generally using Varnish) I've set it up so nginx runs in front of Varnish handling SSL termination, which means that I still have SSL support even though I'm serving through a cache.

So how do you avoid this?

Force TLS on all pages and subdomains, send the Strict Transport Security header, and preload your site (https://hstspreload.appspot.com/).

Reply on news.ycombinator.com