Specific risks of embedding an HTTPS iframe in an HTTP page

  • 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.

    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?

    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.

    I know this is an old question, but FWIW the "Buy Now" link no longer demonstrates the http + https iframe situation described.

  • bobince

    bobince Correct answer

    8 years ago

    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.

    http://example.com/https/, heh. (Along those lines, I wonder if http://evilsite.com/secure-checkout?secure=yes would ever fool anyone)

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM