2017年，短洞某大型国企的文件官网被挂上了暗链。安全工程师排查时发现，名泄攻击者根本没费多大力气——他们只是露漏向IIS服务器发送了一串特殊的短文件名请求，就摸清了网站后台的短洞真实目录结构。这个漏洞，文件就是名泄IIS短文件名泄露。

IIS为了兼容DOS时代的露漏8.3命名规则，会自动为长文件名生成对应的短洞短文件名。比如"Important_Contract_2024.pdf"会被解析成"IMPORT~1.PDF"。文件问题在于，名泄IIS处理这些短文件名请求时，露漏响应时间会有细微差别。短洞攻击者利用这个时间差，文件就能像猜谜一样逐字符爆破出服务器上的名泄真实文件名。

实测过的人都知道，这招有多阴险。你不需要任何权限，只需要一个普通的HTTP请求。发送"*~1*"之类的通配符请求，观察服务器返回的404状态码差异，就能判断某个文件是否存在。更麻烦的是，这个漏洞影响所有启用短文件名功能的IIS版本，从6.0到10.0统统中招。

有次我帮朋友测试他的企业站，用脚本跑了不到五分钟，就扫出了"LOGIN~1.ASP"和"CONFI~1.INI"两个文件。后者直接暴露了数据库连接字符串的备份路径。朋友当场脸色就白了——那个备份文件就放在web根目录下，文件名就叫"config_2023_backup.ini"。

修复方案其实不复杂。最彻底的办法是禁用短文件名功能：在cmd里运行"fsutil behavior set disable8dot3 1"，然后重启IIS。但要注意，这个操作会影响所有新建文件的短文件名生成，已经存在的短文件名不会自动消失，需要复制重建或使用工具清理。

另一个思路是调整URL过滤规则，拦截包含"~"符号的请求。在IIS的请求过滤模块里添加一条拒绝规则，把"*~*"模式直接挡在门外。不过这个方案对老版本IIS不生效，它们没有请求过滤功能。

我见过最粗心的运维，把整个C盘都共享了，短文件名漏洞反而成了最不起眼的问题。但更多时候，这个漏洞是攻击链条的第一环——先通过短文件名探明后台地址，再用弱口令爆破进入管理后台，最后上传webshell。整个攻击过程行云流水，而最初的突破口，就是几个看似无害的"~"符号。

说句实话，这个漏洞在如今HTTPS普及、云WAF横行的时代，杀伤力已经大不如前。但很多遗留系统还在裸奔，尤其是那些跑在Windows Server 2008上的老古董。如果你还在维护这类系统，不妨现在就打开命令行，敲一句"dir /x"看看你的服务器上有没有生成短文件名。如果有，那你的系统就还暴露在阳光下。

(责任编辑：综合)