我正在为一个网站构建一个结帐页面,并有一个带有内容安全策略(CSP)的结帐页面。当客户用卡付款时,他们会看到一个带有银行页面的框弹出,允许银行进行验证(如果他们愿意的话)。
我的问题是弹出的框是iframe,我真的不想在CSP中允许所有的框架-src,我目前已经允许www.securesuite.co.uk,但我猜这不是德国或法国银行将使用的域?此外,我有一个MasterCard,但不是维萨或大师卡,我没有帐户,所有的大银行,他们都可能使用不同的供应商。据谷歌称,我的银行大都会使用类似于Www.security reliste.co.uk/metrobank/的东西,其他银行也做类似的事情。
最后,我的CSP报告页面将收集所有这些数据,但每一个都意味着每个失败帧源的事务失败。
所有银行都使用www.securesuite.co.uk吗?其他人是否有3D安全在不同银行和信用卡类型中使用的域名列表?我们的总部设在英国/欧洲,客户遍布欧洲,并将使用各种银行的信用卡。
发布于 2021-01-18 15:49:32
感谢这是一个更老的问题,但最近我遇到了同样的问题--管理一个“财富”杂志( fortune ) 50强的电子商务网站,我想我应该分享一下自己的想法。
不幸的是,新的3DS2实现是基于iframe的,与CSP并不完全兼容。世界上的大多数银行将为其iframe内容提供一个不同的域,并且绝对不可能确定和维护所有这些内容的完整列表。世界上所有的意志,不幸的是,你将失去销售。
最好的方法就是允许框架-src*出现在最后的结账页面上,如果可以的话,只允许使用那个页面。这似乎是一种松懈的方法,但当你意识到支付页面对你网站的安全至关重要时,你实际上就有机会从结账页面中删除一些不必要的主机,方法是为该页面提供一个“小”CSP。所以这不全是厄运和阴霾。唯一的其他选择是有一个单独的域为您的结帐,我看到了一些网站做的。尽管从这些不同域无缝切换会话状态将带来比它解决的更多的安全问题。
我也探索过很多其他选择..。比如使用一个新窗口/选项卡,或者对iframe URL完全重定向.但我们做了一些测试,并证实(对我们)成功的付款将有一个明显的下降。我怀疑任何企业都会感受到类似的打击。
在结帐页面上,CSP/browser-sec还有其他一些边缘情况问题。例如,一些银行的iframes试图打开一个URI,比如examplebank://open,希望把它交给一个移动/本地应用程序。如果CSP阻止了这一点,它有时也会影响任何回退逻辑。而其他银行,奇怪的是,提出了“x帧选项:拒绝”在iframe内容的标题,想要全页,永远不会正常工作。
根据银行的情况,3DS的到期日目前仍是一次又一次的失败,我会尽你所能做到最好,而不冒你的底线。
https://security.stackexchange.com/questions/235414
复制相似问题