短文件名漏洞修复

短文件名漏洞其实在13年时还是很令人耳熟能详的，不过随着所在公司的编码语言转型，目前使用ASP.NET的新项目基本上没有了，而更多的是对原来的采用ASP.NET语言开发的项目进行维护或打个补丁。

首先我们来发现一些细节：

从Windows 2003到Windows 2008 R2系列都有存在短文件名漏洞的可能；

Windows 2008 之后的利用场景更为苛刻

那么短文件名漏洞利用原理是啥，这里贴个内容：

Windows 还以 8.3 格式生成与 MS-DOS 兼容的（短）文件名，以允许基于 MS-DOS 或 16 位 Windows的程序访问这些文件。在cmd下输入“dir /x”即可看到短文件名的效果。通配符”*” 和 “?”发送一个请求到IIS，当IIS接收到一个文件路径中包含”~”的请求时，它的反应是不同的。基于这个特点，可以根据HTTP的响应区分一个可用或者不可用的文件。

为了去复现短文件名，我们一般不建议用手工，耗时又耗力，伟大的GITHUB上已经有无数能人写了脚本，这里我贴一个，若你有更好的，欢迎留言分享下：https://github.com/lijiejie/IIS_shortname_Scanner

要存在短文件名就会全部列出来，没有就会提示没有，简单易用。

漏洞怎么修呢？

这里我首先列一下网上收集的全部修复手段：

禁止url中使用“~”或它的Unicode编码；

关闭windows的8.3格式功能；

将.NET Farrmework升级至4.0

正好，本次的需求下，让运维一个一个地试，一组一组地尝试。结果“真理还是出于实践”：

系统框架已为4.0版本，经扫描漏洞依然存在；

禁止url中使用“~”或它的Unicode编码，手段太复杂，基本上很少运维懂；

单纯地关闭windows的8.3格式功能是没有鸟用的

*注：我们的漏洞环境为Windows 2008 R2，程序使用的是ASP.NET 2.0。

我们最终的方案是（你们仅作参考哈，毕竟偶是不会对你负责的）：

修改注册表项：（重启服务器生效）
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation
值为1；

执行DOS命令， fsutil behavior set disable8dot3 1；

删除现有的IIS目录重新部署，完成此步骤才能完全修复