iFrame 托管支付
我正在尝试将我们所有各种 Web 应用程序的所有付款条目“合并”到单个“托管”付款条目 Web 应用程序下。为了尽可能“灵活”地使用我们的各种 Web 应用程序并且不影响安全性，我想我会创建一个标准的 web2.0 小部件，它将 iFrame 来自同一二级域上的 Web 应用程序的支付输入/处理屏幕，但不同的三级域名。
IE：这些“单独”的 Web 应用程序：
- https://www.company.com/gifts/store
- https://www.company.com/cars/store
- https://www.company.com/hotels/store
会将所有 iframe 置于“签出”点的“灯箱”隐喻内容中，来自 https:// payments.company.com/ payment-entry.php
[https:// payments.company.com ] 将位于完全不同的服务器上并受到PCI 合规性，因为它是唯一暴露于 CC 数据的 Web 应用程序。目标是消除尽可能多的看到 CC 数据的内部和外部应用程序。
如果我有通配符证书，是否有人看到此 iframe 相同第三级域解决方案存在任何安全或跨站点脚本问题？
I'm attempting to "consolidate" all payment entries for all our various web applications under a single "hosted" payment entry web application. To be as "flexible" as possible with our various web-applications and not compromising security, I thought I would create a standard web2.0 widget that will iFrame the payment entry/processing screen from a web-application on the same 2nd level domain, but different 3rd level domain.
IE: These "separate" web applications:
- https://www.company.com/gifts/store
- https://www.company.com/cars/store
- https://www.company.com/hotels/store
would all iframe at the point of "check-out" in a "lightbox" metaphor content from https://payments.company.com/payment-entry.php
The [https://payments.company.com] would be on a completely different server and be subjected to the PCI compliance because its the only web application exposed to CC data. The goal is to eliminate as many internal and external applications seeing CC data.
If I have a wildcard certificate, does anyone see any security or cross-site scripting issues with this iframe same 3rd level domain solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论