1.XSS

說明:

XSS攻擊全稱 跨站腳本攻擊(Cross Site Scripting),是為不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆,故將跨站腳本攻擊縮寫為XSS.

XSS簡(jiǎn)單分為反射型恋脚、存儲(chǔ)型(DOM型屬于反射型的一種),其本質(zhì)上是HTML注入,簡(jiǎn)單來說就是通過某種手段引誘受害者(用戶)信任該腳本(或網(wǎng)站),進(jìn)而可以使攻擊方的代碼在客戶端為所欲為.

常見的諸如各類釣魚網(wǎng)站,釣魚郵件,或是最簡(jiǎn)單的頁面腳本注入等皆為此類型.

舉個(gè)栗子:

• 反射型:
  反射型XSS需要欺騙用戶去執(zhí)行(訪問或點(diǎn)擊)攻擊者構(gòu)造的腳本,從而觸發(fā)js事件.也就是說,這種攻擊手段是被動(dòng)執(zhí)行的.

舉個(gè)栗子:
假如構(gòu)造一個(gè)形如

http://demo/index.html?user=%3Cscript%3Ealert(233)%3C/script%3E

這樣的url,那么當(dāng)用戶訪問該url時(shí),script中的腳本就會(huì)被執(zhí)行,同時(shí)由于domain為受信任的網(wǎng)站,所以可以正常獲取到用戶的敏感信息.

這種注入方式由于特征明顯,可以被很多瀏覽器過濾掉.

• 存儲(chǔ)型:
  存儲(chǔ)型XSS將攻擊代碼持久化存儲(chǔ)在數(shù)據(jù)庫\服務(wù)器中,使得每次該數(shù)據(jù)被load時(shí),該腳本都會(huì)被執(zhí)行.

舉個(gè)栗子:
假如用戶輸入未被驗(yàn)證,在數(shù)據(jù)庫中存儲(chǔ)了以下數(shù)據(jù):

<script>alert("xxx");<script>

那么每當(dāng)該數(shù)據(jù)被頁面讀取,該腳本就會(huì)被客戶端解析并加載一次.

當(dāng)然,注入方式多種多樣,可能是未經(jīng)過驗(yàn)證的腳本輸入(<script></script>),或者一張帶有執(zhí)行腳本的圖片文件(<img>).

防范:

防御XSS最棘手的地方就在于其切入點(diǎn)的多樣性,特別是在業(yè)務(wù)體量巨大的情況下,試圖篩選出所有XSS的注入點(diǎn)實(shí)在是費(fèi)時(shí)費(fèi)力.

一般而言,最基本的防范措施:

• 1.輸入過濾;
  根據(jù)業(yè)務(wù)需求,適當(dāng)過濾掉' " , < > \ <! --等特殊字符,盡量保證錄入后端的數(shù)據(jù)可靠性;
• 2.輸出過濾;
  同上,盡量保證輸出到頁面的數(shù)據(jù)可靠性;
• 3.開啟瀏覽器自帶的XSS防護(hù);
  可以有效過濾很多低端釣魚鏈接;

防范XSS的核心在于記住一句話:
所有的輸入都是有害的盟榴。

2.CSRF

說明:

CSRF（Cross-site request forgery）跨站請(qǐng)求偽造,也被稱為“One Click Attack”或者Session Riding,通郴枵祝縮寫為CSRF或者XSRF,是一種對(duì)網(wǎng)站的惡意利用.盡管聽起來像跨站腳本XSS,但它與XSS非常不同,XSS利用站點(diǎn)內(nèi)的信任用戶,而CSRF則通過偽裝來自受信任用戶的請(qǐng)求來利用受信任的網(wǎng)站.與XSS攻擊相比,CSRF攻擊往往不大流行（因此對(duì)其進(jìn)行防范的資源也相當(dāng)稀少）和難以防范,所以被認(rèn)為比XSS更具危險(xiǎn)性.

CSRF的根本原因是服務(wù)器對(duì)用戶身份的過分信任或驗(yàn)證機(jī)制的不完善.

CSRF可以使用XSS作為payload,在用戶不知情的情況下攫取受害者(用戶)的真實(shí)信息(cookie等),從而使用該真實(shí)信息向服務(wù)器發(fā)起請(qǐng)求.

舉個(gè)栗子:
假如某站將session_id以cookie的方式記錄在客戶端中,并且每次提交都以該session_id作為用戶身份識(shí)別的依據(jù),那么在用戶已登錄的情況下,攻擊者只要通過上文介紹的XSS方式,誘騙或引導(dǎo)用戶執(zhí)行以下代碼就能獲取這個(gè)關(guān)鍵的session_id:

var sid = $.cookie('session_id'); // 獲取用戶信息
$.POST('/攻擊方url', sid);

當(dāng)攻擊者獲取session_id后,就可以在該身份有效期內(nèi)利用這個(gè)session_id偽造成該用戶從而進(jìn)行各種操作.當(dāng)服務(wù)器的驗(yàn)證方式不夠健全時(shí),這種操作方式可以是致命的.

防范:

由于CSRF在客戶端難以被預(yù)測(cè),所以防御手段主要集中在服務(wù)端.

• 1.驗(yàn)證HTTP Referer字段:
  該字段記錄了本次請(qǐng)求的來源,通過比對(duì)驗(yàn)證該字段值可以拒絕來自白名單外的訪問請(qǐng)求.不過需要注意的是,來自某些來源的訪問并不帶有Referer字段(如桌面超鏈接,word文檔超鏈接等),并且Referer字段是可以被偽造的.
• 2.使用獨(dú)特的加密規(guī)則,在每次請(qǐng)求中攜帶并驗(yàn)證一個(gè)token的正確性:
  這是目前最實(shí)用且易用的解決方案.需要注意的是,該token的加密及驗(yàn)證方式需要足夠的安全性,避免驗(yàn)證規(guī)則被暴力解析,并且在某些業(yè)務(wù)中,該方式并不足夠靈活.
• 3.使用定制HTTP報(bào)頭:
  定制一個(gè)HTTP的報(bào)頭并置于每次請(qǐng)求中,服務(wù)端收到請(qǐng)求后首先驗(yàn)證報(bào)頭的正確性.不確定報(bào)頭能否被跨站偽造,所以該方式本人持懷疑態(tài)度.
• 4.增加額外的驗(yàn)證步驟:
  在敏感操作前增加如驗(yàn)證碼等操作,這樣會(huì)增加額外的操作,需要在用戶體驗(yàn)和安全性之間做出權(quán)衡.
• 5.對(duì)于一些安全等級(jí)較高或來源不可控的訪問業(yè)務(wù)(如支付,三方登陸等),現(xiàn)在有個(gè)比較流行的授權(quán)方案:
  OAuth協(xié)議
  該協(xié)議目前已是2.0版本,泛用性較高,并且各平臺(tái)將該協(xié)議演化出了不同版本.這里就不再贅述.

3.DDoS

說明:

DDoS是Denial of Service的簡(jiǎn)稱，即拒絕服務(wù)盾鳞，造成DDoS的攻擊行為被稱為DDoS攻擊，其目的是使計(jì)算機(jī)或網(wǎng)絡(luò)無法提供正常的服務(wù)杆兵。最常見的DDoS攻擊有計(jì)算機(jī)網(wǎng)絡(luò)帶寬攻擊和連通性攻擊雁仲。

DDoS攻擊是指故意的攻擊網(wǎng)絡(luò)協(xié)議實(shí)現(xiàn)的缺陷或直接通過野蠻手段殘忍地耗盡被攻擊對(duì)象的資源，目的是讓目標(biāo)計(jì)算機(jī)或網(wǎng)絡(luò)無法提供正常的服務(wù)或資源訪問琐脏，使目標(biāo)系統(tǒng)服務(wù)系統(tǒng)停止響應(yīng)甚至崩潰攒砖，而在此攻擊中并不包括侵入目標(biāo)服務(wù)器或目標(biāo)網(wǎng)絡(luò)設(shè)備。這些服務(wù)資源包括網(wǎng)絡(luò)帶寬日裙，文件系統(tǒng)空間容量吹艇，開放的進(jìn)程或者允許的連接。這種攻擊會(huì)導(dǎo)致資源的匱乏昂拂，無論計(jì)算機(jī)的處理速度多快受神、內(nèi)存容量多大、網(wǎng)絡(luò)帶寬的速度多快都無法避免這種攻擊帶來的后果格侯。

最直接的例子就是前些年春運(yùn)期間的12306,當(dāng)訪問用戶過多時(shí)服務(wù)器處理不過來,只能宕機(jī).

這種攻擊方式的危害不僅在于會(huì)讓過載的服務(wù)器宕機(jī),更會(huì)由于異常的流量涌入導(dǎo)致服務(wù)器ip被運(yùn)營商屏蔽,導(dǎo)致一段時(shí)間內(nèi)該ip下的所有服務(wù)器都無法使用.

防范:

這種方式是針對(duì)服務(wù)器本體的,一些云服務(wù)提供商推出了一些容災(zāi)措施,號(hào)稱可以扛住XXGB的攻擊,實(shí)際上也只是分布式容災(zāi)而已.如果有人下血本使用DDoS來攻擊你的服務(wù)器,基本上是沒有什么辦法的(攤手).

4.SQL注入

說明:

所謂SQL注入鼻听，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請(qǐng)求的查詢字符串财著，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令。具體來說撑碴，它是利用現(xiàn)有應(yīng)用程序撑教，將（惡意的）SQL命令注入到后臺(tái)數(shù)據(jù)庫引擎執(zhí)行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個(gè)存在安全漏洞的網(wǎng)站上的數(shù)據(jù)庫醉拓，而不是按照設(shè)計(jì)者意圖去執(zhí)行SQL語句伟姐。

不得不說這種方式實(shí)在很low,但是近些年因此翻車的各大網(wǎng)站也是比比皆是.
曾經(jīng)有人這樣評(píng)價(jià):這種攻擊方式就跟把你家大門踹開進(jìn)去偷東西一樣low.

不多做評(píng)價(jià)了,隨便搜了個(gè)栗子:

某個(gè)網(wǎng)站的登錄驗(yàn)證的SQL查詢代碼為：

strSQL = "SELECT * FROM users WHERE (name
= '" +
userName + "') and (pw
= '"+
passWord +"');"

惡意填入

userName = "1' OR '1'='1"; 與passWord = "1' OR '1'='1";

將導(dǎo)致原本的SQL字符串被填為

strSQL = "SELECT * FROM users WHERE (name
= '1' OR '1'='1') and (pw = '1' OR '1'='1');"

也就是實(shí)際上運(yùn)行的SQL命令會(huì)變成下面這樣的

strSQL = "SELECT * FROM users;"

因此達(dá)到無賬號(hào)密碼，亦可登錄網(wǎng)站亿卤。所以SQL注入攻擊被俗稱為黑客的填空游戲愤兵。

防范:

SQL注入的本質(zhì)在于它是一條語言而不是一個(gè)特定格式的API,它只能作為一條語句被整體執(zhí)行.也就是說,輸入的內(nèi)容可以直接進(jìn)入SQL,一個(gè)元素就可以變成一條語句,那么SQL注入就無法防止.
所以,杜絕SQL語句的動(dòng)態(tài)拼裝可以解決絕大多數(shù)的問題.

• 1.使用參數(shù)化查詢;
• 2.使用詞法分析;
• 3.使用noSQL;

5.停用js

說明:

假如由于某些原因(多半由于技術(shù)過菜),授權(quán)驗(yàn)證的操作都在前端(大多是js)完成,那么直接禁用掉js就可以繞開這部分的驗(yàn)證步驟...

如果上一種攻擊方式是踹大門偷東西,那么這種方式差不多就是點(diǎn)了一把火把房子燒了然后進(jìn)去拿東西...
我一度覺得這種攻擊方式甚至不能被稱為攻擊,也許能算的上bug的一種.

隨手寫個(gè)栗子:

var auth = function () {
    if (!user) {
        alert(' authorize denied!! ');
       // do something rejection
    }
}

可見當(dāng)user為false時(shí),該函數(shù)會(huì)返回執(zhí)行一系列拒絕操作.但是當(dāng)js被禁用后,顯然拒絕操作不會(huì)被執(zhí)行.

防范:

低級(jí)問題,無需多言.

6.文件上傳

說明:

文件上傳攻擊是指攻擊者利用WEB應(yīng)用對(duì)上傳文件過濾不嚴(yán),導(dǎo)致可以上傳應(yīng)用程序定義類型范圍之外的文件到Web服務(wù)器.比如可以上傳一個(gè)網(wǎng)頁木馬,如果存放上傳文件的目錄剛好有執(zhí)行腳本的權(quán)限,那么攻擊者就可以直接得到一個(gè)WebShell.

由于服務(wù)器端沒有對(duì)用戶上傳的文件進(jìn)行正確的處理,導(dǎo)致攻擊者可以向某個(gè)可通過Web訪問的目錄上傳惡意文件,并且該文件可以被Web服務(wù)器解析執(zhí)行.

攻擊者要想成功實(shí)施文件上傳攻擊,必須要滿足以下三個(gè)條件:

• 1.可以上傳任意腳本文件,且上傳的文件能夠被Web服務(wù)器解析執(zhí)行,具體來說就是存放上傳文件的目錄要有執(zhí)行腳本的權(quán)限.
• 2.用戶能夠通過Web訪問這個(gè)文件,如果文件上傳后,不能通過Web訪問,那么也不能成功實(shí)施攻擊.
• 3.要知道文件上傳到服務(wù)器后的存放路徑和文件名稱,因?yàn)樵S多Web應(yīng)用都會(huì)修改上傳文件的文件名稱,那么這時(shí)就需要結(jié)合其他漏洞去獲取到這些信息,如果不知道上傳文件的存放路徑和文件名稱,即使你上傳了也無法訪問.

防范:

這種攻擊方式也是很基礎(chǔ)的,但是其危害性不容小覷.由于其局限性較強(qiáng),所以可以針對(duì)其發(fā)動(dòng)條件逐條排查:

• 1.檢查上傳文件的格式是否符合要求:
  前端的格式驗(yàn)證可能被某些工具繞過,所以最可靠的方式是后端以白名單的形式進(jìn)行驗(yàn)證.
• 2.檢查文件名和Http content-type報(bào)頭:
  強(qiáng)化上一條的檢查內(nèi)容,檢查文件名中的%00等截?cái)喾?阻止可能混淆在文件名中的可能性.檢查請(qǐng)求報(bào)頭和文件大小,對(duì)異常情況做出反應(yīng).
• 3.增加文件的訪問權(quán)限:
  針對(duì)不同的業(yè)務(wù)需求,適當(dāng)提升部分文件的請(qǐng)求權(quán)限,使得該文件無法被普通用戶訪問或執(zhí)行.
• 4.使用隨機(jī)訪問路徑:
  借鑒分布式的設(shè)計(jì)理念,在文件訪問路徑中混入隨機(jī)參數(shù),避免文件被簡(jiǎn)單的追蹤到.
• 5.定期篩查文件,避免漏網(wǎng)之魚.