短文件名漏洞

短文件名漏洞，短文说白了就是漏洞Windows系统里那个老掉牙的“8.3命名规则”在背后捅刀子。你明明建了个MySecretPassword.docx，短文系统偏要偷偷给你生成一个MYSECR~1.DOC的漏洞短别名。这个别名不会显示在资源管理器里，短文但它在硬盘上是漏洞真实存在的。攻击者只要猜出这个短文件名，短文就能直接绕过你设的漏洞访问规则。

我见过最典型的短文案例是某企业的内部系统。管理员把备份文件命名为2024_Financial_Report_Internal_Do_Not_Share.xlsx，漏洞权限设得严严实实，短文只允许财务部三个人访问。漏洞结果呢？短文渗透测试人员用工具扫了一下目录，直接枚举出2024FI~1.XLS，漏洞然后尝试用短文件名拼接路径去下载——居然成功了。短文因为那个文件系统上，短文件名的继承权限和长文件名不完全一致，防火墙规则只匹配了完整路径。

这个漏洞的根源在于，Windows为了兼容老软件，从NTFS时代起就默默维护着一套短名映射。你以为删掉了短文件名？不，它还在。你禁用8.3生成？那只是对新创建的文件生效，历史遗留的文件名依然在磁盘上躺着。更麻烦的是，有些工具（比如压缩软件、备份程序）会自己调用短名API，你根本拦不住。

实际利用时，攻击者不需要知道完整文件名。只要知道目录路径，然后用通配符加短名特征去暴力枚举。比如*~1.*这种模式，几秒钟就能试出所有候选短名。配合IIS短文件名扫描器，一个站点的敏感文件清单就能被拼凑出来。最讽刺的是，很多安全设备只看HTTP请求里的长路径，短路径请求直接放行——因为规则里根本没有匹配项。

防御手段倒是简单粗暴。在系统盘执行fsutil behavior set disable8dot3 1，然后格式化所有非系统分区——注意，只是改注册表没用，必须重建文件系统才能清除已生成的短名。但现实里很多服务器不能随便格式化，那退而求其次，用访问控制列表把短名也纳入管控，或者直接在Web服务器层面对包含~的请求做拦截。不过说实话，这招治标不治本，因为短名生成机制还在后台跑着。

我遇到过最离谱的情况是，某开发人员把密码文件命名为pass~1.txt，他以为这样够隐蔽，结果短名恰好就是PASS~1.TXT——完全等同。你越是用特殊符号去“隐藏”，反而越容易撞上短名的固定生成规则。这种漏洞不需要什么高深技术，纯粹是历史包袱加设计疏忽。只要Windows还有哪怕一台机器保留着NTFS的兼容性开关，它就永远是一块能撬开系统的砖头。