Web安全是一個大課題，在網絡安全事件中，針對Web的攻擊是最多的。
從一些html標籤，到JS代碼安全問題，然後到接口、數據庫，以及流量攻擊、模擬請求、自動化攻擊等等，很多很多。
本文簡單的聊聊常見的網絡攻擊防禦方式。
一、DDOS
DDOS最常見，也是最難防禦。目前還沒有人敢說能徹底防禦DDOS。
DDoS就是流量攻擊。
由於DDoS攻擊往往採取合法的數據請求技術，再加上傀儡機器，造成DDoS攻擊成為最難防禦的網絡攻擊之一。
如何基礎防禦：
1，對頻繁請求的ip和接口進行限流，熔斷處理，超過多少次必須輸入圖形驗證碼。
進行驗證處理可，減輕服務器數據庫處理壓力。
其實現在很多大公司都是把一下接口放在一個項目裡面進行rpc遠程調用處理。通過分佈式緩存，分佈式一致性問題，分佈式事務來解決這些問題。
2，使用黑名單和白名單機制，防禦攻擊（OAuth2.0協議）這個推薦使用。
這個黑名單白名單就是現在很多代理網站來給你處理網站的安全性，也算是給你防禦網站吧。
3，選擇高防數據中心：
國內數據中心一般都會有防火牆防禦，我們今天把防火牆情況分為兩種：
（1）集群防禦，單線機房防禦一般在：10G-32G的集群防禦，BGP多線機房一般為：10G以內集群防火牆。
（2）獨立防禦，獨立防禦都是出現在單線機房，或者是多線多ip機房，機房防禦能力一般為：10G-200G不等，這種機房是實現的單機防禦能力，隨著數據中心的防禦能力提高還有就是競爭壓力比較大，高防的價格也在不斷的創造新低。
4、CDN內容分發：
通過CDN防禦的方式：CDN技術的初衷是提高互聯網用戶對網站的訪問速度，但是由於分佈式多節點的特點，又能夠對分佈式拒絕攻擊流量產生稀釋的效果。所以目前CDN防禦的方式不但能夠起到防禦的作用，而且用戶的訪問請求是到最近的緩存節點，所以也對加速起到了很好的作用。
CDN防禦的最重要的原理：通過智能DNS的方式將來自不同位置的流量分配到對應的位置上的節點上，這樣就讓區域內的節點成為流量的接收中心，從而將流量稀釋的效果，在流量被稀釋到各個節點後，就可以在每個節點進行流量清洗。從而起到防禦作用。
目前針對DDOS流量攻擊的防護方法中CDN防禦也分為自建CDN防禦，這種情況防禦能力較好，但是成本較高，需要部署多節點，租用各個節點服務器，如果應用較少的話，造成資源浪費。另外就是租用別人現成的CDN防禦，可以極大的節省成本，並且防禦能力很少非常好。
二，CSRF
CSRF即：Cross Site Request Forgery（跨站域請求偽造）它在 2007 年曾被列為互聯網 20 大安全隱患之一,也被稱為“One Click Attack”或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用也就是人們所知道的釣魚網站。儘管聽起來像跨站腳本（XSS），但它與XSS非常不同，並且攻擊方式幾乎相左。
XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊往往不大流行，因此對其進行防範的資源也相當稀少，所以被認為比XSS更具危險性。
也就是通俗一點來說就是，大量請求你的接口，通過抓包工具請求分析，偽造token訪問你的接口，攻擊服務器降低服務器數據庫性能。
如何防禦CSRF？
模擬請求這裡還是要說到分佈式，畢竟真的要用到分佈式，緩存集群。解決限流，服務容錯，熔斷的問題。
後端防禦：
1、MVCC方案
多版本併發控制，該策略主要使用 update with condition（更新帶條件來防止）來保證多次外部請求調用對系統的影響是一致的。在系統設計的過程中，合理的使用樂觀鎖，通過 version 或者 updateTime（timestamp）等其他條件，來做樂觀鎖的判斷條件，這樣保證更新操作即使在併發的情況下，也不會有太大的問題。
2、去重表
在插入數據的時候，插入去重表，利用數據庫的唯一索引特性，保證唯一的邏輯。
3、悲觀鎖
select for update，整個執行過程中鎖定該訂單對應的記錄。注意：這種在 DB 讀大於寫的情況下儘量少用。
4、Token機制,防止頁面重複提交
把token放在redis 裡面通過限流方式，每個token只能使用一次，網絡延遲或者重試機制解決這個問題。
5，MQ消息中間件也可以解決這個問題，可以通過發佈訂閱的方式來消息通知處理。
6，nginx服務器對域名網關攔截處理，只能通過域名訪問，不能獲取到你的ip，所以的前臺文件通過分離來實現。
7，分佈式校驗
在大型網站中，使用Session存儲CSRF Token會帶來很大的壓力。訪問單臺服務器session是同一個。但是現在的大型網站中，我們的服務器通常不止一臺，可能是幾十臺甚至幾百臺之多，甚至多個機房都可能在不同的省份，用戶發起的HTTP請求通常要經過像Ngnix之類的負載均衡器之後，再路由到具體的服務器上，由於Session默認存儲在單機服務器內存中，因此在分佈式環境下同一個用戶發送的多次HTTP請求可能會先後落到不同的服務器上，導致後面發起的HTTP請求無法拿到之前的HTTP請求存儲在服務器中的Session數據，從而使得Session機制在分佈式環境下失效，因此在分佈式集群中CSRF Token需要存儲在Redis之類的公共存儲空間。
由於使用Session存儲，讀取和驗證CSRF Token會引起比較大的複雜度和性能問題，目前很多網站採用Encrypted Token Pattern方式。這種方法的Token是一個計算出來的結果，而非隨機生成的字符串。這樣在校驗時無需再去讀取存儲的Token，只用再次計算一次即可。
這種Token的值通常是使用UserID、時間戳和隨機數，通過加密的方法生成。這樣既可以保證分佈式服務的Token一致，又能保證Token不容易被破解。
在token解密成功之後，服務器可以訪問解析值，Token中包含的UserID和時間戳將會被拿來被驗證有效性，將UserID與當前登錄的UserID進行比較，並將時間戳與當前時間進行比較。
前臺防禦：
1.CSRF監控
對於一個比較複雜的網站系統，某些項目、頁面、接口漏掉了CSRF防護措施是很可能的。
一旦發生了CSRF攻擊，我們如何及時的發現這些攻擊呢？（這裡其實nginx也可以處理）
CSRF攻擊有著比較明顯的特徵：
- 跨域請求。
- GET類型請求Header的MIME類型大概率為圖片，而實際返回Header的MIME類型為Text、JSON、HTML。
2，通過對稱非對稱算法，前臺網站訪問先訪問後臺獲取到應籤，然後在把前臺請求的參數拿到後臺去檢驗。一般網絡上面接口支付都是重定向啦。這樣一般都比較麻煩。但是這樣安全性能很高的，其實ssl證書比域名都貴滴。
3，用雙重Cookie防禦CSRF的
優點：
- 無需使用Session，適用面更廣，易於實施。
- Token儲存於客戶端中，不會給服務器帶來壓力。
- 相對於Token，實施成本更低，可以在前後端統一攔截校驗，而不需要一個個接口和頁面添加。
缺點：
- Cookie中增加了額外的字段。
- 如果有其他漏洞（例如XSS），攻擊者可以注入Cookie，那麼該防禦方式失效。
- 難以做到子域名的隔離。
- 為了確保Cookie傳輸安全，採用這種防禦方式的最好確保用整站HTTPS的方式，如果還沒切HTTPS的使用這種方式也會有風險。
三，SQL注入
SQL注入：利用現有應用程序，將惡意的SQL命令注入到後臺數據庫執行一些惡意的操作。造成SQL注入的原因是因為程序沒有有效過濾用戶的輸入，使攻擊者成功的向服務器提交惡意的SQL查詢代碼，程序在接收後錯誤的將攻擊者的輸入作為查詢語句的一部分執行，導致原始的查詢邏輯被改變，額外的執行了攻擊者精心構造的惡意代碼。
SQL注入漏洞可能會影響使用SQL數據庫（如MySQL，Oracle，SQL Server或其他）的任何網站或Web應用程序。犯罪分子可能會利用它來未經授權訪問用戶的敏感數據：客戶信息，個人數據，商業機密，知識產權等。SQL注入攻擊是最古老，最流行，最危險的Web應用程序漏洞之一。
SQL注入攻擊的類型
SQL注入攻擊可以通過多種方式執行。在選擇特定攻擊方法之前，攻擊者可能會觀察系統的行為。
帶內注入
這是典型的攻擊，攻擊者可以通過相同的通信通道發起攻擊並獲得結果。這是通過兩種帶內技術完成的：
● 基於錯誤的SQL注入：從顯示的錯誤消息中獲取有關數據庫的信息
● 基於聯合的SQL注入：依賴於攻擊者能夠將UNION ALL被盜信息的結果與合法結果連接起來。
這兩種技術都依賴於攻擊者修改應用程序發送的SQL，以及瀏覽器中顯示的錯誤和返回的信息。如果應用程序開發人員或數據庫開發人員無法正確地參數化他們在查詢中使用的值，那麼它會成功。兩者都是試錯法，可以檢測到錯誤。
盲注入
也稱為推理SQL注入，盲注入攻擊不會直接從目標數據庫中顯示數據；相反，攻擊者會仔細檢查行為中的間接線索。HTTP響應中的詳細信息，某些用戶輸入的空白網頁以及數據庫響應某些用戶輸入需要多長時間，這些都可以是線索，具體取決於攻擊者的目標。他們還可以指向攻擊者嘗試的另一個SQLi攻擊途徑。
帶外注入
這種攻擊有點複雜，當攻擊者無法在單個直接查詢 - 響應攻擊中實現其目標時，攻擊者可能會使用此攻擊。通常，攻擊者會製作SQL語句，這些語句在呈現給數據庫時會觸發數據庫系統創建與攻擊者控制的外部服務器的連接。以這種方式，攻擊者可以收集數據或可能控制數據庫的行為。
二階注入就是一種帶外注入攻擊。在這種情況下，攻擊者將提供SQL注入，該注入將由數據庫系統的單獨行為存儲和執行。當二級系統行為發生時（它可能類似於基於時間的作業或由其他典型管理員或用戶使用數據庫觸發的某些事情）並且執行攻擊者的SQL注入，那就是當“伸出”到系統時攻擊者控制發生了。
如何防禦SQL注入
1、規範sql 寫的方式不要寫拼接sql,、最好使用預編譯方式
在mybatis編寫sql語句的時候，最好使用?傳參數方式，不要使用#傳參數，因為#傳參數方式，可能會受到sql語句攻擊。
#{}: 解析為一個 JDBC 預編譯語句（prepared statement）的參數標記符，一個 #{ } 被解析為一個參數佔位符,可以防止SQL注入問題。
${}: 僅僅為一個純碎的 string 替換，在動態 SQL 解析階段將會進行變量替換。
2、限制數據庫權限和特權
將數據庫用戶的功能設置為最低要求；這將限制攻擊者在設法獲取訪問權限時可以執行的操作。
避免直接向用戶顯示數據庫錯誤
攻擊者可以使用這些錯誤消息來獲取有關數據庫的信息。
對訪問數據庫的Web應用程序使用Web應用程序防火牆（WAF），其實，不止是SQL注入，本文所講的這些攻擊，幾乎全都可以用WAF進行防護。WAF有多種，比如硬件、軟件、雲，有很貴的商業WAF硬件，也有免費+商業的WAF軟件（比如：ShareWAF，很不錯。）。
這為面向Web的應用程序提供了保護，它可以幫助識別SQL注入嘗試；根據設置，它還可以幫助防止SQL注入嘗試到達應用程序（以及數據庫）。
3、定期測試與數據庫交互的Web應用程序
這樣做可以幫助捕獲可能允許SQL注入的新錯誤或迴歸。
將數據庫更新為最新的可用修補程序
這可以防止攻擊者利用舊版本中存在的已知弱點/錯誤。
4.後臺日誌分析sql 可以使用AOP攔截寫入sql性能
四、防盜
防盜鏈就是A網站有一張圖片，B網站要引用過來使用到自己網站，引用圖片和樣式，js等等。
如何防禦？
1，寫一個過濾器判斷http請求頭Referer域中的記錄來源的值，如果和當前訪問的域名不一致的情況下，說明該圖片可能被其他服務器盜用。
2，通過動靜分離或者前後端分離。通過nginx配置。
3，可以通過shiro權限判斷鏈接重定向。
五、XSS
Xss就是javascript 腳本攻擊，就是在表單提交的時候提交一個小腳本，因為瀏覽器默認是支持腳本的，所以寫個小腳本不做處理的話問題就很大。不處理網頁直接掛掉。
如何防禦？
1，通過後臺編寫一個過濾器攔截所有getParameter參數 重寫httpservletwrapp方法。
2，通過工具類將參數特殊字符轉換成html源代碼保存。
3，通過js檢驗
過濾用戶輸入的 檢查用戶輸入的內容中是否有非法內容。如<>（尖括號）、”（引號）、 ‘（單引號）、%（百分比符號）、;（分號）、()（括號）、&（& 符號）、+（加號）等。、嚴格控制輸出
六、文件上傳漏洞
什麼是文件上傳漏洞？
上傳漏洞這個顧名思義，就是攻擊者通過上傳木馬文件，直接得到WEBSHELL，危害等級超級高，現在的入侵中上傳漏洞也是常見的漏洞。 導致該漏洞的原因在於代碼作者沒有對訪客提交的數據進行檢驗或者過濾不嚴，可以直接提交修改過的數據繞過擴展名的檢驗。
大家經常在網上下載文件什麼東西，比如一個軟件，默認幾十M但是下下來為啥只有幾百Kb很多網站都是釣魚網站，你下載下來的文件是後綴為.exe文件，這是系統運行文件，文件下載也有這個問題，所以網上很多不靠譜滴，不要亂下載文件。
如何解決防禦？
1 對文件格式限制，只允許某些格式上傳
2 對文件格式進行校驗，前端跟服務器都要進行校驗（前端校驗擴展名，服務器校驗擴展名、Content_Type等）
3 將上傳目錄防止到項目工程目錄之外，當做靜態資源文件路徑，並且對文件的權限進行設定，禁止文件下的執行權限。
4 通過文件流解析判斷文件類型。
七、忘記密碼？
我在這裡分析一個常見的qq漏洞，現在很多都還有人家盜用別人密碼，然後通過qq發送消息，找你借錢或者轉賬到某個地方，黑客就是通過 抓包分析暴力破解密碼（寫一個程序破解驗證碼，如果是4位純數字可想而知），然後盜取你的短信驗證碼登錄，如果發生了這樣的情況，如果是qq的話你就一直髮短信驗證碼，聯繫客戶還得一段時間。因為大家都知道qq驗證碼都是4位所以別人很好破解，我這裡說的都是真實案例，因為我以前也被別人這樣操作過，但是我就一直頻繁發短信驗證碼後面就找回來啦。
如何防禦：
1，忘記密碼驗證碼最好在6-8位 最好是加字符，字母組合。
2 一旦頻繁調用接口驗證時，應該使用圖形驗證碼攔截，防止機器模擬。
3，使用黑名單和白名單機制，防禦攻擊（OAuth2.0協議）。
閱讀更多 WangLiwen 的文章
