直接访问`/etc/passwd`是目录最粗暴的验证方式，但多数时候你连路径都猜不中。遍历真正高效的漏洞验证，是验证从一个可控参数开始的。

假设目标站点的目录URL长这样：`http://example.com/download.php?file=report.pdf`。你手动把`report.pdf`改成`../../../../etc/passwd`，遍历浏览器返回了“File not found”。漏洞这不算失败——你要观察的验证是响应差异。如果返回的目录是空白页、报错信息带出绝对路径，遍历或者干脆弹出一个下载框，漏洞那就有戏。验证真正的目录死路是服务器把`../`直接过滤掉，或者拼接后路径不存在，遍历响应码变成404。漏洞

我习惯用Burp Suite的Repeater逐个测试编码变体。`../`被拦截？试试`....//`，有些中间件会把`../`剥掉一次，剩下的`../`恰好能构成穿越。再不行就URL编码：`%2e%2e%2f`，或者双编码`%252e%252e%252f`。有一次我碰上个Java应用，单编码全被拦，但双编码后的请求直接读到了`WEB-INF/web.xml`——那感觉就像开锁匠试了十把钥匙，第十一把突然转了。

别只盯着`/etc/passwd`。Linux下可以试`/proc/self/environ`，里面有时会泄露数据库密码或内网IP。Windows服务器就换思路，读`C:\Windows\win.ini`，或者`C:\boot.ini`（老系统）。响应里如果出现`[fonts]`或`[extensions]`这类节选，基本能确认存在漏洞。更隐蔽的验证方式是测错误信息：构造一个超长路径，让应用抛出堆栈跟踪，看打印的物理路径是`/var/www/html/`还是`D:\inetpub\wwwroot\`——这比直接读文件更安全，因为不会触发文件读取的日志告警。

自动化工具只能帮你缩小范围。比如用wfuzz跑字典，把`FUZZ`替换成`../../../../etc/passwd`，观察响应长度。但工具容易误报——有些站点对所有不存在的文件都返回200空页面，你得手动比对Content-Length。有个技巧：正常请求一个存在的文件，比如`report.pdf`，记录长度；再请求穿越路径，如果长度不同且内容包含`root:x:0:0:`，那才实锤。

验证完别急着写报告。顺手测下能不能读源码，比如`download.php`本身。如果能读出来，那漏洞影响直接升级——攻击者能审计代码找更多后门。我碰到过一个案例，文件下载漏洞配合源码泄露，最后翻出了后台的硬编码AES密钥。整个过程不过半小时，但危害远超单纯读几个系统文件。

最后提醒一句：别在未授权站点上试。这技术用于自己搭的靶机或者获得书面授权的渗透测试。真到了实战，记得用代理池换IP，别让目标WAF把你的扫描特征记进黑名单。验证完之后，把请求包和响应包完整保存下来，写报告时附上时间戳和工具版本，这比空口说“存在漏洞”有说服力得多。