短文件名漏洞其實在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目錄重新部署，完成此步驟才能完全修復
*注：注冊表項說明見微軟官方文檔：