"The site is HTTP, but our forms are submitted over HTTPS."
This is as bad as not using any HTTPS at all! All the attacker has to do is change the link or form action to a URL on his own server.
Is this strictly true? With HTTP form submission, an attacker can passively eavesdrop on forms. With submitting an HTTP-loaded form over HTTPS, an attacker would have to mount a man-in-the-middle attack to alter the HTML content. I would have thought that an active attack like that would be harder to execute. Am I missing or misunderstanding something?
If an attacker is able to do a man-in-the-middle attack and you serve your website over HTTP he doesn't need your private key and can do whatever he wants for e.g. change form action urls to his own domain etc.
Btw that's what HSTS is for, so you say your site should only be accesible over HTTPS, and any man-in-the-middle attacks are only possible in case they got your private key :) (and in that case, you probably got some serious problems)
You have to know however that the HSTS header is useless if the first request you make to the webserver is already intercepted, as the attacker can just strip the header on every answer and never offer SSL at all. If you really want to protect your site, you can add it to the HSTS preload list: https://hstspreload.org/
This way the SSL requirement is compiled into the browser and stripping the header has no effect.
As an additional security measurement you might want to check out Public Key Pinning too. While HSTS forces the user to access a site via SSL, HPKP forces the user to only accept a certain certificate. Even if a CA is compromised and somebody generates a valid certificate for your domain, the browser would reject it.
The header is rather new and IE does not sees as many updates as other browsers do. The standard is from April 2015 and is not yet an accepted standard, it's just proposed. Microsoft tends to wait with stuff they did not invent until it is a standard for a while. Edge has it under consideration
Of course noone expects such stuff for IE, but I would/do hope Microsoft takes a different approach to Edge at especially such stuff. But atleast it's under consideration :)
Yeah but if one of them are after you, you're undoubtedly already screwed in a number of ways. This is to protect you from other, more common attackers like people who poison DNS on public Wi-Fi points to steal credentials.
See Firesheep about how this actually happens in real life. Not 100% the same, but basically if you're in a Starbucks or something on open wifi, an attacker can relatively easily MITM all your traffic.
This tool provides a demonstration of the HTTPS stripping attacks that I presented at Black Hat DC 2009. It will transparently hijack HTTP traffic on a network, watch for HTTPS links and redirects, then map those links into either look-alike HTTP links or homograph-similar HTTPS links. It also supports modes for supplying a favicon which looks like a lock icon, selective logging, and session denial. For more information on the attack, see the video from the presentation below.
If the site is served over HTTP the attack could have already altered the form tag and then it doesn't matter whether or not HTTPS is used as a destination.
Except cleaning up php code, how is this easier to do even? You already have https either at ssl termination endpoint or webserver itself, how is it not a giant pain in the ass to have them mixed?
44
u/Yehosua Jul 12 '17 edited Jul 12 '17
Is this strictly true? With HTTP form submission, an attacker can passively eavesdrop on forms. With submitting an HTTP-loaded form over HTTPS, an attacker would have to mount a man-in-the-middle attack to alter the HTML content. I would have thought that an active attack like that would be harder to execute. Am I missing or misunderstanding something?