[點(diǎn)晴永久免費(fèi)OA]文件上傳驗(yàn)證繞過技術(shù)總結(jié)
文件上傳漏洞可以說是日常滲透測(cè)試用得最多的一個(gè)漏洞,因?yàn)橛盟@得服務(wù)器權(quán)限最快最直接。但是想真正把這個(gè)漏洞利用好卻不那么容易,其中有很多技巧,也有很多需要掌握的知識(shí)。俗話說,知己知彼方能百戰(zhàn)不殆,因此想要研究怎么防護(hù)漏洞,就要了解怎么去利用。此篇文章主要分三部分:總結(jié)一些常見的上傳文件校驗(yàn)方式,以及繞過校驗(yàn)的各種姿勢(shì),最后對(duì)此漏洞提幾點(diǎn)防護(hù)建議。(根據(jù)個(gè)人經(jīng)驗(yàn)總結(jié),歡迎補(bǔ)充糾錯(cuò)~~) 文件上傳校驗(yàn)姿勢(shì)
1.客戶端校驗(yàn) 一般都是在網(wǎng)頁(yè)上寫一段javascript腳本,校驗(yàn)上傳文件的后綴名,有白名單形式也有黑名單形式。 2.服務(wù)端校驗(yàn)2.1 content-type字段校驗(yàn)這里以PHP代碼為例,模擬web服務(wù)器端的校驗(yàn)代碼 if($_FILES[''userfile''][''type''] != "image/gif") #這里對(duì)上傳的文件類型進(jìn)行判斷,如果不是image/gif類型便返回錯(cuò)誤。 { echo "Sorry, we only allow uploading GIF images"; exit; } $uploaddir = ''uploads/''; $uploadfile = $uploaddir . basename($_FILES[''userfile''][''name'']); if (move_uploaded_file($_FILES[''userfile''][''tmp_name''], $uploadfile)) { echo "File is valid, and was successfully uploaded.\n"; } else { echo "File uploading failed.\n"; } ?> 可以看到代碼對(duì)上傳文件的文件類型進(jìn)行了判斷,如果不是圖片類型,返回錯(cuò)誤。 2.2 文件頭校驗(yàn) 可以通過自己寫正則匹配,判斷文件頭內(nèi)容是否符合要求,這里舉幾個(gè)常見的文件頭對(duì)應(yīng)關(guān)系: 文件上傳繞過校驗(yàn)姿勢(shì)
1.客戶端繞過可以利用burp抓包改包,先上傳一個(gè)gif類型的木馬,然后通過burp將其改為asp/php/jsp后綴名即可。 2.服務(wù)端繞過2.1 文件類型繞過我們可以通過抓包,將content-type字段改為image/gif POST /upload.php HTTP/1.1 TE: deflate,gzip;q=0.3 Connection: TE, close Host: localhost User-Agent: libwww-perl/5.803 Content-Type: multipart/form-data; boundary=xYzZY Content-Length: 155 --xYzZY Content-Disposition: form-data; name="userfile"; filename="shell.php" Content-Type: image/gif (原為 Content-Type: text/plain) --xYzZY- 2.2 文件頭繞過 在木馬內(nèi)容基礎(chǔ)上再加了一些文件信息,有點(diǎn)像下面的結(jié)構(gòu) 2.3 文件后綴名繞過前提:黑名單校驗(yàn) 3.配合文件包含漏洞前提:校驗(yàn)規(guī)則只校驗(yàn)當(dāng)文件后綴名為asp/php/jsp的文件內(nèi)容是否為木馬。 #PHP #ASP #JSP or <%@include file="上傳的txt文件路徑"%> 4.配合服務(wù)器解析漏洞詳細(xì)可參考:http://thief.one/2016/09/21/服務(wù)器解析漏洞/ 5.配合操作系統(tǒng)文件命令規(guī)則(1)上傳不符合windows文件命名規(guī)則的文件名 6.CMS、編輯器漏洞(1)CMS漏洞:比如說JCMS等存在的漏洞,可以針對(duì)不同CMS存在的上傳漏洞進(jìn)行繞過。 7.配合其他規(guī)則(1)0x00截?cái)啵夯谝粋€(gè)組合邏輯漏洞造成的,通常存在于構(gòu)造上傳文件路徑的時(shí)候 name= getname(httprequest) //假如這時(shí)候獲取到的文件名是 help.asp.jpg(asp 后面為 0x00) type =gettype(name) //而在 gettype()函數(shù)里處理方式是從后往前掃描擴(kuò)展名,所以判斷為 jpg if(type == jpg) SaveFileToPath(UploadPath.name, name) //但在這里卻是以 0x00 作為文件名截?cái)?/p> //最后以 help.asp 存入路徑里 8.WAF繞過8.1 垃圾數(shù)據(jù)有些主機(jī)WAF軟件為了不影響web服務(wù)器的性能,會(huì)對(duì)校驗(yàn)的用戶數(shù)據(jù)設(shè)置大小上限,比如1M。此種情況可以構(gòu)造一個(gè)大文件,前面1M的內(nèi)容為垃圾內(nèi)容,后面才是真正的木馬內(nèi)容,便可以繞過WAF對(duì)文件內(nèi)容的校驗(yàn); 當(dāng)然也可以將垃圾數(shù)據(jù)放在數(shù)據(jù)包最開頭,這樣便可以繞過對(duì)文件名的校驗(yàn)。 可以將垃圾數(shù)據(jù)加上Content-Disposition參數(shù)后面,參數(shù)內(nèi)容過長(zhǎng),可能會(huì)導(dǎo)致waf檢測(cè)出錯(cuò)。 8.2 filename針對(duì)早期版本安全狗,可以多加一個(gè)filename 或者將filename換位置,在IIS6.0下如果我們換一種書寫方式,把filename放在其他地方: 8.3 POST/GET有些WAF的規(guī)則是:如果數(shù)據(jù)包為POST類型,則校驗(yàn)數(shù)據(jù)包內(nèi)容。 8.4 以上方式針對(duì)WAF,以上介紹的服務(wù)器解析漏洞、文件包含漏洞等都可以嘗試?yán)@過。 ————————————————2017.2.6更新————————————————– 8.5 利用waf本身缺陷刪除實(shí)體里面的Conten-Type字段第一種是刪除Content整行,第二種是刪除C后面的字符。刪除掉ontent-Type: image/jpeg只留下c,將.php加c后面即可,但是要注意額,雙引號(hào)要跟著c.php。 正常包:Content-Disposition: form-data; name="image"; filename="085733uykwusqcs8vw8wky.png"Content-Type: image/png 構(gòu)造包:Content-Disposition: form-data; name="image"; filename="085733uykwusqcs8vw8wky.png C.php" 刪除Content-Disposition字段里的空格增加一個(gè)空格導(dǎo)致安全狗被繞過案列: 修改Content-Disposition字段值的大小寫Boundary邊界不一致每次文件上傳時(shí)的Boundary邊界都是一致的: Content-Type: multipart/form-data; boundary=---------------------------471****1141173****525****99 Content-Length: 253 -----------------------------471****1141173****525****99 Content-Disposition: form-data; name="file1"; filename="shell.asp" Content-Type: application/octet-stream <%eval request("a")%> -----------------------------471****1141173****525****99-- 但如果容器在處理的過程中并沒有嚴(yán)格要求一致的話可能會(huì)導(dǎo)致一個(gè)問題,兩段Boundary不一致使得waf認(rèn)為這段數(shù)據(jù)是無意義的,可是容器并沒有那么嚴(yán)謹(jǐn): 文件名處回車多個(gè)Content-Disposition在IIS的環(huán)境下,上傳文件時(shí)如果存在多個(gè)Content-Disposition的話,IIS會(huì)取第一個(gè)Content-Disposition中的值作為接收參數(shù),而如果waf只是取最后一個(gè)的話便會(huì)被繞過,Win2k8 + IIS7.0 + PHP 利用NTFS ADS特性ADS是NTFS磁盤格式的一個(gè)特性,用于NTFS交換數(shù)據(jù)流。在上傳文件時(shí),如果waf對(duì)請(qǐng)求正文的filename匹配不當(dāng)?shù)脑捒赡軙?huì)導(dǎo)致繞過。 其他情況補(bǔ)充文件重命名繞過如果web程序會(huì)將filename除了擴(kuò)展名的那段重命名的話,那么還可以構(gòu)造更多的點(diǎn)、符號(hào)等等。 特殊的長(zhǎng)文件名繞過文件名使用非字母數(shù)字,比如中文等最大程度的拉長(zhǎng),不行的話再結(jié)合一下其他的特性進(jìn)行測(cè)試: 反刪除將下圖file1改成了file4,這樣就不會(huì)把這個(gè)文件刪除了。(JCMS漏洞) 文件校驗(yàn)的幾點(diǎn)建議
以上幾點(diǎn),可以防御絕大多數(shù)上傳漏洞,但是需要跟服務(wù)器容器結(jié)合起來。如果解析漏洞依然存在,那么沒有絕對(duì)的安全。
文件上傳漏洞及解析漏洞總結(jié)
文件上傳漏洞是指用戶上傳了一個(gè)可執(zhí)行的腳本文件,并通過此腳本文件獲得了執(zhí)行服務(wù)器端命令的能力。這種攻擊方式是最為直接和有效的,“文件上傳”本身沒有問題,有問題的是文件上傳后,服務(wù)器怎么處理、解釋文件。如果服務(wù)器的處理邏輯做的不夠安全,則會(huì)導(dǎo)致嚴(yán)重的后果。 文件上傳后導(dǎo)致的常見安全問題一般有: 1)上傳文件是Web腳本語(yǔ)言,服務(wù)器的Web容器解釋并執(zhí)行了用戶上傳的腳本,導(dǎo)致代碼執(zhí)行。 2)上傳文件是Flash的策略文件crossdomain.xml,黑客用以控制Flash在該域下的行為(其他通過類似方式控制策略文件的情況類似); 3)上傳文件是病毒、木馬文件,黑客用以誘騙用戶或者管理員下載執(zhí)行。 4)上傳文件是釣魚圖片或?yàn)榘四_本的圖片,在某些版本的瀏覽器中會(huì)被作為腳本執(zhí)行,被用于釣魚和欺詐。 除此之外,還有一些不常見的利用方法,比如將上傳文件作為一個(gè)入口,溢出服務(wù)器的后臺(tái)處理程序,如圖片解析模塊;或者上傳一個(gè)合法的文本文件,其內(nèi)容包含了PHP腳本,再通過"本地文件包含漏洞(Local File Include)"執(zhí)行此腳本;等等。 要完成這個(gè)攻擊,要滿足以下幾個(gè)條件: 首先,上傳的文件能夠被Web容器解釋執(zhí)行。所以文件上傳后所在的目錄要是Web容器所覆蓋到的路徑。 其次,用戶能夠從Web上訪問這個(gè)文件。如果文件上傳了,但用戶無法通過Web訪問,或者無法得到Web容器解釋這個(gè)腳本,那么也不能稱之為漏洞。 最后,用戶上傳的文件若被安全檢查、格式化、圖片壓縮等功能改變了內(nèi)容,則也可能導(dǎo)致攻擊不成功。 一、從FCKEditor文件上傳漏洞談起 FCKEditor是一款非常流行的富文本編輯器,為了方便用戶,它帶有一個(gè)文件上傳功能,但是這個(gè)功能卻出過多次漏洞。 FCKEditor針對(duì)ASP/PHP/JSP等環(huán)境都有對(duì)應(yīng)的版本,以PHP為例,其文件上傳功能在: http://www.xxx.com/path/FCKEditor/editor/filemanager/browser/default/browser.html?,配合解析漏洞。 (一)IIS5.x-6.x解析漏洞 使用iis5.x-6.x版本的服務(wù)器,大多為windows server 2003,網(wǎng)站比較古老,開發(fā)語(yǔ)句一般為asp;該解析漏洞也只能解析asp文件,而不能解析aspx文件。 目錄解析(6.0) 形式:www.xxx.com/xx.asp/xx.jpg 原理: 服務(wù)器默認(rèn)會(huì)把.asp,.asp目錄下的文件都解析成asp文件。 文件解析 形式:www.xxx.com/xx.asp;.jpg 原理:服務(wù)器默認(rèn)不解析;號(hào)后面的內(nèi)容,因此xx.asp;.jpg便被解析成asp文件了。 解析文件類型 IIS6.0 默認(rèn)的可執(zhí)行文件除了asp還包含這三種 : /test.asa /test.cer /test.cdx (二)apache解析漏洞 漏洞原理 Apache 解析文件的規(guī)則是從右到左開始判斷解析,如果后綴名為不可識(shí)別文件解析,就再往左判斷。比如test.php.qwe.asd “.qwe”和”.asd” 這兩種后綴是apache不可識(shí)別解析,apache就會(huì)把wooyun.php.qwe.asd解析成php。 漏洞形式 www.xxxx.xxx.com/test.php.php123 其余配置問題導(dǎo)致漏洞 (1)如果在 Apache 的 conf 里有這樣一行配置 AddHandler php5-script .php 這時(shí)只要文件名里包含.php 即使文件名是 test2.php.jpg 也會(huì)以 php 來執(zhí)行。 (2)如果在 Apache 的 conf 里有這樣一行配置 AddType application/x-httpd-php .jpg 即使擴(kuò)展名是 jpg,一樣能以php 方式執(zhí)行。 修復(fù)方案 1.apache配置文件,禁止.php.這樣的文件執(zhí)行,配置文件里面加入 2.用偽靜態(tài)能解決這個(gè)問題,重寫類似.php.*這類文件,打開apache的httpd.conf找到LoadModule rewrite_module modules/mod_rewrite.so 把#號(hào)去掉,重啟apache,在網(wǎng)站根目錄下建立.htaccess文件 (三)nginx解析漏洞 漏洞原理 Nginx默認(rèn)是以CGI的方式支持PHP解析的,普遍的做法是在Nginx配置文件中通過正則匹配設(shè)置SCRIPT_FILENAME。當(dāng)訪問www.xx.com/phpinfo.jpg/1.php這個(gè)URL時(shí),$fastcgi_script_name會(huì)被設(shè)置為“phpinfo.jpg/1.php”,然后構(gòu)造成SCRIPT_FILENAME傳遞給PHP CGI,但是PHP為什么會(huì)接受這樣的參數(shù),并將phpinfo.jpg作為PHP文件解析呢?這就要說到fix_pathinfo這個(gè)選項(xiàng)了。 如果開啟了這個(gè)選項(xiàng),那么就會(huì)觸發(fā)在PHP中的如下邏輯: PHP會(huì)認(rèn)為SCRIPT_FILENAME是phpinfo.jpg,而1.php是PATH_INFO,所以就會(huì)將phpinfo.jpg作為PHP文件來解析了 漏洞形式 www.xxxx.com/UploadFiles/image/1.jpg/1.php www.xxxx.com/UploadFiles/image/1.jpg%00.php www.xxxx.com/UploadFiles/image/1.jpg/%20\0.php 另外一種手法:上傳一個(gè)名字為test.jpg,然后訪問test.jpg/.php,在這個(gè)目錄下就會(huì)生成一句話木馬shell.php。 (四)IIS7.5解析漏洞 IIS7.5的漏洞與nginx的類似,都是由于php配置文件中,開啟了cgi.fix_pathinfo,而這并不是nginx或者iis7.5本身的漏洞。 5.配合操作系統(tǒng)文件命令規(guī)則 (1)上傳不符合windows文件命名規(guī)則的文件名 test.asp. test.asp(空格) test.php:1.jpg test.php:: $DATA 會(huì)被windows系統(tǒng)自動(dòng)去掉不符合規(guī)則符號(hào)后面的內(nèi)容。 如圖訪問ip/Netsys/HtmlEdit/fckeditor/editor/filemanager/connectors/test.html
![]()
點(diǎn)擊Create Folder新建文件夾
![]()
用brup suite進(jìn)行改包,將%2F改為a.asp。
![]()
點(diǎn)擊Get Folders獲得文件夾。
![]()
上傳文件,我這里上傳了一句話圖片木馬,然后能看到上傳的路徑,訪問的是1.asp/FI201610191827336199.jpg,會(huì)被當(dāng)作asp執(zhí)行,用菜刀連接getshell。
![]()
二、繞過文件上傳檢查功能 一般都是通過文件名后綴檢查。但是在某些時(shí)候,攻擊者手動(dòng)修改了上傳過程中的POST包,在文件名后添加一個(gè)%00字節(jié)額,則可以截?cái)嗄承┖瘮?shù)對(duì)文件名的判斷。因?yàn)樵谠S多語(yǔ)言的函數(shù)中,比如在C、PHP等語(yǔ)言的常用字符串處理函數(shù)中,0x00被認(rèn)為是終止符。受此影響的環(huán)境有Web應(yīng)用和一些服務(wù)器。比如應(yīng)用原本只允許上傳JPG圖片,那么可以構(gòu)造文件名為xxx.php[\0].JPG,其中[\0]為十六進(jìn)制的0x00字符,.JPG繞過了應(yīng)用的上傳文件類型判斷;但對(duì)于服務(wù)器來說,此文件因?yàn)?x00字符截?cái)嗟年P(guān)系,最終卻變成了xxx.php。 1.客戶端校驗(yàn) 一般都是在網(wǎng)頁(yè)上寫一段javascript腳本,校驗(yàn)上傳文件的后綴名,有白名單形式也有黑名單形式。 判斷方式:在瀏覽加載文件,但還未點(diǎn)擊上傳按鈕時(shí)便彈出對(duì)話框,內(nèi)容如:只允許上傳.jpg/.jpeg/.png?www.2cto.com后綴名的文件,而此時(shí)并沒有發(fā)送數(shù)據(jù)包。
![]()
客戶端繞過 可以利用burp抓包改包,先上傳一個(gè)gif類型的木馬,然后通過burp將其改為asp/php/jsp后綴名即可。 2.服務(wù)端校驗(yàn) 2.1 content-type字段校驗(yàn)
![]()
文件類型繞過 我們可以通過抓包,將content-type字段改為image/gif 2.2 文件頭校驗(yàn) 可以通過自己寫正則匹配,判斷文件頭內(nèi)容是否符合要求,這里舉幾個(gè)常見的文件頭對(duì)應(yīng)關(guān)系: (1) .JPEG;.JPE;.JPG,”JPGGraphic File” (2) .gif,”GIF 89A” (3) .zip,”Zip Compressed” (4) .doc;.xls;.xlt;.ppt;.apr,”MS Compound Document v1 or Lotus Approach APRfile” 文件頭繞過 在木馬內(nèi)容基礎(chǔ)上再加了一些文件信息,有點(diǎn)像下面的結(jié)構(gòu) GIF89a 2.3 擴(kuò)展名驗(yàn)證 MIME驗(yàn)證 MIME(Multipurpose Internet Mail Extensions)多用途互聯(lián)網(wǎng)郵件擴(kuò)展類型。是設(shè)定某種擴(kuò)展名的文件用一種應(yīng)用程序來打開的方式類型,當(dāng)該擴(kuò)展名文件被訪問的時(shí)候,瀏覽器會(huì)自動(dòng)使用指定應(yīng)用程序來打開。多用于指定一些客戶端自定義的文件名,以及一些媒體文件打開方式。 它是一個(gè)互聯(lián)網(wǎng)標(biāo)準(zhǔn),擴(kuò)展了電子郵件標(biāo)準(zhǔn),使其能夠支持: 非ASCII字符文本;非文本格式附件(二進(jìn)制、聲音、圖像等);由多部分(multiple parts)組成的消息體;包含非ASCII字符的頭信息(Header information)。 這個(gè)標(biāo)準(zhǔn)被定義在RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049等RFC中。 MIME改善了由RFC 822轉(zhuǎn)變而來的RFC 2822,這些舊標(biāo)準(zhǔn)規(guī)定電子郵件標(biāo)準(zhǔn)并不允許在郵件消息中使用7位ASCII字符集以外的字符。正因如此,一些非英語(yǔ)字符消息和二進(jìn)制文件,圖像,聲音等非文字消息原本都不能在電子郵件中傳輸(MIME可以)。MIME規(guī)定了用于表示各種各樣的數(shù)據(jù)類型的符號(hào)化方法。 此外,在萬維網(wǎng)中使用的HTTP協(xié)議中也使用了MIME的框架,標(biāo)準(zhǔn)被擴(kuò)展為互聯(lián)網(wǎng)媒體類型。 MIME的作用 使客戶端軟件區(qū)分不同種類的數(shù)據(jù),例如web瀏覽器就是通過MIME類型來判斷文件是GIF圖片,還是可打印的PostScript文件。 Web服務(wù)器使用MIME來說明發(fā)送數(shù)據(jù)的種類,Web客戶端使用MIME來說明希望接收到的數(shù)據(jù)種類。 一個(gè)普通的文本郵件的信息包含一個(gè)頭部分(To: From: Subject: 等等)和一個(gè)體部分(Hello Mr.,等等)。在一個(gè)符合MIME的信息中,也包含一個(gè)信息頭并不奇怪,郵件的各個(gè)部分叫做MIME段,每段前也綴以一個(gè)特別的頭。MIME郵件只是基于RFC 822郵件的一個(gè)擴(kuò)展,然而它有著自己的RFC規(guī)范集。 頭字段:MIME頭根據(jù)在郵件包中的位置,大體上分為MIME信息頭和MIME段頭。(MIME信息頭指整個(gè)郵件的頭,而MIME段頭只每個(gè)MIME段的頭。) 常見MIME類型
![]()
mimntype判斷 一般先判斷內(nèi)容的前十個(gè)字節(jié),來判斷文件類型,然后再判斷后綴名。 文件擴(kuò)展名繞過 前提:黑名單校驗(yàn) 黑名單檢測(cè):一般有個(gè)專門的 blacklist 文件,里面會(huì)包含常見的危險(xiǎn)腳本文件。 繞過方法: (1)找黑名單擴(kuò)展名的漏網(wǎng)之魚 - 比如 asa 和 cer 之類 (2)可能存在大小寫繞過漏洞 - 比如 aSp 和 pHp 之類 能被解析的文件擴(kuò)展名列表: jsp jspx jspf asp asa cer aspx 三、配合文件包含漏洞 前提:校驗(yàn)規(guī)則只校驗(yàn)當(dāng)文件后綴名為asp/php/jsp的文件內(nèi)容是否為木馬。 繞過方式:(這里拿php為例,此漏洞主要存在于PHP中) (1)先上傳一個(gè)內(nèi)容為木馬的txt后綴文件,因?yàn)楹缶Y名的關(guān)系沒有檢驗(yàn)內(nèi)容; (2)然后再上傳一個(gè).php的文件,內(nèi)容為“上傳的txt文件路徑”);?> 此時(shí),這個(gè)php文件就會(huì)去引用txt文件的內(nèi)容,從而繞過校驗(yàn),下面列舉包含的語(yǔ)法: (2)linux下后綴名大小寫 在linux下,如果上傳php不被解析,可以試試上傳pHp后綴的文件名。
![]()
CMS、編輯器漏洞 (1)CMS漏洞:比如說JCMS等存在的漏洞,可以針對(duì)不同CMS存在的上傳漏洞進(jìn)行繞過。 (2)編輯器漏洞:比如FCK,ewebeditor等,可以針對(duì)編輯器的漏洞進(jìn)行繞過。 這兩方面的漏洞以后單獨(dú)成文匯總,這里點(diǎn)到為止。 配合其他規(guī)則 (1)0x00截?cái)啵夯谝粋€(gè)組合邏輯漏洞造成的,通常存在于構(gòu)造上傳文件路徑的時(shí)候 test.php(0x00).jpg test.php%00.jpg 路徑/upload/1.php(0x00),文件名1.jpg,結(jié)合/upload/1.php(0x00)/1.jpg 四、WAF繞過 1、 垃圾數(shù)據(jù) 有些主機(jī)WAF軟件為了不影響web服務(wù)器的性能,會(huì)對(duì)校驗(yàn)的用戶數(shù)據(jù)設(shè)置大小上限,比如1M。此種情況可以構(gòu)造一個(gè)大文件,前面1M的內(nèi)容為垃圾內(nèi)容,后面才是真正的木馬內(nèi)容,便可以繞過WAF對(duì)文件內(nèi)容的校驗(yàn)
![]()
當(dāng)然也可以將垃圾數(shù)據(jù)放在數(shù)據(jù)包最開頭,這樣便可以繞過對(duì)文件名的校驗(yàn)。 2、 filename 針對(duì)早期版本安全狗,可以多加一個(gè)filename
![]()
、3 POST/GET 有些WAF的規(guī)則是:如果數(shù)據(jù)包為POST類型,則校驗(yàn)數(shù)據(jù)包內(nèi)容。 此種情況可以上傳一個(gè)POST型的數(shù)據(jù)包,抓包將POST改為GET。 8.4 以上方式 針對(duì)WAF,以上介紹的服務(wù)器解析漏洞、文件包含漏洞等都可以嘗試?yán)@過。 五、設(shè)計(jì)安全的文件上傳功能 1、文件上傳的目錄設(shè)置為不可執(zhí)行 2、判斷文件類型:強(qiáng)烈推薦白名單方式。此外,對(duì)于圖片的處理,可以使用壓縮函數(shù)或者resize函數(shù),在處理圖片的同時(shí)破壞圖片中可能包含的HTML代碼。 3、使用隨機(jī)數(shù)改寫文件名和文件路徑:一個(gè)是上傳后無法訪問;再來就是像shell.php.rar.rar和crossdomain.xml這種文件,都將因?yàn)橹孛鵁o法攻擊。 4、單獨(dú)設(shè)置文件服務(wù)器的域名:由于瀏覽器同源策略的關(guān)系,一系列客戶端攻擊將失效,比如上傳crossdomain.xml、上傳包含Javascript的XSS利用等問題將得到解決。
多種文件上傳繞過手法相信大家都或多或少遇到過上傳的問題,本文講些小技巧,原理用文字?jǐn)⑹鰧?shí)在麻煩 目錄:JS驗(yàn)證實(shí)例 /大小寫/雙重后綴名/過濾繞過/特殊后綴名/文件流類型/文件重寫1.javascript驗(yàn)證突破查看源代碼 2.大小寫突破3.雙重后綴名突破在php后面加一個(gè)空格即可突破 4.過濾繞過
5.特殊后綴名
6.文件流類型
只檢測(cè)了MIME沒檢測(cè)后綴導(dǎo)致的上傳。 7.文件重寫我個(gè)人覺得最有意思的就是這個(gè)了,
代碼: 《FilesMatch "95zz.gif"》 SetHandler application/x-httpd-php 《/FilesMatch》 這里去訪問gif的路徑就能看到已經(jīng)解析了。 該文章在 2020/4/11 4:00:11 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |