3

This question already has an answer here:

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?

marked as duplicate by SilverlightFox, techraf, S.L. Barth, Matthew, Xander Aug 16 '16 at 16:35

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 4
    Yes, it is secure. As far as I remember, this was the easiest way to add Stripe payments to your website. If Stripe is doing it, you can assume that the technique is on the safe-side. – theabhinavdas Aug 16 '16 at 6:15
  • 1
    @0x23212f I was under the impression that Stripe was using tokenization and was sending the payment details directly, which is why they require the page hosting their embedded form also is secured by HTTPS? – Repox Aug 16 '16 at 6:25
  • 1
    That goes into another aspect altogether. The idea behind having HTTPS on your payment page would be to gain trust so you know who you are transmitting your sensitive data to. I agree using an iframe on a website makes it difficult for most people to verify this with developer tools etc, but since you did, and can confirm that the source of the iframe is HTTPS, it should be safe! – theabhinavdas Aug 16 '16 at 6:36
  • 2
    Check out bobince's answer: even if you verify the iframe is coming from HTTPS, there is nothing stopping the unsecured parent page from interfering with it with 'clickjacking' attacks, for example a keylogging overlay form.. i.e. since the outer page is plain HTTP, it is hard to be sure that script hasn't been introduced by a MITM to fool you. – SilverlightFox Aug 16 '16 at 7:17
  • 2
    @0x23212f, but here it is not about trusting the service. If your network is compromised, the main page is delivered via HTTP, so an attacker can change it so that it doesn't even load the HTTPS iframe. It would load an attacker controlled page/code/etc. So even if you trust the service, you are still not safe. Contrast this with if the main page were loaded with HTTPS. – mikeazo Aug 16 '16 at 15:13
15

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.

6

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.

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.