凌晨三点，根目某公司运维老张被电话吵醒。录漏客户网站白屏，根目数据库连不上，录漏服务器日志里躺着一行刺眼的根目记录——`/etc/shadow` 被读取了。这不是录漏什么高深攻击，攻击者只是根目利用了 Nginx 配置里一个不起眼的 alias 拼接错误，在 URL 后面加了 `../`，录漏就摸到了系统根目录。根目

根目录漏洞，录漏说白了就是根目路径穿越的终极形态。Web 应用本该把自己关在网站根目录的录漏“笼子”里，比如 `/var/www/html`。根目但代码写得糙，录漏没过滤 `../` 这种回溯符号，根目攻击者就能一层层往上爬，直到 `../../../../etc/passwd` 直接怼到系统根目录。爬上去能干嘛？读密码文件、翻配置、找密钥，运气好还能直接写文件，把 webshell 种到系统目录里。

我见过最离谱的一次，是某政府网站的文件上传功能。开发图省事，直接用用户提供的文件名拼路径，连个 basename 都没做。攻击者上传一个叫 `../../../../tmp/shell.php` 的文件，服务器居然照单全收，文件直接写到了临时目录。虽然没直接拿到 root，但配合一个低权限的 cron 任务，照样提权成功。整个渗透过程不到十分钟，防线脆得像张纸。

根目录漏洞的可怕之处在于它打破了信任边界。Web 层觉得系统层是铁壁，系统层觉得 Web 层够不着自己，结果一个参数没过滤，两层之间的墙就塌了。很多开发者潜意识里觉得“用户输入最多影响应用自身”，但路径穿越这玩意儿，能直接把这种幻觉打成筛子。

防护手段倒不复杂，无非是严格过滤 `../`、用 `realpath()` 校验最终路径、或者干脆用白名单限制可访问目录。但问题从来不是技术难度，而是意识缺位。我翻过不少漏洞报告，大部分根目录漏洞都出自那种“先跑起来再说”的项目，测试时没人想着往 URL 里塞几个点，上线后自然也没人复盘。

有个细节特别说明问题。某次安全测试，我在一个下载接口的参数里加了 `../../../../etc/passwd`，服务器直接返回了文件内容。当时负责对接的工程师一脸震惊：“这也能行？”他以为框架默认处理了所有路径问题。现实是，框架只保护它自己那层，你写的业务代码如果直接拼路径，框架根本管不着。

根目录漏洞不是那种需要 0day 或者复杂利用链的“高级货”，它更像一扇没上锁的后门。攻击者不需要多天才，只要会猜路径、会数 `../` 的数量，就能撞开。而修复它，往往只需要在代码里加一行校验——但就是这一行，很多系统到被攻破都没补上。

说到底，安全不是堆砌工具和流程，而是每个写路径的瞬间，多问一句：如果用户输入的是 `../../../../`，我会不会完蛋？多数时候，答案让人冒冷汗。