我需要帮助列出在 HTTP 页面内嵌入支持信用卡结账的 HTTPS iframe 的特定风险。在 HTTP 页面上嵌入 HTTPS iframe 是否存在安全问题？提供了一些高级别的问题，但我希望尽可能具体地了解潜在的攻击媒介。单击立即购买以获取不安全页面内的安全 iframe 的一个很好的示例，该页面目前用于信用卡交易。这是我到目前为止所拥有的：

• 转化率可能会更低，因为受过教育的用户会知道在没有看到浏览器 chrome 的 URL 中出现绿色锁的情况下不要输入他们的信用卡号。（知识较少的用户可能不知道他们不应该相信出现在浏览器框架内的锁，如上例所示。）
• 即使用户对这种方法感到满意，当用户在 URL 栏中看不到 SSL 锁定确认时，鼓励用户输入他们的信用卡号通常也是一个坏主意。它正在教用户不良的安全习惯。这篇文章表明 SSL 不仅仅是加密和身份验证，而是关于安全性。
• 中间的一个活跃的人可以将一个流氓脚本注入到可以击键窥探的父页面中。我相信这就是突尼斯政府为窃取持不同政见者的 Facebook 凭据所做的事情。（我相信流氓脚本将被阻止从安全 iframe 访问用户名和密码，但仍然可以访问击键）。当然，更坚定的政府机构也可以颠覆 DNS 并伪造 SSL 证书，就像伊朗政府显然所做的那样，在这种情况下，安全的父页面将无济于事。

我也有这个不切实际的担忧清单：

• 不安全父页面上的另一个 Javascript 对象可以窥探安全 iframe 的内容。我相信只要只支持 IE8 及更高版本的浏览器，这将不再可能。
• 父页面上的恶意 Javascript 对象可以进行击键记录以捕获用户的信用卡号。这可能是可能的，但风险不受父页面是否通过 SSL 提供的影响。流氓脚本可以通过任何一种方式进行击键监听。
• 用户看不到提供安全 iframe 的 URL。对于安全或不安全的父页面，您需要成为技术娴熟的用户才能查看 iframe 源 URL。

您能否告诉我我还缺少哪些其他现实和不切实际的漏洞？我毫不怀疑最好的选择总是将安全的 iframe 嵌入到安全的父页面中。我要决定的是，在不安全的页面中启用安全 iframe 的相对风险和收益与将用户从他们看到产品的不安全站点跳出以在其他地方完成安全结帐的糟糕用户体验相比。