Web前端攻擊方式及防禦措施

原文鏈接：https://blog.csdn.net/Vivian_jay/article/details/58667283

一、XSS

【Cross Site Script】跨站腳本攻擊
惡意攻擊者往Web頁面裏插入惡意Script代碼，當用戶瀏覽該頁之時，嵌入其中Web裏面的Script代碼會被執行，從而達到惡意攻擊用戶的目的。

1、Reflected XSS

基於反射的XSS攻擊，主要依靠站點服務端返回腳本，在客戶端觸發執行從而發起Web攻擊。Web客戶端使用Server端腳本生成頁面爲用戶提供數據時，如果未經驗證的用戶數據被包含在頁面中而未經HTML實體編碼，客戶端代碼便能夠注入到動態頁面中。

2、Stored XSS

該類型是應用最爲廣泛而且有可能影響到Web服務器自身安全的漏洞，駭客將攻擊腳本上傳到Web服務器上，使得所有訪問該頁面的用戶都面臨信息泄漏的可能，其中也包括了Web服務器的管理員。

3、DOM-based XSS

本地利用漏洞，這種漏洞存在於頁面中客戶端腳本自身。

4、防禦措施

1. 對所有用戶提交內容進行可靠的輸入驗證，包括對URL、查詢關鍵字、HTTP頭、POST數據等，僅接受指定長度範圍內、採用適當格式、採用所預期的字符的內容提交，對其他的一律過濾。
2. 實現Session標記(session tokens)、CAPTCHA系統或者HTTP引用頭檢查，以防功能被第三方網站所執行。
3. 確認接收的的內容被妥善的規範化，僅包含最小的、安全的Tag(沒有javascript)，去掉任何對遠程內容的引用(尤其是樣式表和javascript)，使用HTTP only的cookie。
4. 使用HTTPS

當然，如上操作將會降低Web業務系統的可用性，用戶僅能輸入少量的制定字符，人與系統間的交互被降到極致，僅適用於信息發佈型站點。

XSS的原理分析與解剖
XSS攻擊及防禦

二、 CSRF

【Cross Site Request Forgery】站點僞造請求
跨站點參考僞造通過在訪問用戶被認爲已經通過身份驗證的Web應用程序的頁面中包含惡意代碼或鏈接來工作。 如果該Web應用程序的會話沒有超時，攻擊者可能執行未授權的命令。

防禦措施

1. 驗證 HTTP Referer 字段 ;
2. 在請求地址中添加 token 並驗證 ;
3. 在 HTTP 頭中自定義屬性並驗證
4. 正確使用GET,POST和Cookie；
5. 在非GET請求中增加僞隨機數；

預防CSRF攻擊
CSRF攻擊介紹及防禦

三、SQL注入

用戶可以提交一段數據庫查詢代碼，根據程序返回的結果，獲得某些他想得知的數據。
原理如下圖所示：

防禦措施

1. 採用sql語句預編譯和綁定變量，是防禦sql注入的最佳方法。採用JDBC的預編譯語句集，它內置了處理SQL注入的能力，只要使用它的setXXX方法傳值即可。

     <blockquote>
       <p><strong><em>原理</em></strong>：採用了PreparedStatement，就會將sql語句：”select id, no from user where id=?”
         預先編譯好，也就是SQL引擎會預先進行語法分析，產生語法樹，生成執行計劃，也就是說，後面你輸入的參數，無論你輸入的是什麼，都不會影響該sql語句的 語法結構了,只會被當做字符串字面值參數。</p>
     </blockquote>
   </li>
   <li>
     <p>使用正則表達式來過濾一些sql關鍵字，如or、where等。</p>
   
     <blockquote>
       <p><a href="http://blog.csdn.net/acmman/article/details/48862841" rel="nofollow"
           data-token="9b698ccb867cf3aab562d543d1dff7f0">【Web安全與防禦】簡析Sql注入與防禦措施</a></p>
     </blockquote>
   </li>
   

四、cookie竊取和session劫持

Cookie包含了瀏覽器客戶端的用戶憑證，相對較小。Session則維護在服務器，用於維護相對較大的用戶信息。cookie被攻擊者竊取、session被劫持即攻擊者劫持會話，合法登錄了你的賬戶，可以瀏覽大部分用戶資源。
用通俗的語言，Cookie是鑰匙，Session是鎖芯。
最基本的cookie竊取方式：xss漏洞。
cookie竊取和session劫持

五、釣魚攻擊【重定向攻擊】

攻擊者會發送給受害者一個合法鏈接，當鏈接被點擊時，用戶被導向一個似是而非的非法網站，從而達到騙取用戶信任、竊取用戶資料的目的。

防禦措施
對所有的重定向操作進行審覈,以避免重定向到一個危險的地方.

1. 常見解決方案是白名單,將合法的要重定向的url加到白名單中,非白名單上的域名重定向時拒之;
2. 重定向token,在合法的url上加上token,重定向時進行驗證.

六、Http Heads攻擊

HTTP協議在Response header和content之間，有一個空行，即兩組CRLF（0x0D 0A）字符。這個空行標誌着headers的結束和content的開始。“聰明”的攻擊者可以利用這一點。只要攻擊者有辦法將任意字符“注入”到headers中，這種攻擊就可以發生。

防禦措施
過濾所有的response headers，除去header中出現的非法字符，尤其是CRLF。

七、拒絕服務攻擊【DoS】

攻擊者想辦法讓目標機器停止提供服務：一是使用SYN flood迫使服務器的緩衝區滿，不接收新的請求；二是使用IP欺騙，迫使服務器把非法用戶的連接復位，影響合法用戶的連接。

防禦措施
對於SYN flood：啓用SYN Cookie、設置SYN最大隊列長度以及設置SYN+ACK最大重試次數。

八、文件上傳攻擊

用戶上傳一個可執行的腳本文件，並通過此腳本文件獲得了執行服務端命令的能力。

分類

1. 文件名攻擊：上傳的文件採用上傳之前的文件名,可能造成客戶端和服務端字符碼不兼容,導致文件名亂碼問題;文件名包含腳本,從而造成攻擊.
2. 文件後綴攻擊：上傳的文件的後綴可能是exe可執行程序,js腳本等文件,這些程序可能被執行於受害者的客戶端,甚至可能執行於服務器上.因此我們必須過濾文件名後綴,排除那些不被許可的文件名後綴.
3. 文件內容攻擊：IE6有一個很嚴重的問題 , 它不信任服務器所發送的content type，而是自動根據文件內容來識別文件的類型，並根據所識別的類型來顯示或執行文件.如果上傳一個gif文件,在文件末尾放一段js攻擊腳本,就有可能被執行.這種攻擊,它的文件名和content type看起來都是合法的gif圖片,然而其內容卻包含腳本,這樣的攻擊無法用文件名過濾來排除，而是必須掃描其文件內容，才能識別。

防禦措施

1. 文件上傳的目錄設置爲不可執行。
2. 判斷文件類型。在判斷文件類型的時候，可以結合使用MIME Type，後綴檢查等方式。因爲對於上傳文件，不能簡單地通過後綴名稱來判斷文件的類型，因爲攻擊者可以將可執行文件的後綴名稱改爲圖片或其他後綴類型，誘導用戶執行。
3. 對上傳的文件類型進行白名單校驗，只允許上傳可靠類型。
4. 上傳的文件需要進行重新命名，使攻擊者無法猜想上傳文件的訪問路徑，將極大地增加攻擊成本。
5. 限制上傳文件的大小。
6. 單獨設置文件服務器的域名。