PCI-DSS 扫描的漏洞报告
我们对我们的一个网站进行了 PCI 扫描，该扫描是由我们的一位客户传递给我们的。有许多类似如下的漏洞报告：
网络服务：80/443 应用程序 URL： http://www.oursite.com/signup.php 响应包含 SQL Server 错误。这表明 插入的危险字符 测试渗透了应用程序并且 到达 SQL 查询本身（即 该应用程序容易受到 SQL 注入）。
测试信息摘要： header: header X-Forwarded-For=%2527
我不确定他们是如何说他们在这里注入了代码？
他们提供了一个不同的 URL 的另一个例子，据称该 URL 具有相同的问题，其漏洞如下：
测试信息摘要：标题： 标头 X-Forwarded-For='
编辑
我查看了这个标头，它似乎只是由代理或负载均衡器设置（无论如何我们都不使用）。不管怎样，我自己欺骗了它，而且我们根本不存在漏洞，所以我不确定他们在强调什么。由于我们没有使用这个标头，所以我不确定假设的攻击点是什么？
我们所谓的漏洞的另一个例子是：
网络服务：80/443 应用程序 URL： http://www.oursite.com/products/product-na-here/ 370 测试成功嵌入 响应中的脚本，它将是 页面加载后执行 用户的浏览器。这意味着 应用程序容易受到 跨站点脚本。
总结测试 信息：
路径：路径 /产品/产品-na-这里/370 - > /产品/产品-na-这里/370，参数： 标头 >'">警报(957652)
再次，我不确定这里标记的是什么？
谢谢。
We have had a PCI scan on one of our websites passed on to us by one of our clients. There are a number of reports of vulnerabilities that look something like this:
Network service: 80/443 Application URL:
http://www.oursite.com/signup.php
The response contains SQL Server
errors. This suggests that the
hazardous characters inserted by the
test penetrated the application and
reached the SQL query itself (i.e.
that the application is vulnerable to
SQL Injection).Summary test information: header: header X-Forwarded-For=%2527
I'm not sure how they are saying they have injected code here?
another example they provide for a different URL with supposedly the same issue has this as the exploit:
Summary test information: header:
header X-Forwarded-For='
EDIT
I've had a look into this header and it seems its only set by Proxy's or Load Balancers (which we dont use anyway). Either way, i've spoofed it myself and there is no vulnerability at our end at all so i'm not sure what they are highlighting. Since we make no use of this header i'm not sure what the supposed point of attack would be anyway?
Another example we have of a so-called vulnerability is this:
Network service: 80/443 Application URL:
http://www.oursite.com/products/product-na-here/370
The test successfully embedded a
script in the response, and it will be
executed once the page is loaded in
the user's browser. This means the
application is vulnerable to
Cross-Site Scripting.Summary test
information:path: path
/products/product-na-here/370 ->
/products/product-na-here/370,parameter:
header >'">alert(957652)
Again, i'm not sure what is being flagged here at all?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
扫描是自动进行的，可能会产生误报。它是为了提醒您存在漏洞的可能性，您需要解释您如何不易受到攻击或关闭漏洞。 （假设您这样做是为了 PCI 合规性审核......如果不是，那么您只需尝试在内部证明/关闭它们。）
扫描基于 OWASP 前 10 个漏洞 (http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project）按照 PCI DSS 的规定。看看那里；有很多很好的例子和对漏洞的深入解释。
The scans are automated and can generate false positives. It is to alert you to possibilities of vulnerabilities, and you need to either explain how you aren't vulnerable or close the vulnerabilities. (Assuming you're doing this for PCI compliance audit....if not, then you just try to justify/close them internally.)
The scans are based on the OWASP top 10 vulnerabilities (http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) as mandated by PCI DSS. Take a look there; there are a lot of nice examples and really in-depth explanations of the vulnerabilities.
另一种选择是使用不提供完全自动化结果的 ASV。有一些优秀的 ASV 采用混合方法来实现安全结果。他们手动审查以确认或否认每个自动发现的漏洞，并提供手动测试来查找只有人类才能可靠地发现的东西，例如 SQL 注入、跨站点脚本和敏感信息泄漏等，始终提供所需攻击向量的清晰示例。
全面披露：我在一家 ASV 工作，该公司提供的服务与我所描述的类似。
Another option is to use an ASV that does not provide solely automated results. There are some good ASVs around that take a blended approach to security results. They manually vet to confirm or deny each and every automatically found vulnerability, as well as providing manual testing to find things that only a human reliably can, such as SQL injection, cross-site scripting and sensitive information leakage, amongst many others, always providing clear examples of the attack vectors required.
Full disclosure: I work for an ASV that provides a service similar to what i describe.
正如其他用户所提到的，大多数 PCI 扫描结果似乎都标记了误报或改变的做法。我曾经看到有人建议我们不要使用绑定，并且允许 FTP 访问是一个主要的安全漏洞。我建议你在你认为合适的地方质疑他们的发现。
As mentioned by other user most PCI scan results seem to flag either false positives or changing practices. I saw one once recommending that we didnt use bind and that allowing FTP access was a major security hole. I would suggest you challenge their findings where you see fit.