在 http 网页中使用 https iframe只能防止被动攻击者。

这不是一个好的解决方案，因为：

• 它不能防止主动攻击者（他们可以重写 iframe 的 url，请参阅 sslstrip）
• 浏览器无法显示 https 的挂锁（因为主页不安全）

安全处理数据的唯一方法是在整个网页上使用 HTTPS：

• 一切都被加密，即使是活跃的攻击者也无法读取或修改数据（包括链接）
• 用户从浏览器获得确认所有内容都已加密（使用挂锁）

请注意，使用 https 的页面是不够的：应该保护指向该页面的链接（想象一下，如果 http 主页显示 https 链接“捐赠”，攻击者可以重写它）。因此，要真正保护处理敏感数据的网站（请注意，根据欧洲法律，必须保护个人数据）整个网站都应该使用 HTTPS。

在整个网站上使用 HTTPS + HSTS 是保护必须保护一些数据的网站的最佳方法，即使它在几个网页中也是如此。

（抱歉，我知道它不回答 PCI 一致性问题，只回答安全问题。）

很难相信 $crmcompany 在非安全文档设置中真正符合 PCI 与那种“安全”iFrame。即使 $crmcompany 符合 PCI 标准（我会要求他们提供一份显示合规性的最新审计副本），您的非营利组织也不符合 PCI 标准，并且必须遵守，因为他们通过他们的网站（无论 iFrame 是什么）进行付款。由于付款似乎是通过非营利组织的网站进行的，因此它们需要符合 PCI 标准。此外，如果他们检索和存储与支付交易相关的任何 PII，他们还需要对 PCI 合规性负责，并且正如 @Tom 所提到的，他们需要根据欧盟隐私法保护 PII。

考虑您有一个不安全的站点http://charity.com，其中一个安全站点https://Securecharity.com嵌入在不安全站点的 iframe 中。

使用公共 wifi（由咖啡店中名为“FreeHub”的攻击者托管）并访问您的不安全站点的用户，该站点在 iframe 中加载了安全站点。此时，攻击者现在可以访问 b/w 用户和外部世界的数据流（MITM 攻击）。他可以以明文形式查看用户访问的所有数据（仅限 HTTP 站点）。

由于安全的 HTTPS 站点是在不安全的 HTTP 站点中构建的，因此有可能

1. 攻击者在 HTTP 站点中插入可以记录所有击键（Key Logger）的 java 脚本。
2. 攻击者还可以通过更改 inframe src（因为 iframe 嵌入在 HTTP 中）将用户重定向到其他钓鱼网站。

此外，由于托管站点在 HTTP 中，浏览器不会显示挂锁（这表明该站点是安全的）。了解 HTTPS/PCI 的受过教育的用户不会准备好输入他们的付款/卡详细信息，尽管您的网站提到“即使您在地址栏中看不到挂锁或 https，但捕获您的付款信息的页面部分[iFrame] 是安全的。” 因此，它减少了对您组织的捐赠。

由于它涉及用户支付细节，因此最好托管一个安全的 HTTPS 站点。