WEB安全漏洞

概述

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

[[265900]]

 

漏洞分類

 

01.SQL注入

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

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

 

SQL 防護

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

02.XSS 

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

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

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

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

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

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

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

XSS防御

• 輸入檢查

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

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

• 對輸出轉義

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

為了對抗XSS,在HtmlEncode中至少轉換以下字符：

< 轉成 <

> 轉成 >

& 轉成 &

“ 轉成 "

‘ 轉成 '

XSS防護—Spring MVC

a)項目級過濾

<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ā)送各種請求。攻擊者只要借助少許的社會工程學的詭計，例如通過 QQ 等聊天軟件發(fā)送的鏈接(有些還偽裝成短域名，用戶無法分辨)，攻擊者就能迫使 Web 應用的用戶去執(zhí)行攻擊者預設的操作。例如，當用戶登錄網(wǎng)絡銀行去查看其存款余額，在他沒有退出時，就點擊了一個 QQ 好友發(fā)來的鏈接，那么該用戶銀行帳戶中的資金就有可能被轉移到攻擊者指定的帳戶中。

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

CSRF流程

角色

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

流程

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

 

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

 

3.在用戶User被誘導訪問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ā)出，由于瀏覽器訪問時帶上用戶的Cookie，因此WebA會響應瀏覽器的請求，如此一來，攻擊網(wǎng)站W(wǎng)ebB就達到了模擬用戶操作的目的。

 

CSRF攻擊防護

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

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

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

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

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

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

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

04.DDos

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

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

 

網(wǎng)絡層DDos攻擊

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

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

網(wǎng)絡層DDos防御

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

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

應用層 DDoS

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

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

應用層DDos防御

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

應用層的防御有時比網(wǎng)絡層的更難，因為導致應用層被dos攻擊的因素非常多，有時往往是因為程序員的失誤，導致某個頁面加載需要消耗大量資源，有時是因為中間件配置不當?shù)鹊取６鴳脤覦Dos防御的核心就是區(qū)分人與機器(爬蟲)，因為大量的請求不可能是人為的，肯定是機器構造的。因此如果能有效的區(qū)分人與爬蟲行為，則可以很好地防御此攻擊。

05.目錄遍歷漏洞

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

防御措施

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

06.業(yè)務安全

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

賬戶信息安全

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

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

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

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

業(yè)務流程安全

順序執(zhí)行缺陷

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

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

提交新密碼時修改用戶ID為其他ID

跳過驗證步驟、找回方式，直接到設置新密碼頁面

業(yè)務接口安全

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

07.編程規(guī)范

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

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

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

08.總結

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

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

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

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

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

對于URL上攜帶的信息，要謹慎使用。

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

作者介紹

 

李偉山

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

座右銘：Fake it until you make it。