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

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

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

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

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

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

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

Windows 2008 之后的利用場(chǎng)景更為苛刻

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

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

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

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

漏洞怎么修呢？

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

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

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

將.NET Farrmework升級(jí)至4.0

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

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

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

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

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

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

修改注冊(cè)表項(xiàng)：(重啟服務(wù)器生效)

HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation

值為1；

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

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

*注：注冊(cè)表項(xiàng)說明見微軟官方文檔：

總結(jié)

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

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