在 HTTP 站点内的 HTTPS iframe 中收集信用卡信息

信息安全 tls http 信用卡 支付
2021-08-15 06:32:17

slate.com 的付费会员计划通过纯 HTTP 在 HTTPS iframe 内收集信用卡信息。HTTPS 网址是https://my.slate.com/subscriptions/manage/信用卡表格截图

在一篇文章中,他们声称这是安全的:

提交信用卡数据后,它们会被发送给第三方支付提供商,并且 Slate 本身不会存储您的信用卡数据。您的信用卡数据始终通过 HTTPS 发送。我向您保证,在 Slate 输入您的信用卡信息是一件非常安全的事情,我希望您喜欢 Slate Plus。

但是,他们也通过普通的 HTTP 获取用户名/密码,所以我对此表示怀疑。 用户名和密码表单截图

有人可以告诉我是否可以按照他们描述的方式安全地获取信用卡信息?

4个回答

他们正在做的事情肯定比根本不做 https 要好。但是,他们的外部 http 页面更容易受到中间人等攻击,这可能导致“安全”iFrame 被替换或以其他方式受到损害。这种方法也使最终用户难以做出自己的决定 - 锁定图标很有帮助,浏览器正在努力教用户如何确定网站是否安全。

鉴于现在 https 的最低成本以及它提供的额外安全性,他们没有理由为此辩护 - 他们应该修复它并在任何地方使用 https。

警告,IANAQSA

更新:Slate 实际上不是 SAQ A - 他们没有使用 iframe,并且他们将卡片信息提交到例如https://profile.slate.com/widget/traditional_register.jsonp ...下面的内容仍然适用于精神。

有人可以告诉我是否可以按照他们描述的方式安全地获取信用卡信息?

对的,这是可能的。但是,有一些隐含的责任转移给您,以检查您的连接是否安全以及您访问的支付站点是否是合法的支付处理器。

也就是说,这种配置既可以接受(根据 PCI),又有点不可取(根据安全最佳实践)。

SAQ A 的解读(适用于通过 iframe 将所有卡处理外包给其处理器的商家)表明这是一种合法配置。请注意,它没有对包含服务提供商支付页面的支付页面 (iframe)的页面提出任何明确要求只有 SP 的页面来自 SP,并且SP符合 PCI DSS(这意味着加密):

SAQ A 资格要求

现在,话虽如此,但存在诸如MITM之类的问题,使得 Slate 缺乏外部加密是不可取的。许多组织都在努力克服这个难题,最终决定加密其站点上的所有内容比处理不安全感更可取。但在他们的组织到达那里之前,通常需要时间和投诉。因此,请随时对此进行投诉。

当您对整个站点进行加密时,您可以免受被动攻击(他们只读取流量而不修改它)以及主动攻击者(他们会主动尝试从您那里获取信息并绕过安全措施)。通过使用加密的 iframe,您仍然可以免受被动攻击者的侵害,因为支付数据在传输过程中是加密的。然而,由于原始页面是未加密的,一个活跃的攻击者(也就是中间的一个人)可以将安全 iframe 替换为指向他们自己网站的 iframe,他们可以使该 iframe 看起来与应该存在的那个相同,或者只是强制 iframe 通过不安全的连接加载和提交(前提是它没有使用 HSTS 来强制您通过 HTTPS 加载它)。然后,他们能够捕获您输入的所有内容,包括您的付款详细信息。此外,没有浏览器通知通知您输入的内容被拦截,因为 iframe 没有协议或来源指示符。这意味着您检测此类攻击的唯一方法是检查表单上的元素,几乎没有人会这样做。

使用 HTTPS iframe 总比没有好,但说它是安全的是错误的。就个人而言,我永远不会在 URL 栏中没有 https 的页面上输入付款详细信息,但是在受信任的连接(也称为非公共 wifi)上时,风险非常小。

由于 slate.com 正在重定向到(仍然)slate.com,虽然它是从 http 到 https 的协议切换,但它并不意味着 slate.com 没有持卡人数据环境。是的,用户浏览器和 slate.com 之间的安全性有所提高(例如,假设 TLS 1.2),但仅此而已。