文件上傳漏洞攻擊與防護

前言

  從一年前開始學習web安全以來,一直都是在吸取零碎的知識,不斷地看書與一些前輩的文章,中間也通過一些實踐,學習相關的工具,可是卻沒真真正正地在腦中造成一套完整的體系。從不久前就想着要寫一些博客,趁着這個機會,便好好梳理一下所學的知識,只是這些文章所寫大部份內容也是搬運前輩的文章,鮮有本身所想所悟。php

  關於文件上傳漏洞,百度一下便有許多文章出來,在這裏我也稍稍作整理。html

 

0x00 文件上傳漏洞所需知足的條件web

  一是文件可上傳(感受這一句是廢話)。二是上傳文件路徑可知,若是路徑不可知就無法訪問,亦沒法配合諸如文件包含漏洞進行文件執行。三是上傳文件能夠被訪問。四是上傳文件能夠被執行,固然這一步也不是必需的,好比配合文件包含漏洞。shell

 

0x01 文件上傳中的可控點數據庫

  經過HTTP協議上傳文件的過程當中,將經過POST請求對文件內容進行傳輸,而在HTTP請求包中,有可能存在的用戶可控點有幾個,接下來將以DVWA程序爲示例:編程

  如下是DVWA程序中上傳攻擊的請求包c#

 1 POST /DVWA/vulnerabilities/upload/ HTTP/1.1
 2 Host: 127.0.0.1
 3 Content-Length: 5108  4 Cache-Control: max-age=0
 5 Origin: http://127.0.0.1
 6 Upgrade-Insecure-Requests: 1
 7 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36
 8 Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryJUcYpiAjyVAzt5yA
 9 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
10 Referer: http://127.0.0.1/DVWA/vulnerabilities/upload/
11 Accept-Encoding: gzip, deflate, br
12 Accept-Language: zh-CN,zh;q=0.8
13 Cookie: security=low; PHPSESSID=plp6nm81is9eotcvfo3td8thp4
14 Connection: close
15 
16 ------WebKitFormBoundaryJUcYpiAjyVAzt5yA
17 Content-Disposition: form-data; name="MAX_FILE_SIZE"
18 
19 100000
20 ------WebKitFormBoundaryJUcYpiAjyVAzt5yA
21 Content-Disposition: form-data; name="uploaded"; filename="timg.jpg"
22 Content-Type: image/jpeg 23 
24 ?? JFIF  H H ? C   25 
26     
27 
28 
29  "" $(4,$&1'-=-157:::#+?D?8C49:7? C
30 
31 
32 
33 
34 7%%77777777777777777777777777777777777777777777777777?  ? ?" ?              ? <     !1A"Qa?25Tqs慚#B伇%3R懥$b??                 ?                 ?   ? 騦O?昘?     無舧??X讃鞳氾簂O跁? QC +琸僅w?碑髭?遲    ???X?園gX讃鞳氾籛c]鐗>k捐F溵t€灡跓5遲齝]鐗>k捐['?:駛?|讅籲峸駒瑨浩賄*<讅觰峸駒璸??飣]鱇琸僅w?d諤OX鞳氾籛c]鐗>k捐k'?#]鐗>k鵑浩賄j|讅婿J??飣]鱉?摞S婊顔I=c_味w?X鞳氾?2浩賄j|讅?F賄j|讅兄J?? }]鱅
35 ?qC筷(v洟1OjU鼸4@VI^?pwk?枂箥-憚B薫!聞椄輐-?3樒?TS?ィ挩c兙+nH蚥34?溒0椓'ON苧籖?+€Od??虹?l晽VJ?Od鯧K 嬪?Σ釕瑏瑲刷汥Bg7N鉧~h?5勈骽歧??Ml-偐癯`嚥)桰?I$?妠R崇筷(TV)鞪蠟 ā怹p?臋藩F玗$A?餚,n[謕弟輊縨媩B
36 w瑘t叜m??H檌鉅?? "﹖r熪~h%闕蕘cs咁"綆Зtn得?镺╩<O#V?挒j陂r鬁?(28?涫 ?zoE旒W I胰"s躻qM核猋s轍踃?Um眯AW7T7T牞l噠J協}oG杵Zk?興*?k贓宦\nS
37 @罔S磑Jb々??k-m!Ζd鄈n鬾"n嵐粀頂I
38 8?jび+I笰嚹塽t? u惻M;篒d{嵥嵲Z?n檞k悋t?貗爲%薧??妠N崇筷(dV)鞪繛 ā~$呮)Y#t-7^烝X蕣H?n追_婒展郱?$匆礀Fn譡duY頇幐(H箰{味V36<位芠sY蘘⊿f|n稱??璓?FK勸?<q脜P^F丳鞟? ?d?隊:(郯鎁f)\旯?nX漣?*$t?槓炩爗A7貶軤Z鸀錇?? ("腬)┾闈?┹D頫? 
39 P><嵏挖縭︶z散特?  H? ?徟id宲7頭艈狁GN茊 2?Y癶K標;?蠺P狴鎡^.\p煡鎠澦虛﹔45胑難4:?>x母v畷?7冚{
40 埍_FW嵐蛖被jl紱?q粢毆F鎬炑@P胾o|b<e?舢8G厛?/ |V3濘?琶]徽?Xj?op謅魽Q禁?側們懜錆饢?Ym鮍N朔8?H,盿lR筷(0嵟漸W筮?慘?K⒛e?    #逾iOG;楠c?鏇鑳馴    Dwq遁羉bj膚G? 娪?<Mk..諞愱I軤)祍:€>褍蘭N忥s$F踢揁塽瞇 嬤m儡)軫lG{黼-5PP鄲0\l@??猼峽佧_f嫄?劙zz'-$|J儲帓?? 愣b?Y^pe谾?h|\Q紴雛?C{rTmoL?籎駐lm蝅???PuP摑緣M灖餧v夼M屇鋩??d摯#}応車帋HK3磦-蒣諺2zV?伝N儝梧?濬毖?w[1鏳E?觔6?~歳]t欈E鬦鐔J]閿Vsy栮
41 爬騈街@A泘狢東?寢鞖倭??蹭鑰"?D袟<工k瓛@^)?繛 庤蘐 3嵇?關 澁焙駢酪?朅#E厤愪蓽様VF咶鏽(笰>冋?蟻梎袥璿留緵1悒n薣刟懶al崙唨蹫騏?硬★杅]逯?姑(汳N蒯vX€癿瑒??佈?3&疰c媆玉
42 頕1戜gg?@蕪?錨k陘kz0'I踼H'焸紜崛?|糌?2?0s%臂??娪棲條_桻<oV姄H?;飯`|uQI1?x倥?┡?·閐依諏e遴y"宒s?p?捳p? 簴U梴仟轆<-V?c*~椬u賭OG隯肀%[儘)廌:9 ?    k汮鴊戾鱤腷竻F
43 ji?輲練? 脝bN姃z'M<靮妯粌橃妻逗-_a?尰;H繆筲1|9覥IQ408枑#???槙4??)s?@貄V~
44 e?u嗎c
45 ?鉺+c:灋藎?N嫆?O 櫬? λΛ緄澂? 揓[-J:熾?姛鎢= QB⒈Oi拯鼾Et`BO衁 W/拮?cng 絆? 姙92鶺F??t筤姑韉4La芽涽AkP蝮殉?麜?;存 ;E_oi蜙.w$e瞯ZE佌櫎<kc!軍歛狡毀X敉teθ"|Ls3Xh袙K浌袿滈縡昝A{怗+???呡虜|qd?8闕豯妳蝧A(#滈`/嗒j)櫥q銾雬e崅啟&=弓n?D碞sA
46 轎攂s褌懭;絣闤?0=窺瞲?0傋7此鱤閎妳攽榿飊彗`卩rW鈣 fO3籥筞掊煆A?/{?蹭裖PG}l摴4$Gv雮l蟀@騮??$蘌3??0踕F)?繛 ā?pu]懅睿貸渦?A>閼憓%滕 qfe燹芟舮?F鱑0啋{伈?"D\嬢敖伕鏆0cy衱?#癴?樘f遣-餈?禱惰豶E??T>8吵Kk⑩灡畞?5T挵A)MXE?石〃鏩蘾vm@; 7嵂麵3^琺m?獙"燢H寫`? i篙莮H"栁$8?|祦慸絹6nm?A娏僡s衷藭?釵p颺/嬹?堅=廳8蛋'Rz?Le@.x$蠔姶CR?貌??u庋?%古A醵贄泿+c襜逛[ˋ?酭SM#匾c#q穪Yh豌爹杲+琱8??郿菶籙賈P蔳?8胐汯釘澬帺`貟竨Q (    s璻嚚?3鮌簑涥=?I$€躎幋嵇?j壟-謺= QP7O?v攝qt?me
47 o致&lO硑?誾?-鑉匕誼4蝹V濺膕銀W?tq腎鏐禍冄醏;報?d_L屎帹J纚裭炵D忠?g`-餢焊烠\??幵w梔膽?嵯
48 欏ip悅7訒f魄8?式砇鰑.YF:B摚攲靘闍倪A ,?熼?7?    ?CT鴫?盳蔿[?詘+ 疋嫲T革V隆睬?犲籓"y 駫季:h捺?鬼鍉_韞孯本粶F郫H??榌[b? 9w蚞@粄@崏@}<s獼7a)Is.?€乁7膀|?韢??7[給 &偤\6?樜R
49 ??涪艑JX郲 9??綆瓓枬畉?<?|??rFGl北棟A濰??扞 I$?1MqJ蠟 è『#???阱p醕e覿m呌蓃(8罬KS%<蹵???蕩騖ギ稵脹xk?€S跳?崽/@?l?G+鈰巊R冇ⅹ檫Sv?]?ㄓr?{%??v)丟(t?坖-俁硒? N僨燽戶UL滹鑲<敵冗P肀氦?V壹蕉潬鋹n
50 
51 ?姮ET鉛D蜽?|ys婇鴟??&?歳?押?9幁qv桿8??[賧.iK奝鷝?"7cu伃?牁9僛;B<<Qt曺溋V3?{^(姪0?,O姞?乵
52 颾?I%KL苡6'J蟪.IWT?R蠽2紙溵兗滄`盧S4??oZ繻N吇奓F靛抎??勰琭!T曄瑟惠u┿m暪椹?b鈔込 ?q@譒扝I$?扝臡盳繛 è/{YK婝V崇筷*炇?)狣躧儧w$騆伮2偖JY矰lPK爗衵??籧uウ錦^S脫=礩鸏[闖溊1W欅罡?屬爈y5???姼t蹄QL撟?y??殙聼彞壓Y肞?G?*?倆+s? ?日酺U氓瑪?覑賄ME婤逩?懘?{M墜hめP菗??#A钁鯽?胡?3貶昦澇>:fZ盼:劾(?坈sa蘭轎漲歭B澩AWK鄡溮)扏扞$    $扏扞$b駒嵇?N+鞪蠟 āv@?偏涃t?m?€繹驚0磾?I?侚豯U?幦??€喑K?F?巑C乂尐格+藀犄A%舜裭0蘒???'H]適7蒩t1?hE鶢鄥拍dVU6&]偉裁闔¥樓軪宑2T?兗T圖??遰u篻?Rhm?巋#ItB?I$?扞I$?姏鈺= QB騃$S穭扐+禘?s?€c,:?II$?lQt祇侤AI$?&邯貺NJ摡庸$怶扟.?H億$?d7q!q狪 k慾I b?d扏埐d扏扞$?
53 ------WebKitFormBoundaryJUcYpiAjyVAzt5yA
54 Content-Disposition: form-data; name="Upload"
55 
56 Upload
57 ------WebKitFormBoundaryJUcYpiAjyVAzt5yA--

  其實對於整個HTTP請求包來講,全部內容都是用戶可控的,只是請求包中的幾個點有多是後臺服務器的檢測重點,在上面的請求內容中,加粗加大的紅色字體爲可能的後臺檢測重點,主要有幾處:windows

  1. Content-Length,即上傳內容大小安全

  2. MAX_FILE_SIZE,即上傳內容的最大長度服務器

  3. filename,即上傳文件名

  4. Content-Type,即上傳文件類型

  5. 請求包中的亂碼字段,便是所上傳文件的內容

  6. 有可能存在請求包中的可控點還有上傳路徑,只是上面的示例中沒有出現

 

0x02 後臺的檢測點

  依然是以DVWA的代碼爲示例,分別展現一下DVWA不一樣等級下的代碼(雖然DVWA被人拿來示例了好屢次,我仍是厚着臉皮也用一次,畢竟簡單易懂...)

  1. low級別的檢測

 1 <?php
 2 
 3 if( isset( $_POST[ 'Upload' ] ) ) {
 4     // Where are we going to be writing to?
 5     $target_path  = DVWA_WEB_PAGE_TO_ROOT . "hackable/uploads/";
 6     $target_path .= basename( $_FILES[ 'uploaded' ][ 'name' ] );
 7 
 8     // Can we move the file to the upload folder?
 9     if( !move_uploaded_file( $_FILES[ 'uploaded' ][ 'tmp_name' ], $target_path ) ) {
10         // No
11         $html .= '<pre>Your image was not uploaded.</pre>';
12     }
13     else {
14         // Yes!
15         $html .= "<pre>{$target_path} succesfully uploaded!</pre>";
16     }
17 }
18 
19 ?>

  low級別的代碼中,沒有進行任何的檢測,便將文件上傳到指定目錄下,完事了還要告訴你文件上傳到哪裏去了.......因而這裏隨便修改文件名爲可執行腳本,文件內容爲一句話木馬,基本就完事了。我想大概不會遇到這樣的源碼了吧.....

 

  2. medium級別的檢測

 1 <?php
 2 
 3 if( isset( $_POST[ 'Upload' ] ) ) {
 4     // Where are we going to be writing to?
 5     $target_path  = DVWA_WEB_PAGE_TO_ROOT . "hackable/uploads/";
 6     $target_path .= basename( $_FILES[ 'uploaded' ][ 'name' ] );
 7 
 8     // File information
 9     $uploaded_name = $_FILES[ 'uploaded' ][ 'name' ];
10     $uploaded_type = $_FILES[ 'uploaded' ][ 'type' ];
11     $uploaded_size = $_FILES[ 'uploaded' ][ 'size' ];
12 
13     // Is it an image?
14     if( ( $uploaded_type == "image/jpeg" || $uploaded_type == "image/png" ) &&
15         ( $uploaded_size < 100000 ) ) {
16 
17         // Can we move the file to the upload folder?
18         if( !move_uploaded_file( $_FILES[ 'uploaded' ][ 'tmp_name' ], $target_path ) ) {
19             // No
20             $html .= '<pre>Your image was not uploaded.</pre>';
21         }
22         else {
23             // Yes!
24             $html .= "<pre>{$target_path} succesfully uploaded!</pre>";
25         }
26     }
27     else {
28         // Invalid file
29         $html .= '<pre>Your image was not uploaded. We can only accept JPEG or PNG images.</pre>';
30     }
31 }
32 
33 ?>

  medium級別中的源碼只檢測了文件類型與內容長度,也沒檢測文件名之類的,至於繞過方案,天然是上傳可執行腳本,文件名也是腳本擴展名,修改請求頭中的Content-Type,至於Content-Size,對於腳原本說通常都沒那麼大。我想我也不太可能會遇到這樣的源碼了吧....

 

  3. high級別的檢測

 1 <?php
 2 
 3 if( isset( $_POST[ 'Upload' ] ) ) {
 4     // Where are we going to be writing to?
 5     $target_path  = DVWA_WEB_PAGE_TO_ROOT . "hackable/uploads/";
 6     $target_path .= basename( $_FILES[ 'uploaded' ][ 'name' ] );
 7 
 8     // File information
 9     $uploaded_name = $_FILES[ 'uploaded' ][ 'name' ];
10     $uploaded_ext  = substr( $uploaded_name, strrpos( $uploaded_name, '.' ) + 1);
11     $uploaded_size = $_FILES[ 'uploaded' ][ 'size' ];
12     $uploaded_tmp  = $_FILES[ 'uploaded' ][ 'tmp_name' ];
13 
14     // Is it an image?
15     if( ( strtolower( $uploaded_ext ) == "jpg" || strtolower( $uploaded_ext ) == "jpeg" || strtolower( $uploaded_ext ) == "png" ) &&
16         ( $uploaded_size < 100000 ) &&
17         getimagesize( $uploaded_tmp ) ) {
18 
19         // Can we move the file to the upload folder?
20         if( !move_uploaded_file( $uploaded_tmp, $target_path ) ) {
21             // No
22             $html .= '<pre>Your image was not uploaded.</pre>';
23         }
24         else {
25             // Yes!
26             $html .= "<pre>{$target_path} succesfully uploaded!</pre>";
27         }
28     }
29     else {
30         // Invalid file
31         $html .= '<pre>Your image was not uploaded. We can only accept JPEG or PNG images.</pre>';
32     }
33 }
34 
35 ?>

  high級別的源碼中,分別有兩處檢測點,一是檢測了文件名後綴,二是檢測上傳內容是否爲圖像以及圖像大小,所用的函數爲getimagesize()。對於第二點,只須要在內容中增長文件頭標識,便可繞過。對於第一點,因爲其檢測了文件名後綴,那麼在上傳過程當中,就必需以jpg,png,jpeg結尾,這至關於以白名單的方法過濾掉了上傳文件擴展名爲可執行腳本後綴的可能,那麼對於這種檢測的繞過,以我目前的知識來講有兩種方法,一是結合文件包含漏洞進行shell代碼的執行,二是結合文件解析漏洞。而若是要結合文件解析漏洞的話,若是web容器是Apache,對於我來講我以爲沒有辦法,由於這些白名單後綴名都是Apache所認識的,最終去訪問文件的時候Apache也是以圖片的形式去解析,我能想到的就是結合文件包含漏洞了。而若是web容器是IIS,由於web腳本是php,那麼須要的IIS版本爲7.0/7.5,便可結合IIS7.0/7.5的解析漏洞去getshell。若是是Nginx亦是一樣的方法。

  從這個級別的源碼中開始看到對文件名進行過濾的狀況,而在後臺對文件名進行過濾的方法(我所知道的)有兩種,一種是黑名單過濾,一種是白名單過濾。這兩種方法中,黑名單過濾屬於很是不保險的過濾方法,針對該方法的繞過,亦由服務器操做系統的不一樣而不一樣,例如對於windows操做系統,因爲windows不區分大小寫,所以若將文件名後綴換成大寫,也許能夠繞過,或者是在文件名的最後加上.或者_,好比php.或者php_,因爲這類文件名在windows中是不容許的,因此在後臺上傳時windows會自動將.或者_去掉,結果文件就以可執行腳本的形式存在。而若是web容器是Apache,黑名單中若沒有.htaccess的限制,那麼能夠上傳.htaccess配置文件到目錄中覆蓋掉Apache的設置,可經過配置執行webshell。針對白名單的攻擊,能夠經過%00截斷,這個只能寄但願於代碼層的檢測邏輯出現問題,又或者是結合web容器的解析漏洞來getshell。

  4 impossible級別的檢測

 1 <?php
 2 
 3 if( isset( $_POST[ 'Upload' ] ) ) {
 4     // Check Anti-CSRF token
 5     checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' );
 6 
 7 
 8     // File information
 9     $uploaded_name = $_FILES[ 'uploaded' ][ 'name' ];
10     $uploaded_ext  = substr( $uploaded_name, strrpos( $uploaded_name, '.' ) + 1);
11     $uploaded_size = $_FILES[ 'uploaded' ][ 'size' ];
12     $uploaded_type = $_FILES[ 'uploaded' ][ 'type' ];
13     $uploaded_tmp  = $_FILES[ 'uploaded' ][ 'tmp_name' ];
14 
15     // Where are we going to be writing to?
16     $target_path   = DVWA_WEB_PAGE_TO_ROOT . 'hackable/uploads/';
17     //$target_file   = basename( $uploaded_name, '.' . $uploaded_ext ) . '-';
18     $target_file   =  md5( uniqid() . $uploaded_name ) . '.' . $uploaded_ext;
19     $temp_file     = ( ( ini_get( 'upload_tmp_dir' ) == '' ) ? ( sys_get_temp_dir() ) : ( ini_get( 'upload_tmp_dir' ) ) );
20     $temp_file    .= DIRECTORY_SEPARATOR . md5( uniqid() . $uploaded_name ) . '.' . $uploaded_ext;
21 
22     // Is it an image?
23     if( ( strtolower( $uploaded_ext ) == 'jpg' || strtolower( $uploaded_ext ) == 'jpeg' || strtolower( $uploaded_ext ) == 'png' ) &&
24         ( $uploaded_size < 100000 ) &&
25         ( $uploaded_type == 'image/jpeg' || $uploaded_type == 'image/png' ) &&
26         getimagesize( $uploaded_tmp ) ) {
27 
28         // Strip any metadata, by re-encoding image (Note, using php-Imagick is recommended over php-GD)
29         if( $uploaded_type == 'image/jpeg' ) {
30             $img = imagecreatefromjpeg( $uploaded_tmp );
31             imagejpeg( $img, $temp_file, 100);
32         }
33         else {
34             $img = imagecreatefrompng( $uploaded_tmp );
35             imagepng( $img, $temp_file, 9);
36         }
37         imagedestroy( $img );
38 
39         // Can we move the file to the web root from the temp folder?
40         if( rename( $temp_file, ( getcwd() . DIRECTORY_SEPARATOR . $target_path . $target_file ) ) ) {
41             // Yes!
42             $html .= "<pre><a href='${target_path}${target_file}'>${target_file}</a> succesfully uploaded!</pre>";
43         }
44         else {
45             // No
46             $html .= '<pre>Your image was not uploaded.</pre>';
47         }
48 
49         // Delete any temp files
50         if( file_exists( $temp_file ) )
51             unlink( $temp_file );
52     }
53     else {
54         // Invalid file
55         $html .= '<pre>Your image was not uploaded. We can only accept JPEG or PNG images.</pre>';
56     }
57 }
58 
59 // Generate Anti-CSRF token
60 generateSessionToken();
61 
62 ?>

  針對這個級別的檢測,我表示沒有辦法了,後臺代碼從28行開始就對文件內容進行了渲染,而對於這方面我也沒了解過,不知道被渲染以後shell代碼會變成什麼鬼,即便文件可被訪問可執行估計出來也是一堆亂碼。

 

0x03 Apache/IIS/Nginx 解析漏洞

  1 Apache解析漏洞

  關於Apache解析漏洞,主要是參考http://www.cnblogs.com/milantgh/p/5116955.html這篇文章,至於文中所說的以module方式與PHP結合纔會出現解析漏洞的結論我還沒有去驗證。Apache認爲一個文件能夠有多個擴展名,如文件名爲shell.php.xxx.aaa.ccc的文件,Apache認爲該文件從左到右具備這幾個擴展名,php、xxx、aaa、ccc,而對於必定擴展名的處理方式由httpd.conf文件決定。在處理上例的文件中,Apache分別從右到左取其擴展名,直到遇到配置文件中有設置的擴展名,便以該類文件處理。對於 上例,Apache先處理ccc,若是配置文件沒有ccc擴展名,接下來則處理aaa,若是配置文件沒有aaa擴展名,則再處理xxx,直到遇到php,Apache便將該文件以php的方式處理。所以,若遇到後臺是以黑名單過濾的狀況,經過解析漏洞便可上傳shell文件。對於這個漏洞,我在本身電腦上搭建DVWA,採用的Apache版本爲2.4.23,一樣會出現這個漏洞。

  2 IIS解析漏洞

  IIS6.0的解析漏洞有兩個。一爲目錄解析漏洞,若是目錄名中包含".asp"字符串,那麼對於該目錄下的全部文件都會以asp腳本執行,因此這一漏洞是針對IIS6.0/asp的狀況。二是對於文件名中後綴爲".asp;任意字符"的文件,在解析時將會忽略";"後面的任何字符,將文件以asp解析。

  另外針對IIS7.0/7.5的狀況,在對PHP解析時,對於任意文件名,只要在文件名後面追加字符串"/任意字符.php",那麼IIS將會將該文件當作PHP處理,而實際上該漏洞是與php-cgi有關。

  3 Nginx解析漏洞

  Nginx的解析漏洞也有兩個,對於任意文件名,可在其後面添加字符串"任意字符.php",這個漏洞與上面的IIS漏洞相同,另一個即是對於任意文件名,能夠在其後面添加%00.php,便可構成解析漏洞。

 

0x04 文件上傳的防護

  我的以爲,文件上傳漏洞的防護,主要圍繞一開始提到的幾點,一是文件上傳路徑,二是文件訪問權限,三是文件執行權限。而且因爲業務關係,根據所上傳文件的類型也須要進行不一樣的防護。好比不少文件上傳點都在用戶頭像上,而且因爲用戶登陸的時候須要顯示頭像,即在HTML源碼中會爆出路徑,所以對於圖片文件的防護方法,主要是採用白名單以及圖片渲染,這樣即便結合解析漏洞或者是文件包含漏洞也無法getshell。另外的一種方法是將用戶上傳的文件都放到指定的目錄中,同時在服務器配置中設定該目錄下的全部文件不可執行,可是該方法存在的風險便是在路徑可知的狀況下配合文件包含漏洞便可突破。所以,我的以爲,針對文件上傳的最好防護方法便是讓上傳路徑不可知,將用戶上傳文件的路徑保存到數據庫中,而且在須要的時候再去讀取加載。

 

最後

  學習網絡安全一年來,真是深深體會到這個坑有多深,從一開始任何編程基礎都沒到如今,感受依然在艱苦爬行,好在即便是小白,看的文章多了耳濡目染,也能開始利用工具再加手工去發現一些小的漏洞,不過雖然坑深,可是當將漏洞原理熟記於心中時,那種根據所學所得去挖漏洞而且成功時的成就感,倒是使人興奮。同時,對於這些漏洞的研究也不斷促使我去思考身邊的一切,現實生活中的各類場景是否像這些代碼同樣有漏洞?往往思及此,對於這個世界的見解便像是有了些不一樣。一我的的學習之路雖然辛苦,可是沉下心來倒是讓日子過得充實,儘管周圍不斷施加壓力於身上。還有好多好多要學,我須要時間,與本身共勉

相關文章
相關標籤/搜索