[[352781]]

網(wǎng)站安全

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

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

特別是后者，因為影響人群廣泛，部分受影響網(wǎng)站涉及用戶實體資產(chǎn)和交易安全，一時成為輿論焦點。

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

常見的攻擊與防御

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

XSS攻擊

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

常見的XSS攻擊類型：

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

1、反射型XSS攻擊

攻擊步驟：

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

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

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

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

舉個栗子：

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

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

2、存儲型XSS攻擊

攻擊步驟：

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

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

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

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

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

DOM型XSS

攻擊步驟：

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

2、用戶打開帶有惡意代碼的URL，用戶瀏覽器打開帶有惡意代碼的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攻擊者一般都是通過在請求中嵌入惡意腳本達(dá)到攻擊的目的，這些腳本是一般用戶輸入中不使用的，如果進(jìn)行過濾和消毒處理，即對某些html危險字符轉(zhuǎn)義。

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

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

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

XSS的防御-HttpOnly

瀏覽器禁止頁面 JavaScript訪問帶有HttpOnly 屬性的敏感 Cookie。

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

注入攻擊

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

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

SQL注入攻擊

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

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

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

預(yù)防SQL注入

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

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

CSRF攻擊

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

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

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

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

CSRF的防御

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

盡量POST，限制GET

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

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

表單Token

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

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

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

驗證碼

相對說來，驗證碼則更加簡單有效，即請求提交時，需要用戶輸入驗證碼，以避免在用戶不知情的情況下被攻擊者偽造請求。

Referer check

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

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