短文件名漏洞其實在13年時還是很令人耳熟能詳?shù)?#xff0c;不過隨著所在公司的編碼語言轉(zhuǎn)型，目前使用ASP.NET的新項目基本上沒有了，而更多的是對原來的采用ASP.NET語言開發(fā)的項目進(jìn)行維護(hù)或打個補(bǔ)丁。

事出突然，12月的某個下午被項目組喊去幫個忙，第一感覺就是“是不是線上的項目被人黑了？”。于是乎就跑去看下具體的情況，項目組負(fù)責(zé)人見到我第一句話就是“某個項目被某國家單位進(jìn)行線上項目巡檢時發(fā)現(xiàn)了一個漏洞，但是不會修”。

往他所指的電腦上簡單一看，映入眼簾的就是“存在短文件名漏洞，定級為高”。是的，就是這么一個漏洞搞得項目組大伙都緊張。

短文件名漏洞是很多沒有做過安全測試的項目的痛，因為發(fā)生的概率還是很高的，這一點可以通過谷歌來證實。不管是現(xiàn)在的國產(chǎn)安全掃掃器還是國外的安全掃描器都是能輕易的掃出的，且安全危險定級都不低。

短文件名漏洞的產(chǎn)生原理是啥呢？這一塊網(wǎng)上資料很多，我就不細(xì)講，有興趣可以查下維基，我這里著重地貼上一個圖來簡單地解釋下：

首先我們來發(fā)現(xiàn)一些細(xì)節(jié)：

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

Windows 2008 之后的利用場景更為苛刻

那么短文件名漏洞利用原理是啥，這里貼個內(nèi)容：

Windows 還以 8.3 格式生成與 MS-DOS 兼容的(短)文件名，以允許基于 MS-DOS 或 16 位 Windows的程序訪問這些文件。在cmd下輸入“dir /x”即可看到短文件名的效果。通配符”*” 和 “?”發(fā)送一個請求到IIS，當(dāng)IIS接收到一個文件路徑中包含”~”的請求時，它的反應(yīng)是不同的?；谶@個特點，可以根據(jù)HTTP的響應(yīng)區(qū)分一個可用或者不可用的文件。

為了去復(fù)現(xiàn)短文件名，我們一般不建議用手工，耗時又耗力，偉大的GITHUB上已經(jīng)有無數(shù)能人寫了腳本，這里我貼一個，若你有更好的，歡迎留言分享下：https://github.com/lijiejie/IIS_shortname_Scanner

要存在短文件名就會全部列出來，沒有就會提示沒有，簡單易用。

漏洞怎么修呢？

這里我首先列一下網(wǎng)上收集的全部修復(fù)手段：

禁止url中使用“~”或它的Unicode編碼；

關(guān)閉windows的8.3格式功能；

將.NET Farrmework升級至4.0

正好，本次的需求下，讓運維一個一個地試，一組一組地嘗試。結(jié)果“真理還是出于實踐”：

系統(tǒng)框架已為4.0版本，經(jīng)掃描漏洞依然存在；

禁止url中使用“~”或它的Unicode編碼，手段太復(fù)雜，基本上很少運維懂；

單純地關(guān)閉windows的8.3格式功能是沒有鳥用的

*注：我們的漏洞環(huán)境為Windows 2008 R2，程序使用的是ASP.NET 2.0。

我們最終的方案是(你們僅作參考哈，畢竟偶是不會對你負(fù)責(zé)的)：

修改注冊表項：(重啟服務(wù)器生效)

HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation

值為1；

執(zhí)行DOS命令， fsutil behavior set disable8dot3 1；

刪除現(xiàn)有的IIS目錄重新部署，完成此步驟才能完全修復(fù)

*注：注冊表項說明見微軟官方文檔：

總結(jié)

以上是生活随笔為你收集整理的短文件名漏洞如何修复_短文件名漏洞修复的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。