短文件名漏洞其实在13年时还是很令人耳熟能详的，不过随着所在公司的编码语言转型，目前使用ASP.NET的新项目基本上没有了，而更多的是对原来的采用ASP.NET语言开发的项目进行维护或打个补丁。
事出突然，12月的某个下午被项目组喊去帮个忙，第一感觉就是“是不是线上的项目被人黑了？”。于是乎就跑去看下具体的情况，项目组负责人见到我第一句话就是“某个项目被某国家单位进行线上项目巡检时发现了一个漏洞，但是不会修”。
往他所指的电脑上简单一看，映入眼帘的就是“存在短文件名漏洞，定级为高”。是的，就是这么一个漏洞搞得项目组大伙都紧张。
短文件名漏洞是很多没有做过安全测试的项目的痛，因为发生的概率还是很高的，这一点可以通过谷歌来证实。不管是现在的国产安全扫扫器还是国外的安全扫描器都是能轻易的扫出的，且安全危险定级都不低。
短文件名漏洞的产生原理是啥呢？这一块网上资料很多，我就不细讲，有兴趣可以查下维基，我这里着重地贴上一个图来简单地解释下：
首先我们来发现一些细节：
- 从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目录重新部署，完成此步骤才能完全修复
*注：注册表项说明见微软官方文档：