漏洞分類
01.SQL注入
SQL 注入漏洞(SQL Injection)是 Web 開發(fā)中最常見的一種安全漏洞�？梢杂盟鼇韽臄�(shù)據(jù)庫獲取敏感信息，或者利用數(shù)據(jù)庫的特性執(zhí)行添加用戶，導(dǎo)出文件等一系列惡意操作，甚至有可能獲取數(shù)據(jù)庫乃至系統(tǒng)用戶最高權(quán)限。
而造成 SQL 注入的原因是因為程序沒有有效的轉(zhuǎn)義過濾用戶的輸入，使攻擊者成功的向服務(wù)器提交惡意的 SQL 查詢代碼，程序在接收后錯誤的將攻擊者的輸入作為查詢語句的一部分執(zhí)行，導(dǎo)致原始的查詢邏輯被改變，額外的執(zhí)行了攻擊者精心構(gòu)造的惡意代碼。很多 Web 開發(fā)者沒有意識到 SQL 查詢是可以被篡改的，從而把 SQL 查詢當(dāng)作可信任的命令。殊不知，SQL 查詢是可以繞開訪問控制，從而繞過身份驗證和權(quán)限檢查的。更有甚者，有可能通過 SQL 查詢?nèi)ミ\行主機系統(tǒng)級的命令。
SQL防護
不要信任用戶的輸入: 對用戶的輸入進行校驗，可以通過正則表達式，或限制長度;對進入數(shù)據(jù)庫的特殊字符('，"，\，<，>，&，*，; 等)進行轉(zhuǎn)義處理，或編碼轉(zhuǎn)換。
不要使用動態(tài)拼裝 SQL，可以使用參數(shù)化的 SQL 或者直接使用存儲過程進行數(shù)據(jù)查詢存取。
不要使用管理員權(quán)限的數(shù)據(jù)庫連接，為每個應(yīng)用使用單獨的權(quán)限有限的數(shù)據(jù)庫連接。
不要把機密信息直接存放，加密或者 hash 掉密碼和敏感的信息。
嚴(yán)格限制Web應(yīng)用的數(shù)據(jù)庫的操作權(quán)限，給此用戶提供僅僅能夠滿足其工作的最低權(quán)限，從而最大限度的減少注入攻擊對數(shù)據(jù)庫的危害
在應(yīng)用發(fā)布之前建議使用專業(yè)的 SQL 注入檢測工具進行檢測，以及時修補被發(fā)現(xiàn)的 SQL 注入漏洞。網(wǎng)上有很多這方面的開源工具，例如 sqlmap、SQLninja 等。
不要過于細(xì)化返回的錯誤信息，如果目的是方便調(diào)試，就去使用后端日志，不要在接口上過多的暴露出錯信息，畢竟真正的用戶不關(guān)心太多的技術(shù)細(xì)節(jié)，只要話術(shù)合理就行。
當(dāng)采用MyBatis執(zhí)行sql語句時，存在模糊查詢的方法。存在表達式${} 和 #{}
02.XSS 攻擊
XSS 又稱為 CSS，全程為 Cross-site script，跨站腳本攻擊，為了和 CSS 層疊樣式表區(qū)分所以取名為 XSS，是 Web 程序中常見的漏洞。
其原理是攻擊者向有 XSS 漏洞的網(wǎng)站中輸入惡意的 HTML 代碼，當(dāng)其它用戶瀏覽該網(wǎng)站時候，該段 HTML 代碼會自動執(zhí)行，從而達到攻擊的目的，如盜取用戶的 Cookie，破壞頁面結(jié)構(gòu)，重定向到其它網(wǎng)站等。XSS 的攻擊方式千變?nèi)f化，但還是可以大致細(xì)分為幾種類型。
根據(jù)攻擊的方式，XSS攻擊可以分為三類：反射型XSS、存儲型XSS、DOM Based XSS。
反射型XSS也被稱為非持久性XSS,這種攻擊方式把XSS的Payload寫在URL中，通過瀏覽器直接“反射”給用戶。這種攻擊方式通常需要誘使用戶點擊某個惡意鏈接，才能攻擊成功。
存儲型XSS又被稱為持久性XSS,會把黑客輸入的惡意腳本存儲在服務(wù)器的數(shù)據(jù)庫中。當(dāng)其他用戶瀏覽頁面包含這個惡意腳本的頁面，用戶將會受到黑客的攻擊。一個常見的場景就是黑客寫下一篇包含惡意java script腳本的博客文章，當(dāng)其他用戶瀏覽這篇文章時，惡意的java script代碼將會執(zhí)行。
DOM Based XSS 是一種利用前端代碼漏洞進行攻擊的攻擊方式。前面的反射型XSS與存儲型XSS雖然惡意腳本的存放位置不同，但其本質(zhì)都是利用后端代碼的漏洞。
反射型和存儲型xss是服務(wù)器端代碼漏洞造成的，payload在響應(yīng)頁面中，DOM Based中，payload不在服務(wù)器發(fā)出的HTTP響應(yīng)頁面中，當(dāng)客戶端腳本運行時(渲染頁面時)，payload才會加載到腳本中執(zhí)行。
XSS防御
常見的Web漏洞，如XSS、SQL注入等，都要求攻擊者構(gòu)造一些特殊的字符串，而這些字符串是一般用戶不會用到的，所以進行輸入檢查就很有必要了。
輸入檢查可以在用戶輸入的格式檢查中進行。很多網(wǎng)站的用戶名都要求是字母及數(shù)字的組合如“1234qwer”，其實也能過濾一部分的XSS和SQL注入。但是，這種在客戶端的限制很容易被繞過，攻擊者可以用java script或一些請求工具，直接構(gòu)造請求，想網(wǎng)站注入XSS或者SQL。所以，除了在客戶端進行格式檢查，往往還需要在后端進行二次檢查。客戶端的檢查主要作用是阻擋大部分誤操作的正常用戶，從而節(jié)約服務(wù)器資源。
在輸出數(shù)據(jù)之前對潛在的威脅的字符進行編碼、轉(zhuǎn)義是防御XSS攻擊十分有效的措施。
為了對抗XSS,在HtmlEncode中至少轉(zhuǎn)換以下字符：
< 轉(zhuǎn)成 <
> 轉(zhuǎn)成 >
& 轉(zhuǎn)成 &
“ 轉(zhuǎn)成 "
‘ 轉(zhuǎn)成 '
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ā)送各種請求。攻擊者只要借助少許的社會工程學(xué)的詭計，例如通過 QQ 等聊天軟件發(fā)送的鏈接(有些還偽裝成短域名，用戶無法分辨)，攻擊者就能迫使 Web 應(yīng)用的用戶去執(zhí)行攻擊者預(yù)設(shè)的操作。例如，當(dāng)用戶登錄網(wǎng)絡(luò)銀行去查看其存款余額，在他沒有退出時，就點擊了一個 QQ 好友發(fā)來的鏈接，那么該用戶銀行帳戶中的資金就有可能被轉(zhuǎn)移到攻擊者指定的帳戶中。
所以遇到 CSRF 攻擊時，將對終端用戶的數(shù)據(jù)和操作指令構(gòu)成嚴(yán)重的威脅。當(dāng)受攻擊的終端用戶具有管理員帳戶的時候，CSRF 攻擊將危及整個 Web 應(yīng)用程序。
CSRF流程
角色
流程
1.用戶登錄、瀏覽并信任正規(guī)網(wǎng)站W(wǎng)ebA，同時，WebA通過用戶的驗證并在用戶的瀏覽器中產(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ā)出，由于瀏覽器訪問時帶上用戶的Cookie，因此WebA會響應(yīng)瀏覽器的請求，如此一來，攻擊網(wǎng)站W(wǎng)ebB就達到了模擬用戶操作的目的。
CSRF攻擊防護
CSRF 的防御可以從服務(wù)端和客戶端兩方面著手，防御效果是從服務(wù)端著手效果比較好，現(xiàn)在一般的 CSRF 防御也都在服務(wù)端進行。服務(wù)端的預(yù)防 CSRF 攻擊的方式方法有多種，但思路上都是差不多的，主要從以下兩個方面入手：
正確使用 GET，POST 請求和 cookie
在非 GET 請求中增加 token
一般而言，普通的 Web 應(yīng)用都是以 GET、POST 請求為主，還有一種請求是 cookie 方式。我們一般都是按照如下規(guī)則設(shè)計應(yīng)用的請求：
當(dāng)正確的使用了 GET 和 POST 請求之后，剩下的就是在非 GET 方式的請求中增加隨機數(shù)，這個大概有三種方式來進行：
為每個用戶生成一個唯一的 cookie token，所有表單都包含同一個偽隨機值，這種方案最簡單，因為攻擊者不能獲得第三方的 cookie(理論上)，所以表單中的數(shù)據(jù)也就構(gòu)造失敗，但是由于用戶的 cookie 很容易由于網(wǎng)站的 XSS 漏洞而被盜取，所以這個方案必須要在沒有 XSS 的情況下才安全。
每個 POST 請求使用驗證碼，這個方案算是比較完美的，但是需要用戶多次輸入驗證碼，用戶體驗比較差，所以不適合在業(yè)務(wù)中大量運用。
渲染表單的時候，為每一個表單包含一個 csrfToken，提交表單的時候，帶上 csrfToken，然后在后端做 csrfToken 驗證。
CSRF 的防御可以根據(jù)應(yīng)用場景的不同自行選擇。CSRF 的防御工作確實會在正常業(yè)務(wù)邏輯的基礎(chǔ)上帶來很多額外的開發(fā)量，但是這種工作量是值得的，畢竟用戶隱私以及財產(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包時，服務(wù)器返回的SYN+ACK就不能得到應(yīng)答(因為ip是隨意構(gòu)造的)，此時服務(wù)器就會嘗試重新發(fā)送，并且會有至少30s的等待時間，導(dǎo)致資源飽和服務(wù)不可用，此攻擊屬于慢型dos攻擊。
UDP flood攻擊：由于udp是一種無連接的協(xié)議，因此攻擊者可以偽造大量的源IP地址去發(fā)送udp包，此種攻擊屬于大流量攻擊。正常應(yīng)用情況下，UDP包雙向流量會基本相等，因此在消耗對方資源的時候也在消耗自己的資源。
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請求頻率。
防火墻等防護設(shè)置禁止icmp包等
認(rèn)真檢查網(wǎng)絡(luò)設(shè)備和主機/服務(wù)器系統(tǒng)的日志。只要日志出現(xiàn)漏洞或是時間變更,那這臺機器就可能遭到了攻擊。
限制在防火墻外與網(wǎng)絡(luò)文件共享。這樣會給黑客截取系統(tǒng)文件的機會，主機的信息暴露給黑客，無疑是給了對方入侵的機會。
加錢堆機器
網(wǎng)絡(luò)層的DDos攻擊究其本質(zhì)其實是無法防御的，我們能做得就是不斷優(yōu)化自身的網(wǎng)絡(luò)架構(gòu)，以及提升網(wǎng)絡(luò)帶寬。
應(yīng)用層 DDoS
應(yīng)用層 DDoS 攻擊不是發(fā)生在網(wǎng)絡(luò)層，是發(fā)生在 TCP 建立握手成功之后，應(yīng)用程序處理請求的時候，現(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ā)送大量的域名解析請求，通常請求解析的域名是隨機生成或者是網(wǎng)絡(luò)世界上根本不存在的域名，被攻擊的DNS 服務(wù)器在接收到域名解析請求的時候首先會在服務(wù)器上查找是否有對應(yīng)的緩存，如果查找不到并且該域名無法直接由服務(wù)器解析的時候，DNS 服務(wù)器會向其上層 DNS 服務(wù)器遞歸查詢域名信息。域名解析的過程給服務(wù)器帶來了很大的負(fù)載，每秒鐘域名解析請求超過一定的數(shù)量就會造成 DNS 服務(wù)器解析域名超時。
HTTP 慢速連接攻擊：針對 HTTP 協(xié)議，先建立起 HTTP 連接，設(shè)置一個較大的 Conetnt-Length，每次只發(fā)送很少的字節(jié)，讓服務(wù)器一直以為 HTTP 頭部沒有傳輸完成，這樣連接一多就很快會出現(xiàn)連接耗盡。
應(yīng)用層DDos防御
判斷User-Agent字段(不可靠，因為可以隨意構(gòu)造)
網(wǎng)頁中鑲嵌js代碼(不可靠，因為爬蟲也可攜帶瀏覽器引擎，或者執(zhí)行js代碼)
針對ip+cookie，限制訪問頻率(由于cookie可以更改，ip可以使用代理，或者肉雞，也不可靠)
關(guān)閉apache最大連接數(shù)等，合理配置中間件，緩解ddos攻擊。
頁面中添加驗證碼，比如搜索數(shù)據(jù)庫時。
編寫代碼時，盡量實現(xiàn)優(yōu)化，并合理使用緩存技術(shù)，減少數(shù)據(jù)庫的讀取操作。
應(yīng)用層的防御有時比網(wǎng)絡(luò)層的更難，因為導(dǎo)致應(yīng)用層被dos攻擊的因素非常多，有時往往是因為程序員的失誤，導(dǎo)致某個頁面加載需要消耗大量資源，有時是因為中間件配置不當(dāng)?shù)鹊�。而�?yīng)用層DDos防御的核心就是區(qū)分人與機器(爬蟲)，因為大量的請求不可能是人為的，肯定是機器構(gòu)造的。因此如果能有效的區(qū)分人與爬蟲行為，則可以很好地防御此攻擊。
05.目錄遍歷漏洞
目錄遍歷漏洞成因：服務(wù)器端，接收請求中傳來的文件名稱，在服務(wù)器端拼湊成文件的絕對路徑，并且用輸出流下載。
防御措施
06.業(yè)務(wù)安全
在Web系統(tǒng)中，除了常規(guī)的如SQL，XSS，CSRF、Ddos等web漏洞外，更重要的是其業(yè)務(wù)上的安全。
賬戶信息安全
賬戶是一個系統(tǒng)的入口，關(guān)系到用戶最直接的利益，因而賬戶的安全在業(yè)務(wù)安全中占及其重要的地位。賬戶體系分多個層次，每個環(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ā)送的每一個請求，因此能夠按照任何順序進行訪問。于是，用戶就從B直接進入了D過程，就繞過了C。如果C是支付過程，那么用戶就繞過了支付過程而買到了一件商品。如果C是驗證過程，就會繞過驗證直接進入網(wǎng)站程序了。
最后提交新密碼時修改用戶ID為其他ID
跳過驗證步驟、找回方式，直接到設(shè)置新密碼頁面
業(yè)務(wù)接口安全
在短信、郵件調(diào)用業(yè)務(wù)或生成業(yè)務(wù)數(shù)據(jù)環(huán)節(jié)中(類：短信驗證碼，郵件驗證碼，訂單生成，評論提交等)，對其業(yè)務(wù)環(huán)節(jié)進行調(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)品的含有敏感信息的代碼放到第三方外部站點或者暴露給外部用戶，尤其是前端代碼，私鑰類似的保密性的東西不要直接輸出在代碼里或者頁面中。也許還有很多值得注意的點，但是歸根結(jié)底還是繃住安全那根弦，對待每一行代碼都要多多推敲。
開發(fā)時要提防用戶產(chǎn)生的內(nèi)容，要對用戶輸入的信息進行層層檢測
要注意對用戶的輸出內(nèi)容進行過濾(進行轉(zhuǎn)義等)
重要的內(nèi)容記得要加密傳輸(無論是利用https也好，自己加密也好)
get請求與post請求，要嚴(yán)格遵守規(guī)范，不要混用，不要將一些危險的提交使用jsonp完成。
對于URL上攜帶的信息，要謹(jǐn)慎使用。
心中時刻記著，自己的網(wǎng)站哪里可能有危險。
經(jīng)營性網(wǎng)站備案信息
可信網(wǎng)站信用評價
網(wǎng)絡(luò)警察提醒您
誠信網(wǎng)站
中國互聯(lián)網(wǎng)舉報中心
網(wǎng)絡(luò)舉報APP下載
