码迷,mamicode.com
首页 > Web开发 > 详细

文件上传漏洞攻击与防御

时间:2017-04-25 00:51:42      阅读:911      评论:0      收藏:0      [点我收藏+]

标签:http协议   黑名单   link   工具   xhtml   xxx   系统   flat   orm   

前言

  从一年前开始学习web安全以来,一直都是在吸收零碎的知识,不断地看书与一些前辈的文章,中间也经过一些实践,学习相关的工具,但是却没真真正正地在脑中形成一套完整的体系。从不久前就想着要写一些博客,趁着这个机会,便好好梳理一下所学的知识,只是这些文章所写大部分内容也是搬运前辈的文章,鲜有自己所想所悟。

  关于文件上传漏洞,百度一下便有许多文章出来,在这里我也稍稍做整理。

 

0x00 文件上传漏洞所需满足的条件

  一是文件可上传(感觉这一句是废话)。二是上传文件路径可知,如果路径不可知就没法访问,亦无法配合诸如文件包含漏洞进行文件执行。三是上传文件可以被访问。四是上传文件可以被执行,当然这一步也不是必需的,比如配合文件包含漏洞。

 

0x01 文件上传中的可控点

  通过HTTP协议上传文件的过程中,将通过POST请求对文件内容进行传输,而在HTTP请求包中,有可能存在的用户可控点有几个,接下来将以DVWA程序为示例:

  以下是DVWA程序中上传攻击的请求包

 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请求包来说,所有内容都是用户可控的,只是请求包中的几个点有可能是后台服务器的检测重点,在上面的请求内容中,加粗加大的红色字体为可能的后台检测重点,主要有几处:

  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。另外的一种方法是将用户上传的文件都放到指定的目录中,同时在服务器配置中设定该目录下的所有文件不可执行,但是该方法存在的风险即是在路径可知的情况下配合文件包含漏洞即可突破。因此,个人觉得,针对文件上传的最好防御方法即是让上传路径不可知,将用户上传文件的路径保存到数据库中,并且在需要的时候再去读取加载。

 

最后

  学习网络安全一年来,真是深深体会到这个坑有多深,从一开始任何编程基础都没到现在,感觉依然在艰苦爬行,好在即使是小白,看的文章多了耳濡目染,也能开始利用工具再加手工去发现一些小的漏洞,不过虽然坑深,但是当将漏洞原理熟记于心中时,那种根据所学所得去挖漏洞并且成功时的成就感,却是令人兴奋。同时,对于这些漏洞的研究也不断促使我去思考身边的一切,现实生活中的各种场景是否像这些代码一样有漏洞?每每思及此,对于这个世界的看法便像是有了些不同。一个人的学习之路虽然辛苦,但是沉下心来却是让日子过得充实,尽管周围不断施加压力于身上。还有好多好多要学,我需要时间,与自己共勉

  

文件上传漏洞攻击与防御

标签:http协议   黑名单   link   工具   xhtml   xxx   系统   flat   orm   

原文地址:http://www.cnblogs.com/crazylocust/p/6759529.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!