Specific risks of embedding an HTTPS iframe in an HTTP page

Question

I need help listing the specific risks of embedding an HTTPS iframe that enables credit card checkout inside of an HTTP page. Are there security issues with embedding an HTTPS iframe on an HTTP page? provides some high-level concerns, but I'm looking to be as specific as possible about potential attack vectors. Click on Buy Now for a good example of a secure iframe inside of an insecure page, being used today for credit card transactions. Here's what I have so far:

• Conversion will likely be lower because educated users will know not to enter their credit card number without seeing a green lock in the URL in the browser chrome. (Less knowledgable users may not know that they shouldn't trust a lock appearing inside the browser frame, as in the example above.)
• Even if users are comfortable with this approach, it's generally a bad idea to encourage users to enter their credit card number when they don't see an SSL lock confirmation in the URL bar. It is teaching users bad security habits. This post makes the point that SSL is about security more than just encryption and authentication.
• An active man in the middle could inject a rogue script into the parent page that could keystroke snoop. I believe this is what the Tunisian government did to steal dissidents Facebook credentials. (I believe the rogue script would be prevented from accessing the username and password from the secure iframe, but could still access keystrokes). Of course, a more determined government authority could subvert DNS and forge an SSL certificate as well, as the Iranian government apparently did, in which case a secure parent page wouldn't help.

I also have this list of unrealistic concerns:

• Another Javascript object on the unsecure parent page could snoop the contents of the secure iframe. I believe this is no longer possible as long as only browsers IE8 and above are supported.
• A rogue Javascript object on the parent page could do keystroke logging to capture a user's credit card number. This may be possible, but the risk is not affected by whether the parent page is served via SSL or not. A rogue script could keystroke snoop either way.
• The user can't see the URL the secure iframe is being served from. With either a secure or insecure parent page, you would need to be a technically-sophisticated user to view the iframe source URL.

Could you please tell me what other realistic and unrealistic vulnerabilities I'm missing? I have no doubt that the best option is always to embed a secure iframe into a secure parent page. What I'm trying to decide is the relative risks and benefits of enabling a secure iframe inside an insecure page versus the poor user experience of jumping users off of the insecure site where they see the product in order to complete a secure checkout elsewhere.

Answer 1

Click on Buy Now for a good example of a secure iframe inside of an insecure page, being used today for credit card transactions.

Aside from all the mentioned technical reasons this is a disastrously bad thing, this is explicitly against PCI-DSS requirements. See ‘Navigating DSS 2.0’ requirement 4.1:

When using SSL secured websites, ensure “https” is part of the URL

The linked interface is in breach of the PCI conditions that merchants sign up to as part of their agreement with their bank. ShopLocket appear to be providing/encouraging a blatantly non-PCI-compliant as well as deeply questionable approach to card processing.

Answer 2

An attacker who can embed a rogue script in the parent page can also simply change the URL for the iframe, redirecting it to an arbitrary location, at which point all kinds of phishing and man-in-the-middle setups are easy. No need to play DNS tricks at that level. That's the main problem with such an HTTPS iframe: you cannot easily know if you got the genuine thing (you have to fire up the browser debug mode to be really sure -- a cursory look at the page source is not ultimately sufficient because scripts loaded from the page can manipulate it at will at the DOM level, so what you seem to see in the source code is not necessarily what you get).

It really boils down to the lack of URL bar for the iframe. For an HTTPS site, the URL bar shows you that proper SSL is in place, with a valid server certificate, and it tells you the name of the server you are actually talking to. Remove the bar, and all kinds of nasty tricks become possible.

On the bright side, an HTTPS iframe, like a HTTPS target URL for a login form in an HTTP-page, is great against passive-only attackers (the kind of attackers who listens to all exchanged bytes but never injects anything on his own). It just happens that believing most attackers to be passive-only has become singularly naive nowadays.

---

As for user experience, the usual recommendation is simply to make the whole site HTTPS. It is much less expensive, from a computational point of view, than is usually believed. On a general basis, humans are not good at predicting performance issues. Performance is a matter of measurement, not guessing. I suggest that you try it out.

Also, as a user (albeit not necessarily a typical user), I kind of like the visible transition from HTTP to HTTPS. The checkout is about money, and, crucially, about my money. Thus, it is important.