文件上傳漏洞攻擊與防御

前言

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

　　關於文件上傳漏洞，百度一下便有許多文章出來，在這里我也稍稍做整理。

 

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

　　一是文件可上傳（感覺這一句是廢話）。二是上傳文件路徑可知，如果路徑不可知就沒法訪問，亦無法配合諸如文件包含漏洞進行文件執行。三是上傳文件可以被訪問。四是上傳文件可以被執行，當然這一步也不是必需的，比如配合文件包含漏洞。

 

0x01 文件上傳中的可控點

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

　　以下是DVWA程序中上傳攻擊的請求包

POST /DVWA/vulnerabilities/upload/ HTTP/1.1
Host: 127.0.0.1
Content-Length: 5108  4 Cache-Control: max-age=0
Origin: http://127.0.0.1
Upgrade-Insecure-Requests: 1
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
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryJUcYpiAjyVAzt5yA
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://127.0.0.1/DVWA/vulnerabilities/upload/
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.8
Cookie: security=low; PHPSESSID=plp6nm81is9eotcvfo3td8thp4
Connection: close

------WebKitFormBoundaryJUcYpiAjyVAzt5yA
Content-Disposition: form-data; name="MAX_FILE_SIZE"

100000
------WebKitFormBoundaryJUcYpiAjyVAzt5yA
Content-Disposition: form-data; name="uploaded"; filename="timg.jpg"
Content-Type: image/jpeg 23 
?? JFIF 


 H H ? C   25 
    


 "" $(4,$&1'-=-157:::#+?D?8C49:7? C





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?? }]鱅
?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
w瑘t叜m??H檌鉅?? "﹖r熪~h%闕蕘cs咁"綆Зtn得?镺╩<O#V?挒j陂r鬁?(28?涫 ?zoE旒W I胰"s躻qM核猋s轍踃?Um眯AW7Ｔ7T牞l噠J協}oG杵Zk?興*?k贓宦\nS
@罔S磑Jb々??k-m!Ζd鄈n鬾"n嵐粀頂I
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頫? 
P><嵏挖縭︶z散特?  H? ?徟id宲7頭艈狁GN茊 2?Y癶K標;?蠺P狴鎡^.\p煡鎠澦虛﹔45胑難4:?>x母v畷?7冚{
埍_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栮
爬騈街@A泘狢東?寢鞖倭??蹭鑰"?D袟<工k瓛@^)?繛 庤蘐 3嵇?關 澁焙駢酪?朅#E厤愪蓽様VF咶銹(笰>冋?蟻梎袥璿留緵1悒n薣刟懶al崙唨蹫騏?硬★杅]逯?姑(汳N蒯vX€癿瑒??佈?3&疰c媆玉
頕1戜gg?@蕪?錨k陘kz0'I踼H'焸紜崛?|糌?2?0s%臂??娪棲條_桻<o
V姄H?;飯`|uQI1?x倥?┡?·閐依諏e遴y"宒s?p?捳p? 簴U梴仟轆
<-V?c*~椬u賭OG隯肀%
[侭)廌:9 ?    k汮鴊戾鱤腷竻F
ji?輲練? 脝bN姃z'M<靮妯粌橃妻逗-_a?尰;H繆筲1|9覥IQ408枑#???槙4??)s?@貄V~
e?u嗎c
?鉺+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{怗+???呡虜|q
d?8闕豯妳蝧A(#滈`/嗒j)櫥q銾雬e崅啟&=弓n?D碞sA
轎攂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
o致&lO硑?誾?-鑉匕誼4蝹V濺膕銀W?tq腎鏐禍冄醏;報?d_L屎帹J纚裭炵D忠?g`-餢焊烠\??幵w梔膽?嵯
欏ip悅7訒f魄8?式砇鰑.YF:B摚攲靘闍倪A ，?熼?7?    ?CT鴫?盳蔿[?詘+ 疋嫲T革V隆睬?犲籓"y 駫季:h捺?鬼鍉_韞孯本粶F郫H??榌[b? 9w蚞@粄@崏@}<s獼7a)Is.?€乁7膀|?韢??7[給 &偤\6?樜R
??涪艑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

?姮ET鉛D蜽?|ys婇鴟??&?歳?押?9幁qv桿8??[賧.iK奝鷝?"7cu伃?牁9僛;B<<Qt曺溋V3
?{^(姪0?,O姞?乵
颾?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扏扞$?
------WebKitFormBoundaryJUcYpiAjyVAzt5yA
Content-Disposition: form-data; name="Upload"

Upload
------WebKitFormBoundaryJUcYpiAjyVAzt5yA--

　　其實對於整個HTTP請求包來說，所有內容都是用戶可控的，只是請求包中的幾個點有可能是后台服務器的檢測重點，在上面的請求內容中，加粗加大的紅色字體為可能的后台檢測重點，主要有幾處：

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

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

　　3. filename,即上傳文件名

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

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

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

 

0x02 后台的檢測點

　　依然是以DVWA的代碼為示例，分別展示一下DVWA不同等級下的代碼（雖然DVWA被人拿來示例了好多次，我還是厚着臉皮也用一次，畢竟簡單易懂...）

　　1. low級別的檢測

<?php

if( isset( $_POST[ 'Upload' ] ) ) {
    // Where are we going to be writing to?
    $target_path  = DVWA_WEB_PAGE_TO_ROOT . "hackable/uploads/";
    $target_path .= basename( $_FILES[ 'uploaded' ][ 'name' ] );

    // Can we move the file to the upload folder?
    if( !move_uploaded_file( $_FILES[ 'uploaded' ][ 'tmp_name' ], $target_path ) ) {
        // No
        $html .= '<pre>Your image was not uploaded.</pre>';
    }
    else {
        // Yes!
        $html .= "<pre>{$target_path} succesfully uploaded!</pre>";
    }
}

?>

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

 

　　2. medium級別的檢測

<?php

if( isset( $_POST[ 'Upload' ] ) ) {
    // Where are we going to be writing to?
    $target_path  = DVWA_WEB_PAGE_TO_ROOT . "hackable/uploads/";
    $target_path .= basename( $_FILES[ 'uploaded' ][ 'name' ] );

    // File information
    $uploaded_name = $_FILES[ 'uploaded' ][ 'name' ];
    $uploaded_type = $_FILES[ 'uploaded' ][ 'type' ];
    $uploaded_size = $_FILES[ 'uploaded' ][ 'size' ];

    // Is it an image?
    if( ( $uploaded_type == "image/jpeg" || $uploaded_type == "image/png" ) &&
        ( $uploaded_size < 100000 ) ) {

        // Can we move the file to the upload folder?
        if( !move_uploaded_file( $_FILES[ 'uploaded' ][ 'tmp_name' ], $target_path ) ) {
            // No
            $html .= '<pre>Your image was not uploaded.</pre>';
        }
        else {
            // Yes!
            $html .= "<pre>{$target_path} succesfully uploaded!</pre>";
        }
    }
    else {
        // Invalid file
        $html .= '<pre>Your image was not uploaded. We can only accept JPEG or PNG images.</pre>';
    }
}

?>

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

 

　　3. high級別的檢測

<?php

if( isset( $_POST[ 'Upload' ] ) ) {
    // Where are we going to be writing to?
    $target_path  = DVWA_WEB_PAGE_TO_ROOT . "hackable/uploads/";
    $target_path .= basename( $_FILES[ 'uploaded' ][ 'name' ] );

    // File information
    $uploaded_name = $_FILES[ 'uploaded' ][ 'name' ];
    $uploaded_ext  = substr( $uploaded_name, strrpos( $uploaded_name, '.' ) + 1);
    $uploaded_size = $_FILES[ 'uploaded' ][ 'size' ];
    $uploaded_tmp  = $_FILES[ 'uploaded' ][ 'tmp_name' ];

    // Is it an image?
    if( ( strtolower( $uploaded_ext ) == "jpg" || strtolower( $uploaded_ext ) == "jpeg" || strtolower( $uploaded_ext ) == "png" ) &&
        ( $uploaded_size < 100000 ) &&
        getimagesize( $uploaded_tmp ) ) {

        // Can we move the file to the upload folder?
        if( !move_uploaded_file( $uploaded_tmp, $target_path ) ) {
            // No
            $html .= '<pre>Your image was not uploaded.</pre>';
        }
        else {
            // Yes!
            $html .= "<pre>{$target_path} succesfully uploaded!</pre>";
        }
    }
    else {
        // Invalid file
        $html .= '<pre>Your image was not uploaded. We can only accept JPEG or PNG images.</pre>';
    }
}

?>

　　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級別的檢測

<?php

if( isset( $_POST[ 'Upload' ] ) ) {
    // Check Anti-CSRF token
    checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' );


    // File information
    $uploaded_name = $_FILES[ 'uploaded' ][ 'name' ];
    $uploaded_ext  = substr( $uploaded_name, strrpos( $uploaded_name, '.' ) + 1);
    $uploaded_size = $_FILES[ 'uploaded' ][ 'size' ];
    $uploaded_type = $_FILES[ 'uploaded' ][ 'type' ];
    $uploaded_tmp  = $_FILES[ 'uploaded' ][ 'tmp_name' ];

    // Where are we going to be writing to?
    $target_path   = DVWA_WEB_PAGE_TO_ROOT . 'hackable/uploads/';
    //$target_file   = basename( $uploaded_name, '.' . $uploaded_ext ) . '-';
    $target_file   =  md5( uniqid() . $uploaded_name ) . '.' . $uploaded_ext;
    $temp_file     = ( ( ini_get( 'upload_tmp_dir' ) == '' ) ? ( sys_get_temp_dir() ) : ( ini_get( 'upload_tmp_dir' ) ) );
    $temp_file    .= DIRECTORY_SEPARATOR . md5( uniqid() . $uploaded_name ) . '.' . $uploaded_ext;

    // Is it an image?
    if( ( strtolower( $uploaded_ext ) == 'jpg' || strtolower( $uploaded_ext ) == 'jpeg' || strtolower( $uploaded_ext ) == 'png' ) &&
        ( $uploaded_size < 100000 ) &&
        ( $uploaded_type == 'image/jpeg' || $uploaded_type == 'image/png' ) &&
        getimagesize( $uploaded_tmp ) ) {

        // Strip any metadata, by re-encoding image (Note, using php-Imagick is recommended over php-GD)
        if( $uploaded_type == 'image/jpeg' ) {
            $img = imagecreatefromjpeg( $uploaded_tmp );
            imagejpeg( $img, $temp_file, 100);
        }
        else {
            $img = imagecreatefrompng( $uploaded_tmp );
            imagepng( $img, $temp_file, 9);
        }
        imagedestroy( $img );

        // Can we move the file to the web root from the temp folder?
        if( rename( $temp_file, ( getcwd() . DIRECTORY_SEPARATOR . $target_path . $target_file ) ) ) {
            // Yes!
            $html .= "<pre><a href='${target_path}${target_file}'>${target_file}</a> succesfully uploaded!</pre>";
        }
        else {
            // No
            $html .= '<pre>Your image was not uploaded.</pre>';
        }

        // Delete any temp files
        if( file_exists( $temp_file ) )
            unlink( $temp_file );
    }
    else {
        // Invalid file
        $html .= '<pre>Your image was not uploaded. We can only accept JPEG or PNG images.</pre>';
    }
}

// Generate Anti-CSRF token
generateSessionToken();

?>

　　針對這個級別的檢測，我表示沒有辦法了，后台代碼從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。另外的一種方法是將用戶上傳的文件都放到指定的目錄中，同時在服務器配置中設定該目錄下的所有文件不可執行，但是該方法存在的風險即是在路徑可知的情況下配合文件包含漏洞即可突破。因此，個人覺得，針對文件上傳的最好防御方法即是讓上傳路徑不可知，將用戶上傳文件的路徑保存到數據庫中，並且在需要的時候再去讀取加載。

 

最后

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