一台Windows Server 2012 R2，短洞修IIS 8.5，文件跑着一个内部管理系统。名漏某天安全扫描报告出来，短洞修高危项赫然写着：IIS短文件名泄露。文件我当时第一反应是名漏——这玩意儿不是2010年就爆过一轮了吗？怎么2024年了还在报。

短文件名机制本身是短洞修历史包袱。Windows为了兼容16位程序，文件给每个长文件名自动生成一个8.3格式的名漏短名。比如 WebApplicationConfig.xml 会对应一个类似 WEBAPP~1.XML 的短洞修东西。问题出在IIS处理含波浪号的文件请求时，会老老实实去匹配这个短名，名漏返回404和400的短洞修区别就能让攻击者逐字符猜出目录和文件名。

我实际测了一下。文件请求 http://target/abc~1 返回400，名漏说明不存在以abc开头且短名序号为1的文件或目录。换成 http://target/web~1，返回404，说明存在。继续猜后缀，web~1.a 返回400，web~1.c 返回404——web.config 就这么被确认了。整个过程不需要任何认证，纯靠HTTP状态码差异。

修复手段不止一种，但坑也不少

网上搜到的方案翻来覆去就那几条。改注册表 NtfsDisable8dot3NameCreation 设为2，这是最彻底的，但已经生成的短名不会自动消失。你得对每个目录跑 fsutil 8dot3name strip，而且这命令在系统盘上跑要格外小心，有些老软件真就依赖短名活着。

另一个方案是URL重写规则，拦掉带波浪号的请求。IIS 8以上可以用 requestFiltering 里的 denyUrlSequences 加一条 ~。简单粗暴，但会误伤——有些正常业务的URL里确实带波浪号，比如某些静态资源版本号。我就见过一个前端项目用 /~cache/ 做路径前缀，规则一加直接白屏。

微软官方其实给过一个补丁思路：在 web.config 里配置 requestFiltering 的 fileExtensions 允许列表，只放行实际用到的扩展名。这招比全局禁波浪号精准，但维护成本高，业务加个新文件类型就得改配置。

我最后怎么处理的

那台服务器上跑着三个站点，其中一个有老旧的ASP组件。我先在测试环境把注册表改成2，跑了一周没出问题，然后上生产。已经存在的短名用脚本批量strip，strip之前用 dir /x 导出完整列表存档，万一出事能对照排查。URL重写规则作为第二层防线，只拦 ~ 后面跟数字的模式，避免误伤。

扫描器复测通过。但说实话，这个漏洞的修复优先级我一直觉得被高估了。它本身不直接导致入侵，更像信息收集阶段的辅助手段。真正要命的是短名泄露之后跟其他漏洞的组合利用——知道了 web.config 的存在，再去猜备份文件、日志路径，攻击面就打开了。

还有一点容易被忽略：NtfsDisable8dot3NameCreation 改完之后，新建文件确实不再生成短名，但IIS的静态文件缓存和.NET的编译临时目录偶尔还会冒出波浪号路径。我遇到过一次，Temporary ASP.NET Files 目录下的编译产物带了短名，扫描器又报了。最后是把整个临时目录清掉重建才消停。

如果你也在处理这个漏洞，建议先别急着改注册表。拿扫描器报的路径实际验证一遍，确认是真泄露还是误报。有些扫描器只要看到404和400的差异就报，根本没验证后续字符。我见过一个案例，扫描器报了短名泄露，实际手动测的时候发现那个路径本身就不存在，纯粹是IIS返回码的随机波动导致的假阳性。