WEB前端常見受攻擊方式及解決辦法

　　一個網站創建之後，若是不注意安全方面的問題，很容易被人攻擊，下面就討論一下幾種漏洞狀況和防止攻擊的辦法。

1、SQL注入

　　所謂SQL注入，就是經過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。具體來講，它是利用現有應用程序，將（惡意）的SQL命令注入到後臺數據庫引擎執行的能力，它能夠經過在Web表單中輸入（惡意）SQL語句獲得一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。好比先前的不少影視網站泄露VIP會員密碼大多就是經過WEB表單遞交查詢字符暴出的，這類表單特別容易受到SQL注入式攻擊。

　　原理：

　　SQL注入攻擊指的是經過構建特殊的輸入做爲參數傳入Web應用程序，而這些輸入大都是SQL語法裏的一些組合，經過執行SQL語句進而執行攻擊者所要的操做，其主要緣由是程序沒有細緻地過濾用戶輸入的數據，導致非法數據侵入系統。

　　根據相關技術原理，SQL注入能夠分爲平臺層注入和代碼層注入。前者由不安全的數據庫配置或數據庫平臺的漏洞所致；後者主要是因爲程序員對輸入未進行細緻地過濾，從而執行了非法的數據查詢。基於此，SQL注入的產生緣由一般表如今如下幾方面：

　　①不當的類型處理；

　　②不安全的數據庫配置；

　　③不合理的查詢集處理；

　　④不當的錯誤處理；

　　⑤轉義字符處理不合適；

　　⑥多個提交處理不當。

　　防禦：

　　1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗，能夠經過正則表達式，或限制長度；對單引號和雙"-"進行轉換等。

　　2.永遠不要使用動態拼裝sql，可使用參數化的sql或者直接使用存儲過程進行數據查詢存取。

　　3.永遠不要使用管理員權限的數據庫鏈接，爲每一個應用使用單獨的權限有限的數據庫鏈接。

　　4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。

　　5.應用的異常信息應該給出儘量少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝

　　6.sql注入的檢測方法通常採起輔助軟件或網站平臺來檢測，軟件通常採用sql注入檢測工具jsky，MDCSOFT SCAN等。採用MDCSOFT-IPS能夠有效的防護SQL注入，XSS攻擊等。

2、跨站腳本攻擊(XSS，Cross-site scripting)

　　跨站腳本攻擊（XSS）是最多見和基本的攻擊WEB網站的方法。攻擊者在網頁上發佈包含攻擊性代碼的數據。當瀏覽者看到此網頁時，特定的腳本就會以瀏覽者用戶的身份和權限來執行。經過XSS能夠比較容易地修改用戶數據、竊取用戶信息，以及形成其它類型的攻擊，例如CSRF攻擊。

　　常看法決辦法:確保輸出到HTML頁面的數據以HTML的方式被轉義

　　出錯的頁面的漏洞也可能形成XSS攻擊，好比頁面/gift/giftList.htm?page=2找不到。出錯頁面直接把該url原樣輸出，若是攻擊者在url後面加上攻擊代碼發給受害者，就有可能出現XSS攻擊

 3、 跨站請求僞造攻擊（CSRF)

　　跨站請求僞造（CSRF，Cross-site request forgery）是另外一種常見的攻擊。攻擊者經過各類方法僞造一個請求，模仿用戶提交表單的行爲，從而達到修改用戶的數據，或者執行特定任務的目的。爲了假冒用戶的身份，CSRF攻擊經常和XSS攻擊配合起來作，但也能夠經過其它手段，例如誘使用戶點擊一個包含攻擊的連接。

　　解決的思路有：

　　1.採用POST請求，增長攻擊的難度.用戶點擊一個連接就能夠發起GET類型的請求。而POST請求相對比較難，攻擊者每每須要藉助javascript才能實現

　　2.對請求進行認證，確保該請求確實是用戶本人填寫表單並提交的，而不是第三者僞造的.具體能夠在會話中增長token,確保看到信息和提交信息的是同一我的

4、Http Heads攻擊

　　凡是用瀏覽器查看任何WEB網站，不管你的WEB網站採用何種技術和框架，都用到了HTTP協議。HTTP協議在Response header和content之間，有一個空行，即兩組CRLF（0x0D 0A）字符。這個空行標誌着headers的結束和content的開始。「聰明」的攻擊者能夠利用這一點。只要攻擊者有辦法將任意字符「注入」到 headers中，這種攻擊就能夠發生。

　　以登錄爲例：有這樣一個url：http://localhost/login?page=http%3A%2F%2Flocalhost%2Findex

　　當登陸成功之後，須要重定向回page參數所指定的頁面。下面是重定向發生時的response headers。

HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/index

　　假如把URL修改一下，變成這個樣子：

　　http://localhost/login?page=http%3A%2F%2Flocalhost%2Fcheckout%0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E

　　那麼重定向發生時的reponse會變成下面的樣子：

HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/checkout<CRLF>
<CRLF>
<script>alert('hello')</script>

　　這個頁面可能會意外地執行隱藏在URL中的javascript。相似的狀況不只發生在重定向（Location header）上，也有可能發生在其它headers中，如Set-Cookie header。這種攻擊若是成功的話，能夠作不少事，例如：執行腳本、設置額外的cookie（<CRLF>Set-Cookie: evil=value）等。

　　避免這種攻擊的方法，就是過濾全部的response headers，除去header中出現的非法字符，尤爲是CRLF。

　　服務器通常會限制request headers的大小。例如Apache server默認限制request header爲8K。若是超過8K，Aapche Server將會返回400 Bad Request響應：

　　對於大多數狀況，8K是足夠大的。假設應用程序把用戶輸入的某內容保存在cookie中,就有可能超過8K.攻擊者把超過8k的header連接發給受害 者,就會被服務器拒絕訪問.解決辦法就是檢查cookie的大小,限制新cookie的總大寫，減小因header過大而產生的拒絕訪問攻擊。

5、Cookie攻擊

　　經過JavaScript很是容易訪問到當前網站的cookie。你能夠打開任何網站，而後在瀏覽器地址欄中輸入：javascript:alert(doucment.cookie),馬上就能夠看到當前站點的cookie（若是有的話）。攻擊者能夠利用這個特性來取得你的關鍵信息。例如，和XSS攻擊相配合，攻擊者在你的瀏覽器上執行特定的JavaScript腳本，取得你的cookie。假設這個網站僅依賴cookie來驗證用戶身份，那麼攻擊者就能夠假冒你的身份來作一些事情。

　　如今多數瀏覽器都支持在cookie上打上HttpOnly的標記,凡是有這個標誌的cookie就沒法經過JavaScript來取得,若是能在關鍵cookie上打上這個標記，就會大大加強cookie的安全性

6、重定向攻擊

　　一種經常使用的攻擊手段是「釣魚」。釣魚攻擊者，一般會發送給受害者一個合法連接，當連接被點擊時，用戶被導向一個似是而非的非法網站，從而達到騙取用戶信任、竊取用戶資料的目的。爲防止這種行爲，咱們必須對全部的重定向操做進行審覈，以免重定向到一個危險的地方。常看法決方案是白名單，將合法的要重定向的url加到白名單中，非白名單上的域名重定向時拒之。第二種解決方案是重定向token，在合法的url上加上token，重定向時進行驗證。

7、上傳文件攻擊

　　1.文件名攻擊，上傳的文件採用上傳以前的文件名，可能形成：客戶端和服務端字符碼不兼容，致使文件名亂碼問題；文件名包含腳本，從而形成攻擊。

　　2.文件後綴攻擊，上傳的文件的後綴多是exe可執行程序、js腳本等文件，這些程序可能被執行於受害者的客戶端，甚至可能執行於服務器上。所以咱們必須過濾文件名後綴，排除那些不被許可的文件名後綴。

　　3.文件內容攻擊，IE6有一個很嚴重的問題，它不信任服務器所發送的content type，而是自動根據文件內容來識別文件的類型，並根據所識別的類型來顯示或執行文件。若是上傳一個gif文件，在文件末尾放一段js攻擊腳本，就有可能被執行。這種攻擊，它的文件名和content type看起來都是合法的gif圖片，然而其內容卻包含腳本，這樣的攻擊沒法用文件名過濾來排除，而是必須掃描其文件內容，才能識別。