Is it safe to provide my details via an iframe, if the page in the iframe is secured with SSL? [duplicate]

Question

Visiting a streaming service I wanted to provide my payment details and was presented with a page that wasn't secured by HTTPS/SSL.

I didn't provide my details and contacted support asking them to fix this if they wanted my money.

The reply was that the payment details form was actually in an iframe and the source of the iframe is secured by HTTPS/SSL (and this I can verify).

But - is this secure? Can I feel safe with providing my payments details through an iframe, if the source of the iframe is HTTPS but the page displaying the iframe isn't?

Answer 1

It's a bad design and the entire page should use HTTPS, as this trains users to the unsafe practice of trusting and submitting private information over HTTP. It would be trivial for a man-in-the-middle attacker to alter the outer HTTP page to not use the correct HTTPS iframe, but instead an attacker controlled iframe (possibly HTTPS to an attacker controlled domain).

Thus you need to check the source code of the iframe every time you submit private data (as there are no guarantees that the first time you inspected it was fine, but the next time it was altered by an HTTP tamperer).

Furthermore, as the page is loaded over HTTP, a MITM attacker could insert and run whatever javascript they want on the outer page (and hide these modifications in some obfuscated script that's loaded externally). They could leave the original iframe with the right https URL if you clicked view-source of the HTML page, but in javascript they could hide or replace that iframe with malicious DOM elements that look identical (but leak your details to the attacker). This is less of a problem with an interactive DOM inspector in modern developer tools (which shows the DOM as it currently exists, so you should be able to inspect the iframe), but again this requires a lot of verification work for every user who wants to safely submit data.

Answer 2

Since the iframe is over HTTPS but the main web page is HTTP; this would be mixed content but browsers would only give a warning if HTTP content is embedded in an SSL protected page, not the other way around as it is in this case.

Its still an unsafe combination as the main page would be able to communicate with the iframe's contents via HTML postMessage API call. In this cross-domain scenario, this only works if the document in the iframe accepts and responds to these message based queries from the main page. See this example. Here is another example showing developers how to bypass this cross-domain security by embedding iframes of the main page within the iframe itself, so it's a hack which may not last for long as browsers get updated over time and fix these gaps.

The only issue I see here is that if any data is exchanged between the main HTTP page (unsecured) and the HTTPS secured payment page, then how sensitive is it and how well is it protected when crossing over to the unsecured HTTP domain.

But again, this kind of a concern is valid anywhere one web-app is passing user session/transaction to another web-app irrespective of whether iframes are involved or not. As end-users we don't know the type of communication going on behind the scenes between different service providers when completing a transaction. These are the kind of checks that PCI-DSS and others are supposed to validate.

I suggest you could trust them if both servers belonging to the HTTP and HTTPS pages belong to the same streaming service company.

Answer 3

No, it is not safe.

If the parent page is not secured with https then there is no guarantee that the user will see the correct https iframe url.

An attacker may perform a man-in-the-middle attack on the parent page and cause it to render an iframe to the attacker's website. Since browsers do not indicate the url or https status of iframes the user would be none the wiser they are communicating with someone fraudulent.