Credit card forms on HTTP pages a MITM risk?

Question

The other day, there was a web developer mailing list thread about a fundraiser page.

One person noted that the page with the credit card form was HTTP, not HTTPS.

In response, one person said that since the target of the form was HTTPS, it's not a problem

Nah, the form's submitted via https, served by Stripe. The site itself is http, though...

However, someone argued in response that that is not enough

You have not established that the form is secure. A MITM may modify the HTML in the response for http://example.com/ to replace the form's "action" attribute.

The website in question has since changed such that going to http://example.com takes you to https://example.com instead, so it's (hopefully) secure now, but I want to know for future reference.

Is a credit card form being on HTTP, but the target being HTTPS, a security risk for MITM attacks?

Answer 1

Yes, that last someone is correct, in addition to encryption (confidentiality) HTTPS gives you the assurances that the form is coming from where you think it is (authentication), and that it has not been interfered with in transit (integrity). Without HTTPS the form could be modified by a MITM as described.

It'sNot using HTTPS for this is simply bad practise (since the user is often the weakest link), when entering important data the user should just expect to see HTTPS (padlock/green bar/whatever) at every step, no exceptions.

Most browsers will warn by default if you POST from a HTTPS page to a non-HTTP URL, but they don't all clearly indicate that your data is being sent securely in the opposite case. Lack of HTTPS also means that site won't be using "secure" cookies.

See also: Is posting from HTTP to HTTPS a bad practice?

Properly addressing this issue requires HTTP STS (RFC6797), though a boot-strapping issue remains with first HTTP requests in most cases.

A similar issue is the practise of using an iframe to a HTTPS site within a HTTP page, e.g. 3rd party credit card service. In this case, though the form and the post are HTTPS, there's no assurance of integrity in the non-HTTPS content containing the iframe. The browser doesn't show the form is HTTPS (at least not in the normal way, if at all), so this also violates the expectations of a security conscious user.

Answer 2

A man in the middle could easily manipulate the post target, so it doesn't point to the secure HTTPS url anymore. The user cannot see whether the target is secure (without looking at the HTML code), so he just has to believe that the POST target is secure.

This scheme of an unsecure HTTP form calling a secure HTTPS url, is always vulnerable to SSL-strip.

Answer 3

While some of the answers are indeed helpful, they all have neglected mentioning a very important aspect, malicious code injection.

A MITM is able to modify the page served to you over HTTP, thus making him able to inject malicious Javscritpt that, for example, waits until you hover over the submit button and makes an Ajax POST to the attacker's server sending the form information. This is basically what the Tunisian government did to harvest Facebook credentials of dissidents.

So there are, as far as I know, two security problems for serving forms over HTTP (well, they're actually one, but can be exploited in two different ways):

1. The attacker changing the submission target (the action field)
2. The attacker injecting Javascript code that sends the form data to a 3rd party.

Answer 4

Ok, to be clear, you should NOT do this as a site developer, but if you need to work with a site that behaves this way, my answer is designed to say what CAN be done safely. Basically you can't trust anything on the page itself, all you can trust is that if the SSL cert resolves, then the post is talking to the legitimate server for the URL that it claims to be. You have to manually validate that it is sending to that URL and that it is the appropriate URL. This can only be done if the response is going to the same top level URL that served the page since you know you are trying to connect to that top level domain.

As long as the user was verifying that the post target was the intended server and that post connection was HTTPS and that there was no scripts that could alter the content present on the page and the browser doesn't send over an HTTPS link that doesn't have a valid cert for the URL being sent to, then the form would be perfectly secure. Note that you could only know the intended server if it is posting to the same TLD as the page is hosted from. You wouldn't, for example, know if www.bob.com telling you to submit the form to www.bobspayments.com was valid. It is also possible that if the same information submitted to two different services would do different things, then a malicious user might be able to make use of that. The problem is that a user won't do that. It does protect against passive sniffing, but won't provide verification to the user that the site is legit which SHOULD (but probably won't in many cases) raise concern by the user.

An active MITM attacker could simply change the page to return the information to them, but then again, this could be done even if the page itself was HTTPS since many users wouldn't notice if it was actually an HTTP page that was returned, so I'm not sure if there is really a significantly larger threat from an active MITM either since in either case.

The real problem would be the user experience and the fact that it shows up to the user as the page not being secured, so HTTPS is still preferable for the entire page for that reason. To clarify, there is a lot that can go wrong if the page contents are not authentic, so proving authenticity is preferable, but as long as information is actually submitted over SSL, then it will be protected. The problem is guaranteeing that it will be without manually reviewing page code.