我不知道该怎么做.我已将我的扫描公司指向同一个网址,但他们不接受这样做并回答.
我该怎么办？
更新
我没有使用此功能,并且在PHP.ini中禁用了open_basedir指令.但是,他们认为这不是一个合适的解决方案.
以下是他们否认我的争议的回应：
We have denied this dispute based on the information provided regarding how this finding has been addressed. The version of PHP that is currently running on this system has been found to not properly sanitize user-supplied input. Despite the fact that ‘open_basedir’ is disabled on this system,an attacker can exploit this issue and write wsdl files within the context of the affected application. Also,it has been found that other attacks are also possible. As a result,the ‘soap.wsdl_cache_dir’ directive sets the directory name where the SOAP extension will place the cache files. disabling ‘open_basedir’ has not 1) removed cache files that already exist and/or 2) ceased the possibility of new cache files from being placed into an arbitrary directory.
Please review 07001 for the deFinition of a compensating control. Among other things “Compensating controls must:…Be “above and beyond” other PCI DSS requirements (not simply in compliance with other PCI DSS requirements)”,and disabling ‘open_basedir’ does not really go above and beyond,the underlying issue should really be addressed here. Again,the requirements as listed within the scan report are to upgrade the system or utilize the compensating controls mentioned (which,disabling open_basedir would not be sufficient in this case).
Any issues detected on a system that is in scope for PCI DSS compliance would need to have all PCI non-compliant issues remediated (which is any system involved in the storage,processing,and/or transmission of credit card holder data and any system directly connected to a network involved in such processes which does not have proper network segmentation in place).
Please review the scan report and follow the suggestions found underneath the “Remediation” column and then perform another scan when the vulnerability has been remediated to clear the finding from your next scan report.
If the vulnerability continues to be detected after this point and/or if you have already performed this then please feel free to re-dispute this vulnerability and explain what was performed to address the finding.
编辑：似乎Debian和Red Hat有相同的政策,实际上 – “不支持”是不好的措辞,但所有这些发行版都认为本质上有缺陷的安全机制的缺陷不是问题.
07001
但是,这可能无关紧要.检查你的PHP.ini是否有open_basedir – 如果它不在那里,那么你完全不受这个安全问题的影响,因为这个bug是绕过open_basedir提供的安全限制.
但是,如果您的审核员对此特别不好,那么您最好的做法可能就是停止向他们展示您所使用的PHP版本 – 无论如何,版本字符串检查是进行漏洞评估的一种可怕方式.如果它是显示其版本字符串的Apache Web服务器,请将其命名为ServerSignature Off和ServerTokens Prod.
编辑他们发送给您的回复的注释…
The version of PHP that is currently running on this system has been found to not properly sanitize user-supplied input.
这个bug与清理输入没有任何关系,这是沙盒机制中的一个缺陷.
Despite the fact that ‘open_basedir’ is disabled on this system,an attacker can exploit this issue and write wsdl files within the context of the affected application.
我不是PHP内部的专家,但这似乎是对漏洞的严重误解.从我可以讲述的这个bug来看,问题是攻击者可以使用WSDL缓存机制从open_basedir根目录之外的目录位置加载WSDL(但可能仍然在soap.wsdl_cache_dir中,默认为/ tmp) .
对于这个问题,您必须拥有可以以这种方式实际定位的文件以及触发它被缓存的访问方法(可能是您的Web服务器中的目录遍历？)
无论如何,基于系统上已有的内容触发创建缓存的WSDL与将文件写入Web应用程序有很大不同.
As a result,the ‘soap.wsdl_cache_dir’ directive sets the directory name where the SOAP extension will place the cache files. disabling ‘open_basedir’ has not 1) removed cache files that already exist and/or 2) ceased the possibility of new cache files from being placed into an arbitrary directory.
虽然CVE确实说“任意目录”,但它看起来真正意味着“配置的WSDL缓存目录”.如果它包含目录遍历组件,则此漏洞会更严重.实际上,所有改变的都是添加验证以确保缓存目录在open_basedir中.见here.
disabling ‘open_basedir’ does not really go above and beyond,the underlying issue should really be addressed here
那是胡说八道.这是一个错误,WSDL缓存目录没有正确验证它是否在open_basedir中.如果您没有配置open_basedir,则整个漏洞完全无关紧要 – 没有进行任何其他更改以提供任何额外的安全性好处.
