6 ms·

> 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.

by _jomo 11y ago

> 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-over-http-please/ https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-...

mrfusion 11y ago
So how do you avoid this?
- iancarroll 11y ago
  Force TLS on all pages and subdomains, send the Strict Transport Security header, and preload your site (https://hstspreload.appspot.com/ https://hstspreload.appspot.com/).
- deleted 11y ago
  [deleted]
heinrich5991 11y ago
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.
- ams6110 11y ago
  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.
  - eterm 11y ago
    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.
    - saurik 11y ago
      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.
    - Pharaoh2 11y ago
      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.
      - toomuchtodo 11y ago
        > 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.
      - paulddraper 11y ago
        "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).
    - ams6110 11y ago
      Yes but the "login" link, the "add to cart" link, etc. is all served over http so could be replaced by a MITM.
- drblast 11y ago
  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.
eterm 11y ago
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).
- joosters 11y ago
  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...
  - ajanuary 11y ago
    That's not the half of it - if you knew what that cookie contained…
    - qb45 11y ago
      Like... login and cleartext password, to lookup your profile on each request?
      - mgkimsal 11y ago
        $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. :/
        qb45 11y ago
        Sad reality of rising kids with the notion that security is about forms and passwords and not about hacking stuff.
  - madeofpalk 11y ago
    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....?
6d6b73 11y ago
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?
- hwdsl2 11y ago
  They could. But how would they show the users their desired contents after login?
  - notatoad 11y ago
    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
- kilburn 11y ago
  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 https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [2] https://hstspreload.appspot.com/ https://hstspreload.appspot.com/
pmarreck 11y ago
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?
- simonw 11y ago
  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.
nommm-nommm 11y ago
The Tunisia government actually did this. http://m.theregister.co.uk/2011/01/25/tunisia_facebook_password_slurping/ http://m.theregister.co.uk/2011/01/25/tunisia_facebook_passw...

by _jomo 11y ago

mrfusion 11y ago

So how do you avoid this?

iancarroll 11y ago
Force TLS on all pages and subdomains, send the Strict Transport Security header, and preload your site (https://hstspreload.appspot.com/ https://hstspreload.appspot.com/).
deleted 11y ago
[deleted]

heinrich5991 11y ago

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.

ams6110 11y ago
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.
- eterm 11y ago
  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.
  - saurik 11y ago
    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.
  - Pharaoh2 11y ago
    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.
    - toomuchtodo 11y ago
      > 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.
    - paulddraper 11y ago
      "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).
  - ams6110 11y ago
    Yes but the "login" link, the "add to cart" link, etc. is all served over http so could be replaced by a MITM.
drblast 11y ago
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.

eterm 11y ago

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).

joosters 11y ago
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...
- ajanuary 11y ago
  That's not the half of it - if you knew what that cookie contained…
  - qb45 11y ago
    Like... login and cleartext password, to lookup your profile on each request?
    - mgkimsal 11y ago
      $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. :/
      - qb45 11y ago
        Sad reality of rising kids with the notion that security is about forms and passwords and not about hacking stuff.
- madeofpalk 11y ago
  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....?

6d6b73 11y ago

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?

hwdsl2 11y ago
They could. But how would they show the users their desired contents after login?
- notatoad 11y ago
  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
kilburn 11y ago
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 https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [2] https://hstspreload.appspot.com/ https://hstspreload.appspot.com/

pmarreck 11y ago

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?

simonw 11y ago
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.

nommm-nommm 11y ago

The Tunisia government actually did this. http://m.theregister.co.uk/2011/01/25/tunisia_facebook_password_slurping/ http://m.theregister.co.uk/2011/01/25/tunisia_facebook_passw...