WEB安全漏洞

概述

Web應(yīng)用是指采用B/S架構(gòu)、通過HTTP/HTTPS協(xié)議提供服務(wù)的統(tǒng)稱。隨著互聯(lián)網(wǎng)的廣泛使用，Web應(yīng)用已經(jīng)融入到日常生活中的各個(gè)方面：網(wǎng)上購物、網(wǎng)絡(luò)銀行應(yīng)用、證券股票交易、政府行政審批等等。在這些Web訪問中，大多數(shù)應(yīng)用不是靜態(tài)的網(wǎng)頁瀏覽，而是涉及到服務(wù)器側(cè)的動(dòng)態(tài)處理。此時(shí)，如果Java、PHP、ASP等程序語言的編程人員的安全意識不足，對程序參數(shù)輸入等檢查不嚴(yán)格等，會導(dǎo)致Web應(yīng)用安全問題層出不窮。

[[265900]]

 

漏洞分類

 

01.SQL注入

SQL 注入漏洞(SQL Injection)是 Web 開發(fā)中最常見的一種安全漏洞?？梢杂盟鼇韽臄?shù)據(jù)庫獲取敏感信息，或者利用數(shù)據(jù)庫的特性執(zhí)行添加用戶，導(dǎo)出文件等一系列惡意操作，甚至有可能獲取數(shù)據(jù)庫乃至系統(tǒng)用戶權(quán)限。

而造成 SQL 注入的原因是因?yàn)槌绦驔]有有效的轉(zhuǎn)義過濾用戶的輸入，使不法分子成功的向服務(wù)器提交惡意的 SQL 查詢代碼，程序在接收后錯(cuò)誤的將輸入作為查詢語句的一部分執(zhí)行，導(dǎo)致原始的查詢邏輯被改變，額外的執(zhí)行了惡意代碼。很多 Web 開發(fā)者沒有意識到 SQL 查詢是可以被篡改的，從而把 SQL 查詢當(dāng)作可信任的命令。殊不知，SQL 查詢是可以繞開訪問控制，從而繞過身份驗(yàn)證和權(quán)限檢查的。更有甚者，有可能通過 SQL 查詢?nèi)ミ\(yùn)行主機(jī)系統(tǒng)級的命令。

 

SQL 防護(hù)

1. 不要信任用戶的輸入: 對用戶的輸入進(jìn)行校驗(yàn)，可以通過正則表達(dá)式，或限制長度;對進(jìn)入數(shù)據(jù)庫的特殊字符('，"，\，<，>，&，*，; 等)進(jìn)行轉(zhuǎn)義處理，或編碼轉(zhuǎn)換。
2. 不要使用動(dòng)態(tài)拼裝 SQL，可以使用參數(shù)化的 SQL 或者直接使用存儲過程進(jìn)行數(shù)據(jù)查詢存取。
3. 不要使用管理員權(quán)限的數(shù)據(jù)庫連接，為每個(gè)應(yīng)用使用單獨(dú)的權(quán)限有限的數(shù)據(jù)庫連接。
4. 不要把機(jī)密信息直接存放，加密或者 hash 掉密碼和敏感的信息。
5. 嚴(yán)格限制Web應(yīng)用的數(shù)據(jù)庫的操作權(quán)限，給此用戶提供僅僅能夠滿足其工作的權(quán)限，從而減少對數(shù)據(jù)庫的危害
6. 在應(yīng)用發(fā)布之前建議使用專業(yè)的 SQL 注入檢測工具進(jìn)行檢測，以及時(shí)修補(bǔ)被發(fā)現(xiàn)的 SQL 注入漏洞。網(wǎng)上有很多這方面的開源工具，例如 sqlmap、SQLninja 等。
7. 不要過于細(xì)化返回的錯(cuò)誤信息，如果目的是方便調(diào)試，就去使用后端日志，不要在接口上過多的暴露出錯(cuò)信息，畢竟真正的用戶不關(guān)心太多的技術(shù)細(xì)節(jié)，只要話術(shù)合理就行。
8. 當(dāng)采用MyBatis執(zhí)行sql語句時(shí)，存在模糊查詢的方法。存在表達(dá)式${} 和 #{}

02.XSS 

XSS 又稱為 CSS，全程為 Cross-site script，為了和 CSS 層疊樣式表區(qū)分所以取名為 XSS，是 Web 程序中常見的漏洞。

其原理是向有 XSS 漏洞的網(wǎng)站中輸入惡意的 HTML 代碼，當(dāng)其它用戶瀏覽該網(wǎng)站時(shí)候，該段 HTML 代碼會自動(dòng)執(zhí)行，從而達(dá)到目的，如盜取用戶的 Cookie，破壞頁面結(jié)構(gòu)，重定向到其它網(wǎng)站等。XSS 的千變?nèi)f化，但還是可以大致細(xì)分為幾種類型。

XSS分為三類：反射型XSS、存儲型XSS、DOM Based XSS。

反射型XSS也被稱為非持久性XSS,把XSS的Payload寫在URL中，通過瀏覽器直接“反射”給用戶。通常需要誘使用戶點(diǎn)擊某個(gè)惡意鏈接，才能成功。

存儲型XSS又被稱為持久性XSS,會把黑客輸入的惡意腳本存儲在服務(wù)器的數(shù)據(jù)庫中。一個(gè)常見的場景就是黑客寫下一篇包含惡意JavaScript腳本的博客文章，當(dāng)其他用戶瀏覽這篇文章時(shí)，惡意的JavaScript代碼將會執(zhí)行。

DOM Based XSS 是一種利用前端代碼漏洞進(jìn)行方式。前面的反射型XSS與存儲型XSS雖然惡意腳本的存放位置不同，但其本質(zhì)都是利用后端代碼的漏洞。

反射型和存儲型xss是服務(wù)器端代碼漏洞造成的，payload在響應(yīng)頁面中，DOM Based中，payload不在服務(wù)器發(fā)出的HTTP響應(yīng)頁面中，當(dāng)客戶端腳本運(yùn)行時(shí)(渲染頁面時(shí))，payload才會加載到腳本中執(zhí)行。

XSS防御

• 輸入檢查

常見的Web漏洞，如XSS、SQL注入等，都要求構(gòu)造一些特殊的字符串，而這些字符串是一般用戶不會用到的，所以進(jìn)行輸入檢查就很有必要了。

輸入檢查可以在用戶輸入的格式檢查中進(jìn)行。很多網(wǎng)站的用戶名都要求是字母及數(shù)字的組合如“1234qwer”，其實(shí)也能過濾一部分的XSS和SQL注入。但是，這種在客戶端的限制很容易被繞過，用JavaScript或一些請求工具，直接構(gòu)造請求，想網(wǎng)站注入XSS或者SQL。所以，除了在客戶端進(jìn)行格式檢查，往往還需要在后端進(jìn)行二次檢查。客戶端的檢查主要作用是阻擋大部分誤操作的正常用戶，從而節(jié)約服務(wù)器資源。

• 對輸出轉(zhuǎn)義

在輸出數(shù)據(jù)之前對潛在的威脅的字符進(jìn)行編碼、轉(zhuǎn)義是防御XSS十分有效的措施。

為了對抗XSS,在HtmlEncode中至少轉(zhuǎn)換以下字符：

< 轉(zhuǎn)成 <

> 轉(zhuǎn)成 >

& 轉(zhuǎn)成 &

“ 轉(zhuǎn)成 "

‘ 轉(zhuǎn)成 '

XSS防護(hù)—Spring MVC

a)項(xiàng)目級過濾

<context-param> 
<param-name>defaultHtmlEscape</param-name> 
<param-value>true</param-value> 
</context-param> 

b)頁面級過濾

<spring:htmlEscape defaultHtmlEscape=”true” /> 

c)表單元素級過濾

在form元素中添加

<form:form htmlEscape=“true”>或 
<form:input path=”someFormField” htmlEscape=”true” /> 

03.CSRF

CSRF(Cross-Site Request Forgery)，中文名稱：跨站請求偽造攻擊那么 CSRF 到底能夠干嘛呢?你可以這樣簡單的理解：攻擊者可以盜用你的登陸信息，以你的身份模擬發(fā)送各種請求。攻擊者只要借助少許的社會工程學(xué)的詭計(jì)，例如通過 QQ 等聊天軟件發(fā)送的鏈接(有些還偽裝成短域名，用戶無法分辨)，攻擊者就能迫使 Web 應(yīng)用的用戶去執(zhí)行攻擊者預(yù)設(shè)的操作。例如，當(dāng)用戶登錄網(wǎng)絡(luò)銀行去查看其存款余額，在他沒有退出時(shí)，就點(diǎn)擊了一個(gè) QQ 好友發(fā)來的鏈接，那么該用戶銀行帳戶中的資金就有可能被轉(zhuǎn)移到攻擊者指定的帳戶中。

所以遇到 CSRF 攻擊時(shí)，將對終端用戶的數(shù)據(jù)和操作指令構(gòu)成嚴(yán)重的威脅。當(dāng)受攻擊的終端用戶具有管理員帳戶的時(shí)候，CSRF 攻擊將危及整個(gè) Web 應(yīng)用程序。

CSRF流程

角色

• 正常瀏覽網(wǎng)頁的用戶：User
• 正規(guī)的但是具有漏洞的網(wǎng)站：WebA
• 利用CSRF進(jìn)行攻擊的網(wǎng)站：WebB

流程

1.用戶登錄、瀏覽并信任正規(guī)網(wǎng)站W(wǎng)ebA，同時(shí)，WebA通過用戶的驗(yàn)證并在用戶的瀏覽器中產(chǎn)生Cookie。

 

2.攻擊者WebB通過在WebA中添加圖片鏈接等方式誘導(dǎo)用戶User訪問網(wǎng)站W(wǎng)ebB。

 

3.在用戶User被誘導(dǎo)訪問WebB后，WebB會利用用戶User的瀏覽器訪問第三方網(wǎng)站W(wǎng)ebA，并發(fā)出操作請求。

 

4.用戶User的瀏覽器根據(jù)WebB的要求，帶著步驟一中產(chǎn)生的Cookie訪問WebA。

 

5.網(wǎng)站W(wǎng)ebA接收到用戶瀏覽器的請求，WebA無法分辨請求由何處發(fā)出，由于瀏覽器訪問時(shí)帶上用戶的Cookie，因此WebA會響應(yīng)瀏覽器的請求，如此一來，攻擊網(wǎng)站W(wǎng)ebB就達(dá)到了模擬用戶操作的目的。

 

CSRF攻擊防護(hù)

CSRF 的防御可以從服務(wù)端和客戶端兩方面著手，防御效果是從服務(wù)端著手效果比較好，現(xiàn)在一般的 CSRF 防御也都在服務(wù)端進(jìn)行。服務(wù)端的預(yù)防 CSRF 攻擊的方式方法有多種，但思路上都是差不多的，主要從以下兩個(gè)方面入手：

• 正確使用 GET，POST 請求和 cookie
• 在非 GET 請求中增加 token

一般而言，普通的 Web 應(yīng)用都是以 GET、POST 請求為主，還有一種請求是 cookie 方式。我們一般都是按照如下規(guī)則設(shè)計(jì)應(yīng)用的請求：

• GET 請求常用在查看，列舉，展示等不需要改變資源屬性的時(shí)候(數(shù)據(jù)庫 query 查詢的時(shí)候)
• POST 請求常用在 From 表單提交，改變一個(gè)資源的屬性或者做其他一些事情的時(shí)候(數(shù)據(jù)庫有 insert、update、delete 的時(shí)候)

當(dāng)正確的使用了 GET 和 POST 請求之后，剩下的就是在非 GET 方式的請求中增加隨機(jī)數(shù)，這個(gè)大概有三種方式來進(jìn)行：

• 為每個(gè)用戶生成一個(gè) cookie token，所有表單都包含同一個(gè)偽隨機(jī)值，這種方案最簡單，因?yàn)楣粽卟荒塬@得第三方的 cookie(理論上)，所以表單中的數(shù)據(jù)也就構(gòu)造失敗，但是由于用戶的 cookie 很容易由于網(wǎng)站的 XSS 漏洞而被盜取，所以這個(gè)方案必須要在沒有 XSS 的情況下才安全。
• 每個(gè) POST 請求使用驗(yàn)證碼，這個(gè)方案算較好，但是需要用戶多次輸入驗(yàn)證碼，用戶體驗(yàn)比較差，所以不適合在業(yè)務(wù)中大量運(yùn)用。
• 渲染表單的時(shí)候，為每一個(gè)表單包含一個(gè) csrfToken，提交表單的時(shí)候，帶上 csrfToken，然后在后端做 csrfToken 驗(yàn)證。

CSRF 的防御可以根據(jù)應(yīng)用場景的不同自行選擇。CSRF 的防御工作確實(shí)會在正常業(yè)務(wù)邏輯的基礎(chǔ)上帶來很多額外的開發(fā)量，但是這種工作量是值得的，畢竟用戶隱私以及財(cái)產(chǎn)安全是產(chǎn)品最基礎(chǔ)的根本。

04.DDos

DDos又叫分布式拒絕服務(wù)，全稱Distributed Denial of Service，利用DDos造成的攻擊稱為拒絕服務(wù)攻擊，其原理就是利用大量的請求造成資源過載，導(dǎo)致服務(wù)不可用。

DDos攻擊從層次上可分為網(wǎng)絡(luò)層攻擊與應(yīng)用層攻擊，從攻擊手法上可分為快型流量攻擊與慢型流量攻擊，但其原理都是造成資源過載，導(dǎo)致服務(wù)不可用。

 

網(wǎng)絡(luò)層DDos攻擊

網(wǎng)絡(luò)層DDos攻擊包括SYN flood、UDP flood、ICMP flood等。

• SYN flood攻擊：SYN flood攻擊主要利用了TCP三次握手過程中的bug，我們知道TCP三次握手過程是要建立連接的雙方發(fā)送SYN，SYN+ACK，ACK數(shù)據(jù)包，而當(dāng)攻擊方隨意構(gòu)造源ip去發(fā)送SYN包時(shí)，服務(wù)器返回的SYN+ACK就不能得到應(yīng)答(因?yàn)閕p是隨意構(gòu)造的)，此時(shí)服務(wù)器就會嘗試重新發(fā)送，并且會有至少30s的等待時(shí)間，導(dǎo)致資源飽和服務(wù)不可用，此攻擊屬于慢型dos攻擊。
• UDP flood攻擊：由于udp是一種無連接的協(xié)議，因此攻擊者可以偽造大量的源IP地址去發(fā)送udp包，此種攻擊屬于大流量攻擊。正常應(yīng)用情況下，UDP包雙向流量會基本相等，因此在消耗對方資源的時(shí)候也在消耗自己的資源。
• ICMP flood攻擊：此攻擊屬于大流量攻擊，其原理就是不斷發(fā)送不正常的ICMP包(所謂不正常就是ICMP包內(nèi)容很大)，導(dǎo)致目標(biāo)帶寬被占用，但其本身資源也會被消耗。并且目前很多服務(wù)器都是禁ping的(在防火墻在可以屏蔽icmp包)，因此這種方式已經(jīng)落伍。

網(wǎng)絡(luò)層DDos防御

• 網(wǎng)絡(luò)架構(gòu)上做好優(yōu)化，采用負(fù)載均衡分流。
• 添加抗DDos設(shè)備，流量清洗。
• 限制單ip請求頻率。
• 防火墻等防護(hù)設(shè)置禁止icmp包等
• 認(rèn)真檢查網(wǎng)絡(luò)設(shè)備和主機(jī)/服務(wù)器系統(tǒng)的日志。只要日志出現(xiàn)漏洞或是時(shí)間變更,那這臺機(jī)器就可能遭到了攻擊。
• 限制在防火墻外與網(wǎng)絡(luò)文件共享。這樣會給黑客截取系統(tǒng)文件的機(jī)會，主機(jī)的信息暴露給黑客，無疑是給了對方機(jī)會。
• 加錢堆機(jī)器

網(wǎng)絡(luò)層的DDos攻擊究其本質(zhì)其實(shí)是無法防御的，我們能做得就是不斷優(yōu)化自身的網(wǎng)絡(luò)架構(gòu)，以及提升網(wǎng)絡(luò)帶寬。

應(yīng)用層 DDoS

應(yīng)用層 DDoS 攻擊不是發(fā)生在網(wǎng)絡(luò)層，是發(fā)生在 TCP 建立握手成功之后，應(yīng)用程序處理請求的時(shí)候，現(xiàn)在很多常見的 DDoS 攻擊都是應(yīng)用層攻擊。應(yīng)用層攻擊千變?nèi)f化，目的就是在網(wǎng)絡(luò)應(yīng)用層耗盡你的帶寬，下面列出集中典型的攻擊類型。

• CC 攻擊：CC 攻擊的原理，就是針對消耗資源比較大的頁面不斷發(fā)起不正常的請求，導(dǎo)致資源耗盡。因此在發(fā)送 CC 攻擊前，我們需要尋找加載比較慢，消耗資源比較多的網(wǎng)頁，比如需要查詢數(shù)據(jù)庫的頁面、讀寫硬盤文件的等。通過 CC 攻擊，使用爬蟲對某些加載需要消耗大量資源的頁面發(fā)起 HTTP 請求。
• DNS Flood 攻擊：采用的方法是向被攻擊的服務(wù)器發(fā)送大量的域名解析請求，通常請求解析的域名是隨機(jī)生成或者是網(wǎng)絡(luò)世界上根本不存在的域名，被攻擊的DNS 服務(wù)器在接收到域名解析請求的時(shí)候首先會在服務(wù)器上查找是否有對應(yīng)的緩存，如果查找不到并且該域名無法直接由服務(wù)器解析的時(shí)候，DNS 服務(wù)器會向其上層 DNS 服務(wù)器遞歸查詢域名信息。域名解析的過程給服務(wù)器帶來了很大的負(fù)載，每秒鐘域名解析請求超過一定的數(shù)量就會造成 DNS 服務(wù)器解析域名超時(shí)。
• HTTP 慢速連接攻擊：針對 HTTP 協(xié)議，先建立起 HTTP 連接，設(shè)置一個(gè)較大的 Conetnt-Length，每次只發(fā)送很少的字節(jié)，讓服務(wù)器一直以為 HTTP 頭部沒有傳輸完成，這樣連接一多就很快會出現(xiàn)連接耗盡。

應(yīng)用層DDos防御

• 判斷User-Agent字段(不可靠，因?yàn)榭梢噪S意構(gòu)造)
• 網(wǎng)頁中鑲嵌js代碼(不可靠，因?yàn)榕老x也可攜帶瀏覽器引擎，或者執(zhí)行js代碼)
• 針對ip+cookie，限制訪問頻率(由于cookie可以更改，ip可以使用代理，或者肉雞，也不可靠)
• 關(guān)閉apache連接數(shù)等，合理配置中間件，緩解ddos攻擊。
• 頁面中添加驗(yàn)證碼，比如搜索數(shù)據(jù)庫時(shí)。
• 編寫代碼時(shí)，盡量實(shí)現(xiàn)優(yōu)化，并合理使用緩存技術(shù)，減少數(shù)據(jù)庫的讀取操作。

應(yīng)用層的防御有時(shí)比網(wǎng)絡(luò)層的更難，因?yàn)閷?dǎo)致應(yīng)用層被dos攻擊的因素非常多，有時(shí)往往是因?yàn)槌绦騿T的失誤，導(dǎo)致某個(gè)頁面加載需要消耗大量資源，有時(shí)是因?yàn)橹虚g件配置不當(dāng)?shù)鹊?。而?yīng)用層DDos防御的核心就是區(qū)分人與機(jī)器(爬蟲)，因?yàn)榇罅康恼埱蟛豢赡苁侨藶榈模隙ㄊ菣C(jī)器構(gòu)造的。因此如果能有效的區(qū)分人與爬蟲行為，則可以很好地防御此攻擊。

05.目錄遍歷漏洞

目錄遍歷漏洞成因：服務(wù)器端，接收請求中傳來的文件名稱，在服務(wù)器端拼湊成文件的絕對路徑，并且用輸出流下載。

防御措施

• 文件ID使用隨機(jī)數(shù)命名
• 文件路徑保存至數(shù)據(jù)庫，用戶提交文件對應(yīng)ID下載文件。
• 下載文件之前做權(quán)限判斷。
• 記錄文件下載日志。

06.業(yè)務(wù)安全

在Web系統(tǒng)中，除了常規(guī)的如SQL，XSS，CSRF、Ddos等web漏洞外，更重要的是其業(yè)務(wù)上的安全。

賬戶信息安全

賬戶是一個(gè)系統(tǒng)的入口，關(guān)系到用戶最直接的利益，因而賬戶的安全在業(yè)務(wù)安全中占及其重要的地位。賬戶體系分多個(gè)層次，每個(gè)環(huán)節(jié)的漏洞，都將給用戶帶來極大的損失。

業(yè)務(wù)數(shù)據(jù)安全

金額數(shù)據(jù)篡改：抓包修改金額等字段，例如在支付頁面抓取請求中商品的金額字段，修改成任意數(shù)額的金額并提交，查看能否以修改后的金額數(shù)據(jù)完成業(yè)務(wù)流程。

商品數(shù)量篡改：抓包修改商品數(shù)量等字段，將請求中的商品數(shù)量修改成任意數(shù)額，如負(fù)數(shù)并提交，查看能否以修改后的數(shù)量完成業(yè)務(wù)流程。

業(yè)務(wù)流程安全

順序執(zhí)行缺陷

部分網(wǎng)站邏輯可能是先A過程后B過程然后C過程D過程。

用戶控制著他們給應(yīng)用程序發(fā)送的每一個(gè)請求，因此能夠按照任何順序進(jìn)行訪問。于是，用戶就從B直接進(jìn)入了D過程，就繞過了C。如果C是支付過程，那么用戶就繞過了支付過程而買到了一件商品。如果C是驗(yàn)證過程，就會繞過驗(yàn)證直接進(jìn)入網(wǎng)站程序了。

提交新密碼時(shí)修改用戶ID為其他ID

跳過驗(yàn)證步驟、找回方式，直接到設(shè)置新密碼頁面

業(yè)務(wù)接口安全

在短信、郵件調(diào)用業(yè)務(wù)或生成業(yè)務(wù)數(shù)據(jù)環(huán)節(jié)中(類：短信驗(yàn)證碼，郵件驗(yàn)證碼，訂單生成，評論提交等)，對其業(yè)務(wù)環(huán)節(jié)進(jìn)行調(diào)用(重放)測試。如果業(yè)務(wù)經(jīng)過調(diào)用(重放)后被多次生成有效的業(yè)務(wù)或數(shù)據(jù)結(jié)果

07.編程規(guī)范

一切輸入都是有害的!!!輸出也不安全!

輸入：傳參，cookie、session、http header、數(shù)據(jù)庫……

輸出：異常信息、敏感信息、xss

08.總結(jié)

程序猿們能夠管理好代碼隱私，注意代碼安全問題，比如不要將產(chǎn)品的含有敏感信息的代碼放到第三方外部站點(diǎn)或者暴露給外部用戶，尤其是前端代碼，私鑰類似的保密性的東西不要直接輸出在代碼里或者頁面中。也許還有很多值得注意的點(diǎn)，但是歸根結(jié)底還是繃住安全那根弦，對待每一行代碼都要多多推敲。

開發(fā)時(shí)要提防用戶產(chǎn)生的內(nèi)容，要對用戶輸入的信息進(jìn)行層層檢測

要注意對用戶的輸出內(nèi)容進(jìn)行過濾(進(jìn)行轉(zhuǎn)義等)

重要的內(nèi)容記得要加密傳輸(無論是利用https也好，自己加密也好)

get請求與post請求，要嚴(yán)格遵守規(guī)范，不要混用，不要將一些危險(xiǎn)的提交使用jsonp完成。

對于URL上攜帶的信息，要謹(jǐn)慎使用。

心中時(shí)刻記著，自己的網(wǎng)站哪里可能有危險(xiǎn)。

作者介紹

 

李偉山

江湖人稱：山哥，85年生產(chǎn)，IT屆的小學(xué)生。享米高級技術(shù)總監(jiān)，曾經(jīng)在華為、阿里巴巴任職。

座右銘：Fake it until you make it。