通过 iframe 进行的信用卡支付表格是不是有缺点？ [关闭]

Posted 2023-02-22

【中文标题】通过 iframe 进行的信用卡支付表格是不是有缺点？ [关闭]

【英文标题】：Are there drawbacks to credit card payment forms via an iframe? [closed]通过 iframe 进行的信用卡支付表格是否有缺点？ [关闭]

【发布时间】：2012-10-17 20:11:01

【问题描述】：

我在许多小型企业电子商务网站中看到的一个共同特点是，当我单击“结帐”按钮时，我会离开网站并重定向到第三方支付网关（如 paypal、authorize.net）的 url等等...在我在这个第 3 方网站上付款后，我被重定向回小型企业电子商务网站。

我想为我的几个客户简化这个过程。我计划制作一个付款表格，其他人可以通过 iframe 将其嵌入到他们的网站中。付款表格将位于 SSL 后面。当我的付款表单接收到信息时，我会将其传递给像 paypal 这样的商家网关，并使用成功/失败响应重新加载 iframe。

这种 iframe 方法是否存在任何重大问题？我之所以问，是因为我不记得像 paypal 这样的支付网关为其支付页面提供 iframe 嵌入代码，尽管提供它似乎是一件微不足道的事情。如果他们可以向网站所有者提供结帐 url 以嵌入到他们的页面中，他们应该同样能够轻松地提供 iframe 嵌入代码。

【问题讨论】：

投票结束，因为这对 Stack Exchange 的安全部门来说更重要...

问题在于这是黑客用来拦截输入的详细信息并窃取它们的方法，因此没有人会信任您的网站。这就是为什么商家直接链接到支付处理器并重定向回来。

【参考方案1】：

HTTPS 连接安全性的一个基本方面是验证远程方的身份。与某人秘密交换数据是一回事，但您需要知道与谁。

从技术角度来看，服务器的身份是使用其证书来验证的：

它需要被信任，即客户端可以验证它是由它信任的机构颁发的 (RFC 3280/5280)。 它需要发给客户想要与之交谈的实体，即需要验证主机名（RFC 2818，第 3.1 节）。

但是，技术方面只是解决方案的一部分。用户需要能够看到浏览器正在尝试连接的站点。这是一个用户界面问题，只有用户可以检查浏览器正在尝试执行的操作，以及其 UI 显示的内容（期望大多数用户使用开发人员工具是不现实的）。

使用 iframe 会隐藏用户为该 iframe 实际连接到的站点的名称（地址栏中仅显示主页的地址）。这会阻止用户进行此验证。

此外，如果 HTTPS iframe 位于 HTTP 页面中，情况会更糟，在这种情况下，用户甚至根本无法检查是否使用了 HTTPS。

有嵌入 iframe 的不良示例，特别是 3-D Secure，因为 (a) 它建议使用 iframe，并且 (b) 即使不使用 iframe，该名称通常与用户的银行无关、商家网站或信用卡公司。

【参考方案2】：

一个潜在的问题（作为用户，我实际上遇到了）是托管页面可能不会使用 SSL，并且有一些“提示”，人们被告知要在有关成为精明互联网的文章中寻找购物者。由于用户谨慎，可能会在最后一刻失去销售。

跨域脚本也存在潜在问题。这是一个巨大的话题，即使您希望做到这一点也可能非常具有挑战性，但这并非不可能，因此存在滥用的可能性。