建站
咨詢
售后
建站咨詢
新聞中心
網(wǎng)站安全
從從互聯(lián)網(wǎng)發(fā)展開始，各種網(wǎng)絡(luò)安全問題也就伴隨而生。
近些年來有很多網(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ù)好用戶的敏感信息呢?
常見的攻擊與防御
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)頁時(shí)，這段惡意的HTML 腳本會(huì)自動(dòng)執(zhí)行，從而達(dá)到攻擊的目的。
常見的XSS攻擊類型：
- 反射型，通過在請(qǐng)求地址上加入惡意的HTML代碼
- dom型 ，通過一些API向網(wǎng)站注入惡意HTML
- 持久型，將惡意代碼內(nèi)容發(fā)給服務(wù)器，服務(wù)器沒過濾就存儲(chǔ)到數(shù)據(jù)庫中了，下次再請(qǐng)求這個(gè)頁面時(shí)就會(huì)從數(shù)據(jù)庫中讀取出惡意代碼拼接到頁面HTML上
1、反射型XSS攻擊
攻擊步驟：
1、攻擊者構(gòu)造出特殊的URL，其中包含惡意代碼。
2、當(dāng)用戶打開帶有惡意代碼的URL時(shí)，網(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)等。由于需要用戶主動(dòng)打開惡意的 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ù)庫中
2、用戶打開網(wǎng)站時(shí)，網(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ā)帖、商品評(píng)價(jià)、用戶私信等等。
反射型 XSS 跟存儲(chǔ)型 XSS 的區(qū)別是：存儲(chǔ)型 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攻擊者一般都是通過在請(qǐng)求中嵌入惡意腳本達(dá)到攻擊的目的，這些腳本是一般用戶輸入中不使用的，如果進(jìn)行過濾和消毒處理，即對(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
瀏覽器禁止頁面 JavaScript訪問帶有HttpOnly 屬性的敏感 Cookie。
HttpOnly并不是直接對(duì)抗XSS攻擊的，而是防止XSS攻擊者竊取Cookie，就算完成XSS注入后也無法竊取此Cookie屬性，防止冒充用戶提交請(qǐng)求。
注入攻擊
注入攻擊主要有兩種形式：
- SQL注入攻擊
- OS注入攻擊
SQL注入攻擊
攻擊者在HTTP請(qǐng)求中注入惡意SQL命令(drop table users;)，服務(wù)器用請(qǐng)求參數(shù)構(gòu)造數(shù)據(jù)庫SQL命令時(shí)，惡意SQL被一起構(gòu)造，并在數(shù)據(jù)庫中執(zhí)行。
攻擊者獲取數(shù)據(jù)庫表結(jié)構(gòu)信息的手段：
- 開源，比如一些開源的博客數(shù)據(jù)庫表是公開的，攻擊者可以直接獲得。
- 錯(cuò)誤回顯，如果網(wǎng)站開啟錯(cuò)誤回顯，即服務(wù)器內(nèi)部500錯(cuò)誤會(huì)顯示到瀏覽器上。攻擊者通過故意構(gòu)造非法參數(shù)，使服務(wù)端異常信息輸出到瀏覽器端，為攻擊猜測(cè)數(shù)據(jù)庫表結(jié)構(gòu)提供了便利。
- 盲注，網(wǎng)站關(guān)閉錯(cuò)誤回顯，攻擊者根據(jù)頁面變化情況判斷SQL語句的執(zhí)行情況，據(jù)此猜測(cè)數(shù)據(jù)庫表結(jié)構(gòu)。
預(yù)防SQL注入
- 消毒，和防XSS攻擊一樣，請(qǐng)求參數(shù)編碼是一種比較簡(jiǎn)單粗暴又有效的手段。通過正則匹配，過濾請(qǐng)求數(shù)據(jù)中可能注入的SQL，如“drop table”、“\b(?:update\b.?\bset|delete\b\W?\bfrom)\b”等
- 參數(shù)綁定，使用預(yù)編譯手段，綁定參數(shù)是最好的防SQL注入方法。目前許多數(shù)據(jù)訪問層框架，如IBatis，Hibernate等，都實(shí)現(xiàn)SQL預(yù)編譯和參數(shù)綁定，攻擊者的惡意SQL會(huì)被當(dāng)做SQL的參數(shù)，而不是SQL命令被執(zhí)行。
除了SQL注入，攻擊者還根據(jù)具體應(yīng)用，注入OS命令、編程語言代碼等，利用程序漏洞，達(dá)到攻擊目的。
CSRF攻擊
CSRF(Cross Site Request Forgery，跨站點(diǎn)請(qǐng)求偽造)，是一種劫持授信用戶向服務(wù)器發(fā)送非預(yù)期請(qǐng)求的攻擊方式，也就是以合法用戶的身份進(jìn)行非法操作。
攻擊者會(huì)誘導(dǎo)受害者訪問第三方網(wǎng)站，利用受害者獲得的被攻擊網(wǎng)站的憑證來冒充正常用戶對(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接口太容易被拿來做CSRF攻擊，看第一個(gè)示例就知道，只要構(gòu)造一個(gè)img標(biāo)簽，而img標(biāo)簽又是不能過濾的數(shù)據(jù)。接口最好限制為POST使用，GET則無效，降低攻擊風(fēng)險(xiǎn)。
當(dāng)然POST并不是萬無一失，攻擊者只要構(gòu)造一個(gè)form就可以，但需要在第三方頁面做，這樣就增加暴露的可能性。
表單Token
CSRF是一個(gè)偽造用戶請(qǐng)求的操作，所以需要構(gòu)造用戶請(qǐng)求的所有參數(shù)才可以。
表單Token通過在請(qǐng)求參數(shù)中增加隨機(jī)數(shù)的辦法來阻止攻擊者獲得所有請(qǐng)求參數(shù)：
在頁面表單中增加一個(gè)隨機(jī)數(shù)作為Token，每次響應(yīng)頁面的Token都不相同，從正常頁面提交的請(qǐng)求會(huì)包含該Token值，而偽造的請(qǐng)求無法獲得該值，服務(wù)器檢查請(qǐng)求參數(shù)中Token的值是否存在并且正確以確定請(qǐng)求提交者是否合法。
驗(yàn)證碼
相對(duì)說來，驗(yàn)證碼則更加簡(jiǎn)單有效，即請(qǐng)求提交時(shí)，需要用戶輸入驗(yàn)證碼，以避免在用戶不知情的情況下被攻擊者偽造請(qǐng)求。
Referer check
HTTP請(qǐng)求頭的Referer域中記錄著請(qǐng)求來源，可通過檢查請(qǐng)求來源，驗(yàn)證其是否合法。很多網(wǎng)站使用這個(gè)功能實(shí)現(xiàn)圖片防盜鏈(如果圖片訪問的頁面來源不是來自自己網(wǎng)站的網(wǎng)頁就拒絕)。
本文轉(zhuǎn)載自微信公眾號(hào)「架構(gòu)技術(shù)專欄」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系架構(gòu)技術(shù)專欄公眾號(hào)。
當(dāng)前題目：講真！這些攻擊手段你知道嗎
本文來源：http://www.5511xx.com/article/dpgspgh.html
