目录遍历攻击：当你的网站变成”裸奔”的文件夹
从一场数据泄露说起
上周有个消息在技术圈里炸开了锅——某知名电商网站因为一个不起眼的PHP代码漏洞，导致用户数据大规模泄露。数万名用户的手机号、邮箱、甚至部分订单信息被挂到黑市上贩卖。技术人员复盘后发现，罪魁祸首竟然是一个极其基础、甚至可以说”低级”的漏洞：目录遍历攻击。
很多人听到这个名词会觉得陌生，但它背后隐藏的逻辑其实很简单——就像你去图书馆借书，管理员告诉你”去三楼书架拿第7排的书”，结果你发现，管理员忘了锁门，你不但能拿到第7排的书，还能顺着走廊一路走到禁书区，甚至翻出地下室存放的机密档案。
这就是目录遍历攻击的本质：利用系统对路径输入的不当处理，突破预期目录的限制，访问本不应被访问的文件或目录。
这个漏洞是怎么被利用的？
让我用一个最真实的例子来说明。
假设你维护着一个图片分享网站，用户点击文章里的图片链接时，后台PHP代码是这样写的：
<?php
$imageName = $_GET['image'];
$imgPath = "/var/www/uploads/" . $imageName;
echo file_get_contents($imgPath);
?>
看起来挺正常的对吧？用户传一个图片名，代码拼接到固定路径后面读取文件。但如果用户传入的是这样的参数：
?image=../../../etc/passwd
最终拼接出来的路径就变成了：
/var/www/uploads/../../../etc/passwd
系统在执行这个路径时，会层层向上跳转，最终定位到 /etc/passwd——这是Linux系统里存放所有用户账户信息的文件。如果服务器配置不当，攻击者甚至能直接读取里面的内容，包括用户名、用户ID，甚至哈希后的密码。
这就是目录遍历攻击的核心手法：通过构造特殊的 ../ 序列，跳出预期目录，访问服务器上的任意文件。
为什么PHP特别容易中招？
PHP作为老牌服务器端脚本语言，在处理文件路径时有一系列”宽松”特性，这让目录遍历漏洞在PHP项目中尤为常见。
第一个问题：路径解析的宽容度
PHP的许多文件操作函数（如 include、file_get_contents、fopen）在处理路径时，并不会严格校验路径是否合法，而是直接将传入的字符串拼接到路径后面。这意味着攻击者可以随意注入 ../ 来改变文件读取方向。
第二个问题：include 的致命特性
比读取文件更危险的是动态包含：
<?php
$page = $_GET['page'];
include($page . ".php");
?>
这段代码原本的目的是根据用户传入的 page 参数加载不同的页面文件。但如果攻击者传入 ../../etc/shadow，最终执行的是：
include("../../etc/shadow.php");
如果服务器开启了PHP短标签或者配置允许，攻击者甚至可以包含远程文件（前提是 allow_url_include=On），实现远程代码执行，这比单纯的文件读取可怕得多。
第三个问题：Windows与Unix路径的差异
在Windows系统中，攻击者还可以利用 .. 配合其他路径字符进行绕过。比如：
?file=..\..\windows\system32\config\sam
不同操作系统对路径的处理方式不同，这让防御变得更加复杂。
这种漏洞能造成多大的危害？
一个看似不起眼的目录遍历漏洞，在特定条件下可以引发连锁反应，造成毁灭性的后果。
最直接的后果：敏感文件泄露
攻击者可以读取网站配置文件（如 config.php、.env），里面往往存放着数据库密码、API密钥、加密私钥等关键信息。一旦这些内容泄露，攻击者就能直接登录数据库，批量导出所有用户数据——这正是前面提到的那起电商网站泄露事件的典型案例。
更隐蔽的威胁：代码注入与远程执行
如果服务器上存在日志文件、临时文件或者可写的配置文件，攻击者可以通过目录遍历找到这些文件，注入恶意代码，然后在后续请求中触发执行。这种攻击方式被称为”文件包含攻击链”，在真实的安全事件中屡见不鲜。
企业层面的损失
数据泄露带来的后果不仅仅是技术层面的。监管罚款、用户信任崩塌、竞争对手的恶意利用，这些成本往往是企业难以承受的。某知名安全研究机构统计过，一次中等规模的数据泄露事件，企业平均需要花费200万美元以上用于应急响应和后续补救，而声誉损失更是难以量化。
如何从根源上修复这个漏洞？
修复目录遍历漏洞并不复杂，核心思路就一句话：永远不要信任用户输入的路径参数。以下是几种经过实战验证的防御方法。
方法一：路径白名单校验
最安全的方式是直接限制允许访问的文件范围：
<?php
$allowedImages = ['logo.png', 'banner.jpg', 'icon.svg'];
$imageName = $_GET['image'];
if (!in_array($imageName, $allowedImages)) {
http_response_code(403);
exit('非法请求');
}
$imgPath = "/var/www/uploads/" . $imageName;
echo file_get_contents($imgPath);
?>
这种方式从源头上杜绝了恶意路径的注入，是防御目录遍历最可靠的手段之一。
方法二：路径规范化后校验
如果允许的文件列表动态生成，可以使用 realpath() 函数将路径规范化，然后检查规范化后的路径是否在预期目录内：
<?php
$userInput = $_GET['file'];
$basePath = realpath('/var/www/uploads');
$requestedPath = realpath('/var/www/uploads/' . $userInput);
// 确保请求的路径在基目录内，且文件存在
if ($requestedPath === false || strpos($requestedPath, $basePath) !== 0) {
http_response_code(403);
exit('路径非法');
}
header('Content-Type: application/octet-stream');
readfile($requestedPath);
?>
这段代码通过 realpath() 解析了所有 ../ 序列，然后检查最终路径是否以 /var/www/uploads 开头。如果攻击者试图跳出该目录，strpos 校验就会失败，请求被拒绝。
方法三：过滤危险字符
虽然过滤不如白名单可靠，但在某些场景下仍然是必要的补充手段：
<?php
// 移除所有路径分隔符和危险序列
$safeName = str_replace(['..', '/', '\\'], '', $_GET['filename']);
// 进一步校验只包含合法字符（字母、数字、下划线、连字符）
if (!preg_match('/^[a-zA-Z0-9_-]+\.jpg$/', $safeName)) {
http_response_code(400);
exit('文件名不合法');
}
?>
这种正则表达式的方式可以阻止大部分简单的目录遍历尝试，但不建议作为唯一的防御措施。
方法四：服务器层面的配置加固
除了代码修复，Web服务器本身的配置同样重要。对于Nginx服务器，可以在配置中限制某些敏感路径的访问：
location ~* \.(env|ini|log|sh|sql|bak)$ {
deny all;
return 403;
}
location ~ /\.git {
deny all;
}
这段配置直接禁止了 .env、.git 目录等敏感路径的访问，即使应用代码存在漏洞，攻击者也难以利用这些路径获取敏感信息。
给开发者的几点实战建议
第一，代码审查不能只盯着新写的逻辑。
很多目录遍历漏洞藏在”看似无害”的旧代码里。一个多年前的文件下载功能，可能因为没有做好路径校验，成为整个网站的安全短板。定期审计历史代码，尤其是涉及文件操作的部分，是避免重蹈覆辙的关键。
第二，不要依赖”没人知道这个路径”的安全假设。
有些开发者认为，把敏感文件放在非公开目录、或者给目录设置不易猜测的名称，就能保护数据安全。这种想法在大数情况下是危险的——攻击者并不关心路径是否”隐蔽”，他们只会按照漏洞原理系统性地探测。安全应该建立在技术防御之上，而不是信息隐藏之上。
第三，开启服务器的错误抑制模式。
在生产环境中，务必关闭PHP的错误显示功能：
; php.ini 配置
display_errors = Off
log_errors = On
error_log = /var/log/php/errors.log
开启错误显示时，攻击者可以通过错误信息获取服务器路径、PHP版本等敏感信息，大大降低了利用漏洞的难度。
写在最后
那次电商网站的数据泄露事件，最终调查报告里有一句话让人印象很深：“如果当初只是多加一行路径校验，一切都不会发生。”
目录遍历攻击不是什么高深的黑客技术，它利用的是开发者在代码编写时最容易被忽视的细节——对输入数据的信任。在互联网安全领域，很多重大的安全事故，回溯到根源时，都是这种”小疏忽”造成的。
希望这篇文章能让正在阅读的你，下次在写文件路径相关的代码时，多问自己一句：“如果用户传了 ../，我的代码能正确处理吗？” 这个问题看似简单，却可能保护你的网站免于成为下一个数据泄露的典型案例。
毕竟，在网络安全的世界里，最好的防线永远是”多想一步”的习惯。