24

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.

Community
  • 1
Dan Kohn
  • 343
  • 1
  • 2
  • 7
  • The first three reasons seem to be more than enough. I would actively recommend for people not to shop at that site. Users have been repeatedly trained to check for `https` in the URL bar to a known domain. While I could attempt to check there's no rogue keylogging JS and HTTPS is actually being used (every time - and the no keylogging check is not trivial with minified JS), I wouldn't expect most users to be able to do this. Also, how do I know that the HTTPS connection for `ninjastandingdesk.com` is supposed to be to `newrelic.com` and that isn't a MitM attack? – dr jimbob Jul 02 '13 at 19:20
  • Never, ever put an SSL protected page in an iframe of a non-SSL page. It's asking for trouble, you'll be slapping user confidence in the face, and last but not least it might have a bad influence on your security karma. Fun aside: just don't. – e-sushi Jul 03 '13 at 04:57
  • I know this is an old question, but FWIW the "Buy Now" link no longer demonstrates the http + https iframe situation described. – jacobq Jun 29 '18 at 19:52

2 Answers2

21

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.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 1
    Just to be clear, my site (which is the source of the embedded iFrame) is SSL-only. The issue is that we are providing third-party Javascript to (hopefully) thousands of other sites, and many of those may find it difficult to enable SSL. Separate from getting a certificate installed, those sites often hard code HTTP images in their CSS, and make other mistakes that cause mixed content warnings. – Dan Kohn Jul 02 '13 at 19:26
  • http://wordpress.org/plugins/wordpress-https/ is a great solution for easily adding SSL to Wordpress blogs (although you still have to fix non-protocol-independent URLs referenced in the CSS). But, there is currently no way to make Tumblr and other third-party blog sites secure. – Dan Kohn Jul 02 '13 at 19:32
  • See also: http://security.stackexchange.com/questions/31748/credit-card-forms-on-http-pages-a-mitm-risk which covers closely related issues. – mr.spuratic Jul 03 '13 at 09:06
  • 1
    Tom, this was a great answer. Sorry I can't mark them both as correct. – Dan Kohn Jul 05 '13 at 11:33
15

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.

bobince
  • 12,494
  • 1
  • 26
  • 42
  • 7
    http://example.com/https/, heh. (Along those lines, I wonder if http://evilsite.com/secure-checkout?secure=yes would ever fool anyone) – user253751 Aug 30 '15 at 11:19