How to securely send content from non-secure page to a secure URL?

Question

I have a JavaScript snippet that is aimed to be embedded into any webpage. This snippet loads a form into the page it's embedded in. The snippet then sends the form data to a secure URL. Here is the problem, the page where the snippet loads the form may not be secure, but I need the form data to be securely transferred to a secure external URL. How can I implement this if possible?

Jay Dansand · Answer 1 · 2013-02-07T19:49:29.553

4

If a form's ACTION attribute directs it to an HTTPS destination, then the content is encrypted and transmitted securely to the destination, regardless of how the form HTML itself was originally transmitted: when the user submits the form, the browser starts a new connection and issues a POST request (I'm assuming your form's METHOD is POST, not GET) against the destination, not the current browser location. In this case, that POST occurs over HTTPS because the destination is "https://...".

That says nothing about the inherent security risks of XSS or whatnot that could be embedded on the insecure page, or MITM attacks against the form HTML while it is being transmitted over HTTP via your JavaScript... you'll have to decide if those considerations are worthwhile for your project. Perhaps your JavaScript can embed an IFRAME with the form in it (using HTTPS for the IFRAME's SRC) instead of the FORM itself; this is what Facebook and others do to prevent other scripts running on the insecure page from accessing the form and its data - the browser will block such attempts from other scripts based on its same-origin policy (every popular modern browser can be relied upon to do this), and the form is transmitted over HTTPS when the IFRAME requests it. This is the preferred way to deliver a form to an arbitrary site when its contents need to be secure and you cannot control where the form is embedded.

edited Feb 07 '13 at 19:49

answered Feb 07 '13 at 19:10

Jay Dansand

789
1
9
13

Even an iframe, if the outer page is over plain HTTP, presents [similar risks](http://stackoverflow.com/a/3183176/372643). – Bruno Feb 07 '13 at 22:31
If your JS and form are only transferred over HTTPS (and deny access to HTTP requests), you've done all you can. If a MITM intercepted the outer page over HTTP and rewrote your JS embed to drop an HTTP IFRAME, it won't load your form anyway. All they really can do is intercept your JS, kill it, and inject their own form from scratch. There's nothing you can do at that point - even if you didn't normally provide the form in any manner, they could rewrite the page and create a convincing knockoff and insert it anyway. If the URL is wrong or lock icon is missing, everyone clicks through anyway. – Jay Dansand Feb 07 '13 at 22:43
Indeed, if the outer page is in plain HTTP, you can't guarantee anything. – Bruno Feb 07 '13 at 22:46
Since most users ignore the lock icon (and SSL as an authentication mechanism is totally broken anyway), anyone can fake any page into looking like the legitimate login portal for any other page, even if you don't offer a login embedding function. So I think the best we can do is mitigate what we can and accept that there is no perfect solution, especially if they've already attained MITM or MITB access. 2-factor/out-of-band verification? European hackers broke that w/combined Android trojans, so it's still just mitigation, no real answer. – Jay Dansand Feb 07 '13 at 22:51

score 0 · Answer 2 · answered Feb 07 '13 at 19:38

It's the action URL that matters when you submit a form, so if your form uses an https:// URL, it will make the POST request to that URL whether the form itself is hosted on an http:// or https:// page.

However, you should also serve the form page via https://. See the first rule of the WASP TLS cheat sheet (this principle not only applies to login pages but to any similar form).

The problem is that, without serving the form's page via https:// on an address the user can see an verify, the user can't trust that a MITM attacker hasn't altered this form. For example, such an attacker could replace the action attribute transparently to redirect to another site, or inject some JavaScript that logs every key entered into that form, supposed to gather sensitive data.

score 0 · Answer 3 · answered Feb 07 '13 at 20:09

The JavaScript loaded on the HTTP page would be replaced by an attacker who is modifying your traffic. The modified JavaScript can simply post the data to the public somewhere. Thus it's not possible to securely transfer data from the HTTP page to an HTTPS page. Unless you have some other definition of "secure" that I'm missing?

How to securely send content from non-secure page to a secure URL?

3 Answers3