web網站常見攻擊及防范

一個網站建立以后,如果不注意安全方面的問題,很容易被人攻擊,下面就討論一下幾種漏洞情況和防止攻擊的辦法.

一.SQL注入

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

    原理：

    SQL注入攻擊指的是通過構建特殊的輸入作為參數傳入Web應用程序，而這些輸入大都是SQL語法里的一些組合，通過執行SQL語句進而執行攻擊者所要的操作，其主要原因是程序沒有細致地過濾用戶輸入的數據，致使非法數據侵入系統。

    根據相關技術原理，SQL注入可以分為平台層注入和代碼層注入。前者由不安全的數據庫配置或數據庫平台的漏洞所致；后者主要是由於程序員對輸入未進行細致地過濾，從而執行了非法的數據查詢。基於此，SQL注入的產生原因通常表現在以下幾方面：①不當的類型處理；②不安全的 數據庫配置；③不合理的查詢集處理；④不當的錯誤處理；⑤轉義字符處理不合適；⑥多個提交處理不當。

　　

被攻擊的原因:

　　sql語句偽造參數，然后在對參數進行拼接的后形成破壞性的sql語句，最后導致數據庫受到攻擊

    防護：

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

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

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

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

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

    6.sql注入的檢測方法一般采取輔助 軟件或網站平台來檢測，軟件一般采用sql注入檢測工具jsky，網站平台就有億思 網站安全平台檢測工具。MDCSOFT SCAN等。采用 MDCSOFT-IPS可以有效的防御SQL注入，XSS攻擊等。

　7.使用預編譯語句(PreparedStatement)，這樣的話即使我們使用sql語句偽造成參數，到了服務端的時候，這個偽造sql語句的參數也只是簡單的字符，並不能起到攻擊的作用。

　　
二.跨站腳本攻擊(XSS)

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

　被攻擊的原因：

　　用戶輸入的數據變成了代碼，比如說上面的<script>,應該只是字符串卻有了代碼的作用。

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

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

 三. 跨站請求偽造攻擊（CSRF)

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

　被攻擊的原因：

　　用戶本地存儲cookie，攻擊者利用用戶的cookie進行認證，然后偽造用戶發出請求

　　之所以被攻擊是因為攻擊者利用了存儲在瀏覽器用於用戶認證的cookie，那么如果我們不用cookie來驗證不就可以預防了。所以我們可以采用token（不存儲於瀏覽器）認證，為每一個提交的表單生成一個隨機token， 存儲在session中，每次驗證表單token，檢查token是否正確。。
　　通過referer識別，HTTP Referer是header的一部分，當瀏覽器向web服務器發送請求的時候，一般會帶上Referer，告訴服務器我是從哪個頁面鏈接過來的，服務器基此可以獲得一些信息用於處理。那么這樣的話，我們必須登錄銀行A網站才能進行轉賬了。

 

 

    解決的思路有:
      1.采用POST請求,增加攻擊的難度.用戶點擊一個鏈接就可以發起GET類型的請求。而POST請求相對比較難，攻擊者往往需要借助javascript才能實現
      2.對請求進行認證，確保該請求確實是用戶本人填寫表單並提交的，而不是第三者偽造的.具體可以在會話中增加token,確保看到信息和提交信息的是同一個人

 

四.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過大而產生的拒絕訪問攻擊

五.Cookie攻擊

      通過Java Script非常容易訪問到當前網站的cookie。你可以打開任何網站，然后在瀏覽器地址欄中輸入：javascript:alert(doucment.cookie),立刻就可以看到當前站點的cookie（如果有的話）。攻擊者可以利用這個特性來取得你的關鍵信息。例如，和XSS攻擊相配合，攻擊者在你的瀏覽器上執行特定的Java Script腳本，取得你的cookie。假設這個網站僅依賴cookie來驗證用戶身份，那么攻擊者就可以假冒你的身份來做一些事情。
      現在多數瀏覽器都支持在cookie上打上HttpOnly的標記,凡有這個標志的cookie就無法通過Java Script來取得,如果能在關鍵cookie上打上這個標記，就會大大增強cookie的安全性

六.重定向攻擊
    一種常用的攻擊手段是“釣魚”。釣魚攻擊者，通常會發送給受害者一個合法鏈接，當鏈接被點擊時，用戶被導向一個似是而非的非法網站，從而達到騙取用戶信任、竊取用戶資料的目的。為防止這種行為,我們必須對所有的重定向操作進行審核,以避免重定向到一個危險的地方.常見解決方案是白名單,將合法的要重定向的url加到白名單中,非白名單上的域名重定向時拒之,第二種解決方案是重定向token,在合法的url上加上token,重定向時進行驗證.

七.上傳文件攻擊
    1.文件名攻擊,上傳的文件采用上傳之前的文件名,可能造成:客戶端和服務端字符碼不兼容,導致文件名亂碼問題;文件名包含腳本,從而造成攻擊.

     2.文件后綴攻擊.上傳的文件的后綴可能是exe可執行程序,js腳本等文件,這些程序可能被執行於受害者的客戶端,甚至可能執行於服務器上.因此我們必須過濾文件名后綴,排除那些不被許可的文件名后綴.

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

八.session攻擊，會話劫持

一句話概括：

　　用某種手段得到用戶session ID，從而冒充用戶進行請求

原因： 由於http本身無狀態，同時如果想維持一個用戶不同請求之間的狀態，session ID用來認證用戶
三種方式獲取用戶session ID：

　　預測：PHP生成的session ID足夠復雜並且難於預測，基本不可能
　　會話劫持： URL參數傳遞sessionID； 隱藏域傳遞sessionID；比較安全的是cookie傳遞。但同樣可以被xss攻擊取得sessionID
　　會話固定： 誘騙用戶使用指定的sessionID進行登錄，這樣系統不會分配新的sessionID
防御方法：

　　每次登陸重置sessionID
　　設置HTTPOnly，防止客戶端腳本訪問cookie信息，阻止xss攻擊
　　關閉透明化sessionID
　　user-agent頭信息驗證
　　token校驗

九.DDOS

概念
　　分布式拒絕服務攻擊（Distributed Denial of Service），簡單說就是發送大量請求是使服務器癱瘓。DDos攻擊是在DOS攻擊基礎上的，可以通俗理解，dos是單挑，而ddos是群毆，因為現代技術的發展，dos攻擊的殺傷力降低，所以出現了DDOS，攻擊者借助公共網絡，將大數量的計算機設備聯合起來，向一個或多個目標進行攻擊。
案例:
　　SYN Flood ,簡單說一下tcp三次握手，客戶端先服務器發出請求，請求建立連接，然后服務器返回一個報文，表明請求以被接受，然后客戶端也會返回一個報文，最后建立連接。那么如果有這么一種情況，攻擊者偽造ip地址，發出報文給服務器請求連接，這個時候服務器接受到了，根據tcp三次握手的規則，服務器也要回應一個報文，可是這個ip是偽造的，報文回應給誰呢，第二次握手出現錯誤，第三次自然也就不能順利進行了，這個時候服務器收不到第三次握手時客戶端發出的報文，又再重復第二次握手的操作。如果攻擊者偽造了大量的ip地址並發出請求，這個時候服務器將維護一個非常大的半連接等待列表，占用了大量的資源，最后服務器癱瘓。
CC攻擊，在應用層http協議上發起攻擊，模擬正常用戶發送大量請求直到該網站拒絕服務為止。
被攻擊的原因:
　　服務器帶寬不足，不能擋住攻擊者的攻擊流量
預防:
　　最直接的方法增加帶寬。但是攻擊者用各地的電腦進行攻擊，他的帶寬不會耗費很多錢，但對於服務器來說，帶寬非常昂貴。
　　雲服務提供商有自己的一套完整DDoS解決方案，並且能提供豐富的帶寬資源