如果销售点读卡器停止工作，卡处理供应商需要备份卡输入方法。处理器建议的方法是应用程序托管WebBrowser control到供应商自己的网站，在结帐时输入信用卡信息，并监视URL更改以了解交易何时完成并接收验证令牌。
这令我印象深刻是一个潜在的PCI雷区：
可以肯定的是，独立的Web浏览器可能会遇到一些相同的问题，但至少它不是应用程序代码库的责任。我不希望PCI审计在代码库中遇到与其无关的问题，因为它与支付条目共享代码库。
我是否过度思考，因为如果读卡器关闭，它只是一种备用方法？处理此问题的标准方法是什么？
答案 0 :(得分：1)
如果您接受审计，审计员会寻找以下基本事项：
制造商更新嵌入式浏览器的频率如何？它是如何接收更新的？它会接收/部署自动更新吗？或者，每当发现/修补严重的安全漏洞时，您是否必须重新部署应用程序？你如何管理这些更新？如果更新是自动的，那么在他们生产之后你如何对它们进行质量检查？如果您必须重新部署该应用程序，您将如何将其推广给用户？您如何确定所有用户从不安全版本更新到安全版本？他们多久被推？您是否有一套良好的流程可以在频繁更新之间进行管理，以至于您的用户永远不知道他们打开和更新的内容很少会导致您运行极易受攻击的软件？
在实践中（特别是如果您需要进行违规后审核），嵌入式浏览器是否已完全更新以防止修补安全威胁？
嵌入式浏览器是否可以防止基于浏览器的威胁（如下载驱动器）？您的防病毒解决方案是否仍适用于嵌入式浏览器？你确定吗？你是如何测试的？
如果您是在浏览器中运行虚拟终端，那么您希望能够回答相同的问题，只关注常规浏览器。因此，使用嵌入式浏览器不会改变PCI-DSS的字母。但是，嵌入式浏览器的安全流程将有所不同。
对于像MITM攻击这样的事情，我并不完全确定我理解你的问题。嵌入式浏览器与MITM的常规浏览器一样容易受到攻击，尽管一些常规浏览器在中间攻击中具有更强的针对人的保护。例如，如果您的嵌入式浏览器是谷歌浏览器的更新版本，那么我觉得比您的嵌入式浏览器是IE 6的版本要安全得多，这个版本在未来十年没有看到更新
要记住的重要一点是，如果您的持卡人数据环境（CDE）位于接收常规漏洞扫描的安全网络内（如果您有一个良好的书面流程来管理您如何执行漏洞扫描），那么您应该没问题如果发生违规行为。但问题是，您需要记录流程以及您如何遵循流程。
例如，假设您的流程是：
a。）让您的团队专家每隔一个星期五进行漏洞扫描。 b。）聘请外部公司每季度进行一次完整的漏洞扫描。
您需要有以下记录：
a。）谁是你的专家？她是如何训练的？她有资格进行漏洞扫描吗？如果她发现漏洞，它是如何升级的？她执行扫描的日期是几号？她有结果的打印件吗？她是否用她的发现填写了一份表格？你有所有表格吗？我可以看到她在2015年12月18日进行的漏洞扫描的结果吗？
b。）完成专业扫描后，谁执行扫描？你如何审查公司是否合格？你怎么审查做他们的人是合格的？如果他们发现漏洞会发生什么？如果他们发现您的内部专家无法找到的漏洞，会发生什么？我能看到他们的上一份报告吗？我可以在四个季度前看到这份报告吗？