IIS短文件名漏洞是短洞解个老古董，但直到今天，文件它依然像根刺一样扎在不少Windows服务器的名泄喉咙里。攻击者只需要向服务器发一个包含`~`符号的露漏畸形请求，就能探测出网站根目录下的决方文件或文件夹前六位字符。这玩意儿利用的短洞解是8.3短文件名的历史遗留机制——Windows为每个长文件名自动生成一个短别名，即便你在NTFS里关闭了索引，文件这个行为依然默认开启。名泄

拿个真实案例说话。露漏去年我帮一家电商公司做渗透测试，决方对方用的短洞解是IIS 8.5，部署在Windows Server 2012 R2上。文件我发送请求`/a*~1*/.aspx`，名泄服务器返回404，露漏但响应头里泄露了`X-Powered-By: ASP.NET`，决方再换几个前缀试，比如`/s*~1*/.aspx`，返回码变成400，直接暴露了根目录下存在以`s`开头的文件。整个过程不到三分钟，没用到任何扫描工具，纯手工。对方运维一脸懵，说他们装了防火墙和WAF，但这漏洞根本不走应用层，直接打在IIS的静态文件处理模块上。

修复方法其实不复杂，但有个坑必须先说清楚：网上很多教程让你在注册表里加`NtfsDisable8dot3NameCreation`，设成1，重启服务器——这确实能阻止新文件生成短名，但已经存在的文件依然保留短名。也就是说，你得先删除所有现有文件的短名，再改注册表，否则漏洞照旧。实操中我建议用命令行工具`fsutil`配合`dir /x`查看所有短名，写个批处理逐个清理，或者干脆把文件复制到新目录再删旧目录，强制系统重新创建不带短名的文件。

另一个常见误区是只改IIS配置。有人把`请求筛选`里的`URL序列`加上`~`字符拦截，觉得万事大吉。但攻击者可以改用Unicode编码绕过，比如`%7e`代表`~`，或者用`/;/`分号路径参数混淆。我实测过，IIS 7.5以上版本对`%7e`的解析有时不经过请求筛选，直接命中短名探测。所以真正靠谱的做法是双管齐下：先禁用短名生成，再在IIS的`URL重写`模块里加一条规则，把所有包含`~`或`%7e`的请求直接返回403。别依赖WAF规则，那些东西对编码变种基本是摆设。

还有个细节容易被忽略——备份文件。就算你禁了短名，如果服务器上存在`web.config`的备份文件，比如`web.config.bak`，攻击者依然能通过短名猜解出前六位`WEB~1.BAK`，然后直接下载。我见过不止一次，运维只关注了主文件，忘了清理同目录下的`.old`、`.temp`、`.txt`后缀备份。所以修复后，记得用`dir /x`扫一遍整个站点目录，把所有带`~`号的文件全部处理掉，要么删除，要么重命名成不含长文件名规则的形式。

最后提个醒，Windows Server 2022和IIS 10虽然默认关闭了短名生成，但如果你的系统是从旧版本升级上来的，注册表项可能被保留，漏洞依旧存在。别信“新系统默认安全”那套，拿到服务器第一件事就是跑一下`fsutil 8dot3name query`，看返回结果是`0`还是`1`。返回`0`意味着所有卷都启用了短名，赶紧改。返回`1`只代表系统卷禁用，其他数据卷还得单独查。安全这东西，永远别嫌麻烦，因为攻击者永远不会嫌麻烦。