我最近发送了一份类似漏洞的报告，并得到了类似的回复。

事实证明，大多数浏览器和 CLI http 客户端都会从 URL 中删除路径遍历组件。

例如，如果在 Firefox 上键入 URL http://example.com/../../../etc/passwd，到达 example.com 的 GET 请求将如下所示：

GET /etc/passwd HTTP/1.1
[Ommitted headers]

与 wget 相同。

您应该尝试使用较低级别的工具，例如 telnet 或 netcat：

$ telnet example.com 80
GET /../../../etc/issue HTTP/1.1

HTTP/1.1 400 Bad Request
Content-Type: text/html
Content-Length: 349
Connection: close
Date: Wed, 07 Sep 2016 12:38:13 GMT
Server: ECSF (fll/078B)

再说一次，这可能是误报，您的审计员应该/etc/issue在报告中包含内容。这就是使用问题而不是密码的重点。

您至少应该与您的审核员跟进以确认它是否是误报。如果这是不可能的，安排一个新的渗透测试或使用像dotdotpwn这样的路径遍历模糊器执行你自己的测试

永远不要假设你是安全的，确保你是安全的。尤其是在这样的报告之后。

首先，没有人对其进行笔测试。他们运行扫描仪并将结果交给您。

渗透测试人员会确认该漏洞并解释如何重新创建它。

扫描程序可能错误地将您的主页作为对这些有效负载的响应这一事实标记为积极发现。

我也认为，像 Jesse 一样，双问号隐藏了真正的有效负载，因为我从未听说过??它是目录遍历有效负载的一部分，也找不到任何让我认为它是一个的东西。尝试替换..所有你看到的地方??

扫描仪将使用不遵循https://www.rfc-editor.org/rfc/rfc3986#section-5.2的浏览器版本， 这是用于删除/解决 URL 中这些点的规范。

如果扫描仪只将一个有效载荷标记为易受攻击而其他几十个没有，我会更担心，但看起来你得到了几十个不同有效载荷的结果，对吧？就像@Gnp 说的那样，向扫描仪索取证据（并询问该??有效载荷）。

这很可能是误报。

在您的问题中看到以下更新信息后

获取请求 -

app: 0|req: 1591/1591] 127.0.0.1 () {34 vars in 493 bytes} [Tue Sep  6 15:47:14 2016] GET /??/??/etc/passwd => generated 982 bytes in 5 msecs (HTTP/1.1 200) 2 headers in 80 bytes

很明显它是由一些自动扫描仪产生的。

然后是扫描仪如何确定其易受攻击的问题？

正如你提到的，

然后我尝试使用 curl，它也返回了主页。

自动扫描器只是假设，因为它得到HTTP/1.1 200（OK）作为服务器响应，它能够读取/etc/passwd服务器上的那个文件。愚蠢的自动扫描仪。

自动扫描程序希望该页面不会受到攻击，例如HTTP/1.1 404（未找到）或（URL 重定向）。HTTP/1.1 302