[[352781]]

網(wǎng)站安全

從從互聯(lián)網(wǎng)發(fā)展開(kāi)始，各種網(wǎng)絡(luò)安全問(wèn)題也就伴隨而生。

近些年來(lái)有很多網(wǎng)站遭到攻擊，如新浪微博遭XSS攻擊，以CSDN為代表的多個(gè)網(wǎng)站泄露用戶密碼和個(gè)人信息。

特別是后者，因?yàn)橛绊懭巳簭V泛，部分受影響網(wǎng)站涉及用戶實(shí)體資產(chǎn)和交易安全，一時(shí)成為輿論焦點(diǎn)。

那么新浪微博是如何被攻擊的?CSDN的密碼為何會(huì)泄露?如何防護(hù)網(wǎng)站免遭攻擊，保護(hù)好用戶的敏感信息呢?

常見(jiàn)的攻擊與防御

XSS攻擊，它和SQL注入攻擊構(gòu)成網(wǎng)站應(yīng)用攻擊最主要的兩種手段，全球大約70%的Web應(yīng)用攻擊都來(lái)自XSS攻擊和SQL注入攻擊。此外，常用的Web應(yīng)用還包括CSRF、Session劫持等手段。

XSS攻擊

XSS攻擊又稱CSS,全稱Cross Site Script (跨站腳本攻擊)，其原理就是攻擊者像有XSS漏洞的網(wǎng)站注入惡意HTML腳本，在用戶瀏覽網(wǎng)頁(yè)時(shí)，這段惡意的HTML 腳本會(huì)自動(dòng)執(zhí)行，從而達(dá)到攻擊的目的。

常見(jiàn)的XSS攻擊類型：

• 反射型，通過(guò)在請(qǐng)求地址上加入惡意的HTML代碼
• dom型 ，通過(guò)一些API向網(wǎng)站注入惡意HTML
• 持久型，將惡意代碼內(nèi)容發(fā)給服務(wù)器，服務(wù)器沒(méi)過(guò)濾就存儲(chǔ)到數(shù)據(jù)庫(kù)中了，下次再請(qǐng)求這個(gè)頁(yè)面時(shí)就會(huì)從數(shù)據(jù)庫(kù)中讀取出惡意代碼拼接到頁(yè)面HTML上

1、反射型XSS攻擊

攻擊步驟：

1、攻擊者構(gòu)造出特殊的URL，其中包含惡意代碼。

2、當(dāng)用戶打開(kāi)帶有惡意代碼的URL時(shí)，網(wǎng)站服務(wù)端將惡意代碼從URL中取出，拼接在HTML中返回瀏覽器，之后用戶瀏覽器收到響應(yīng)后解析執(zhí)行混入其中的惡意代碼。

3、惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。

常見(jiàn)于通過(guò) URL 傳遞參數(shù)的功能，如網(wǎng)站搜索、跳轉(zhuǎn)等。由于需要用戶主動(dòng)打開(kāi)惡意的 URL 才能生效，攻擊者往往會(huì)結(jié)合多種手段誘導(dǎo)用戶點(diǎn)擊。

舉個(gè)栗子：

新浪微博以前被攻擊就是一種反射型XSS攻擊。攻擊者發(fā)布的微博中有一個(gè)含有惡意腳本的URL，用戶點(diǎn)擊該URL，腳本會(huì)自動(dòng)關(guān)注攻擊者的新浪微博ID，發(fā)布含有惡意腳本URL的微博，攻擊就被擴(kuò)散了。

現(xiàn)實(shí)中，攻擊者可以采用XSS攻擊，偷取用戶Cookie、密碼等重要數(shù)據(jù)，進(jìn)而偽造交易、盜竊用戶財(cái)產(chǎn)、竊取情報(bào)

2、存儲(chǔ)型XSS攻擊

攻擊步驟：

1、攻擊者將惡意代碼提交到目標(biāo)網(wǎng)站的數(shù)據(jù)庫(kù)中

2、用戶打開(kāi)網(wǎng)站時(shí)，網(wǎng)站服務(wù)端將惡意代碼從數(shù)據(jù)庫(kù)中取出，拼接在HTML中返回瀏覽器

3、用戶瀏覽器收到響應(yīng)后解析執(zhí)行混入其中的惡意代碼，惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。

常見(jiàn)于帶有用戶保存數(shù)據(jù)的網(wǎng)站功能，比如論壇發(fā)帖、商品評(píng)價(jià)、用戶私信等等。

反射型 XSS 跟存儲(chǔ)型 XSS 的區(qū)別是：存儲(chǔ)型 XSS 的惡意代碼存在數(shù)據(jù)庫(kù)里，反射型 XSS 的惡意代碼存在 URL 里。

DOM型XSS

攻擊步驟：

1、攻擊者構(gòu)造出特殊的URL，其中包含惡意代碼

2、用戶打開(kāi)帶有惡意代碼的URL，用戶瀏覽器打開(kāi)帶有惡意代碼的URL，之后用戶瀏覽器收到響應(yīng)后解析執(zhí)行，前端JS取出URL中的惡意代碼并執(zhí)行

3、惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。

DOM 型 XSS 跟前兩種 XSS 的區(qū)別：

DOM 型 XSS 攻擊中，取出和執(zhí)行惡意代碼由瀏覽器端完成，屬于前端 JavaScript 自身的安全漏洞，而其他兩種 XSS 都屬于服務(wù)端的安全漏洞。

XSS的防御手段主要有兩種：

• 消毒
• HttpOnly

XSS的防御-消毒

XSS攻擊者一般都是通過(guò)在請(qǐng)求中嵌入惡意腳本達(dá)到攻擊的目的，這些腳本是一般用戶輸入中不使用的，如果進(jìn)行過(guò)濾和消毒處理，即對(duì)某些html危險(xiǎn)字符轉(zhuǎn)義。

如 “>” 轉(zhuǎn)義為“>” 、“<”轉(zhuǎn)義為 “<”等，就可以防止大部分攻擊。

為了避免對(duì)不必要的內(nèi)容錯(cuò)誤轉(zhuǎn)義，如“3<5”中的 “<” 需要進(jìn)行文本匹配后再轉(zhuǎn)義，如 “

事實(shí)上，消毒幾乎是所有網(wǎng)站最必備的XSS防攻擊手段。

XSS的防御-HttpOnly

瀏覽器禁止頁(yè)面 JavaScript訪問(wèn)帶有HttpOnly 屬性的敏感 Cookie。

HttpOnly并不是直接對(duì)抗XSS攻擊的，而是防止XSS攻擊者竊取Cookie，就算完成XSS注入后也無(wú)法竊取此Cookie屬性，防止冒充用戶提交請(qǐng)求。

注入攻擊

注入攻擊主要有兩種形式：

• SQL注入攻擊
• OS注入攻擊

SQL注入攻擊

攻擊者在HTTP請(qǐng)求中注入惡意SQL命令(drop table users;)，服務(wù)器用請(qǐng)求參數(shù)構(gòu)造數(shù)據(jù)庫(kù)SQL命令時(shí)，惡意SQL被一起構(gòu)造，并在數(shù)據(jù)庫(kù)中執(zhí)行。

攻擊者獲取數(shù)據(jù)庫(kù)表結(jié)構(gòu)信息的手段：

• 開(kāi)源，比如一些開(kāi)源的博客數(shù)據(jù)庫(kù)表是公開(kāi)的，攻擊者可以直接獲得。
• 錯(cuò)誤回顯，如果網(wǎng)站開(kāi)啟錯(cuò)誤回顯，即服務(wù)器內(nèi)部500錯(cuò)誤會(huì)顯示到瀏覽器上。攻擊者通過(guò)故意構(gòu)造非法參數(shù)，使服務(wù)端異常信息輸出到瀏覽器端，為攻擊猜測(cè)數(shù)據(jù)庫(kù)表結(jié)構(gòu)提供了便利。
• 盲注，網(wǎng)站關(guān)閉錯(cuò)誤回顯，攻擊者根據(jù)頁(yè)面變化情況判斷SQL語(yǔ)句的執(zhí)行情況，據(jù)此猜測(cè)數(shù)據(jù)庫(kù)表結(jié)構(gòu)。

預(yù)防SQL注入

• 消毒，和防XSS攻擊一樣，請(qǐng)求參數(shù)編碼是一種比較簡(jiǎn)單粗暴又有效的手段。通過(guò)正則匹配，過(guò)濾請(qǐng)求數(shù)據(jù)中可能注入的SQL，如“drop table”、“\b(?:update\b.?\bset|delete\b\W?\bfrom)\b”等
• 參數(shù)綁定，使用預(yù)編譯手段，綁定參數(shù)是最好的防SQL注入方法。目前許多數(shù)據(jù)訪問(wèn)層框架，如IBatis，Hibernate等，都實(shí)現(xiàn)SQL預(yù)編譯和參數(shù)綁定，攻擊者的惡意SQL會(huì)被當(dāng)做SQL的參數(shù)，而不是SQL命令被執(zhí)行。

除了SQL注入，攻擊者還根據(jù)具體應(yīng)用，注入OS命令、編程語(yǔ)言代碼等，利用程序漏洞，達(dá)到攻擊目的。

CSRF攻擊

CSRF(Cross Site Request Forgery，跨站點(diǎn)請(qǐng)求偽造)，是一種劫持授信用戶向服務(wù)器發(fā)送非預(yù)期請(qǐng)求的攻擊方式，也就是以合法用戶的身份進(jìn)行非法操作。

攻擊者會(huì)誘導(dǎo)受害者訪問(wèn)第三方網(wǎng)站，利用受害者獲得的被攻擊網(wǎng)站的憑證來(lái)冒充正常用戶對(duì)被攻擊網(wǎng)站進(jìn)行某些操作的目的。

如轉(zhuǎn)賬交易、發(fā)表評(píng)論等。CSRF的主要手法是利用跨站請(qǐng)求，在用戶不知情的情況下，以用戶的身份偽造請(qǐng)求。

其核心是利用了瀏覽器Cookie或服務(wù)器Session策略，盜取用戶身份

CSRF的防御

CSRF的防御手段主要是識(shí)別請(qǐng)求者身份，防止第三方網(wǎng)站進(jìn)行冒充，主要有下面幾種方法：

盡量POST，限制GET

GET接口太容易被拿來(lái)做CSRF攻擊，看第一個(gè)示例就知道，只要構(gòu)造一個(gè)img標(biāo)簽，而img標(biāo)簽又是不能過(guò)濾的數(shù)據(jù)。接口最好限制為POST使用，GET則無(wú)效，降低攻擊風(fēng)險(xiǎn)。

當(dāng)然POST并不是萬(wàn)無(wú)一失，攻擊者只要構(gòu)造一個(gè)form就可以，但需要在第三方頁(yè)面做，這樣就增加暴露的可能性。

表單Token

CSRF是一個(gè)偽造用戶請(qǐng)求的操作，所以需要構(gòu)造用戶請(qǐng)求的所有參數(shù)才可以。

表單Token通過(guò)在請(qǐng)求參數(shù)中增加隨機(jī)數(shù)的辦法來(lái)阻止攻擊者獲得所有請(qǐng)求參數(shù)：

在頁(yè)面表單中增加一個(gè)隨機(jī)數(shù)作為Token，每次響應(yīng)頁(yè)面的Token都不相同，從正常頁(yè)面提交的請(qǐng)求會(huì)包含該Token值，而偽造的請(qǐng)求無(wú)法獲得該值，服務(wù)器檢查請(qǐng)求參數(shù)中Token的值是否存在并且正確以確定請(qǐng)求提交者是否合法。

驗(yàn)證碼

相對(duì)說(shuō)來(lái)，驗(yàn)證碼則更加簡(jiǎn)單有效，即請(qǐng)求提交時(shí)，需要用戶輸入驗(yàn)證碼，以避免在用戶不知情的情況下被攻擊者偽造請(qǐng)求。

Referer check

HTTP請(qǐng)求頭的Referer域中記錄著請(qǐng)求來(lái)源，可通過(guò)檢查請(qǐng)求來(lái)源，驗(yàn)證其是否合法。很多網(wǎng)站使用這個(gè)功能實(shí)現(xiàn)圖片防盜鏈(如果圖片訪問(wèn)的頁(yè)面來(lái)源不是來(lái)自自己網(wǎng)站的網(wǎng)頁(yè)就拒絕)。

本文轉(zhuǎn)載自微信公眾號(hào)「架構(gòu)技術(shù)專欄」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系架構(gòu)技術(shù)專欄公眾號(hào)。