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.