WebBrowser 和 PCI DSS

Question

如果销售点读卡器停止工作，卡处理供应商需要备用卡输入方法。处理器建议的方法是应用程序将WebBrowser control 托管到供应商自己的站点，在结账时输入信用卡信息，并观察 URL 的变化以了解交易何时完成并接收验证令牌。

这让我觉得这是一个潜在的 PCI 雷区：

• 按键将进入与销售点应用程序的其余部分相同的进程，并且 WebBrowser 还提供进程内 DOM 挂钩
• 我不确定这对于来自单独机器的 MitM 的 HTTPS 证书验证意味着什么
• 可能还有其他我不知道的事情同样重要。 （已弃用的协议和算法？）

可以肯定的是，独立的网络浏览器可能会遇到一些相同的问题，但至少它不是应用程序代码库的责任。我不希望 PCI 审核在代码库中出现与代码库无关的问题，因为它与支付条目共享代码库。

我是不是想多了，因为它只是在读卡器出现故障时使用的备用方法？处理此问题的标准方法是什么？

Answer 1

如果您正在接受审核，审核员会寻找以下基本信息：

1. 制造商多久更新一次嵌入式浏览器？它如何接收更新？它会接收/部署自动更新吗？或者，您是否必须在发现/修补关键安全漏洞时重新部署应用程序？您如何管理这些更新？如果更新是自动的，那么在它们投入生产后如何对它们进行 QA？如果您必须重新部署应用程序，您将如何将其推广给用户？您如何确定所有用户都从不安全版本更新到安全版本？他们多久被推一次？您是否有一套良好的流程来管理在更新如此频繁以至于您的用户永远不知道他们将要打开什么和更新如此罕见以至于您运行极易受攻击的软件之间？

2. 在实践中（尤其是在您接受泄露后审计的情况下），嵌入式浏览器是否已完全更新以防止已修补的安全威胁？

3. 嵌入式浏览器是否可以防御基于浏览器的威胁，例如下载驱动？您的防病毒解决方案是否仍然适用于嵌入式浏览器？你确定吗？你是如何测试的？

例如，如果您在浏览器中运行虚拟终端，您可能希望能够回答这些相同的问题，但仅限于常规浏览器。因此，使用嵌入式浏览器不会改变 PCI-DSS 的字母。但是，嵌入式浏览器的安全流程会有所不同。

对于 MITM 攻击之类的事情，我不完全确定我是否理解您的问题。嵌入式浏览器与 MITM 的常规浏览器一样容易受到攻击，尽管一些常规浏览器对中间人攻击具有更强的保护。例如，如果您的嵌入式浏览器是 Google Chrome 的更新版本，那么与您的嵌入式浏览器是十年来没有更新的 IE 6 版本相比，我会觉得安全得多。

要记住的重要一点是，如果您的持卡人数据环境 (CDE) 位于接收定期漏洞扫描的安全网络中（并且如果您有一个良好的书面流程来管理您如何执行漏洞扫描），那么您应该没问题在违反的情况下。但更重要的是，您需要记录流程以及如何遵循流程。

例如，假设您的流程是：

a.) 让团队中的专家每第二个星期五进行一次漏洞扫描。 b.) 聘请外部公司每季度进行一次全面的漏洞扫描。

您需要有以下记录：

a.) 谁是你的专家？她是怎么训练的？她有资格做漏洞扫描吗？如果她发现了一个漏洞，它是如何升级的？她在什么日期进行扫描？她有打印结果吗？她会用她的发现填写表格吗？你有所有的表格吗？我可以查看她在 2015 年 12 月 18 日执行的漏洞扫描的结果吗？

b.) 当您完成专业扫描后，由谁执行？您如何审查该公司是否合格？你如何审查做他们的人是否合格？如果他们发现漏洞会发生什么？如果他们发现您的内部专家没有发现的漏洞会怎样？我可以看看他们最近的报告吗？我可以看看三季度前的报告吗？