WEB網站常見受攻擊方式及解決辦法

標籤：

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

一.跨站指令碼攻擊(XSS)

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

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

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

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

     跨站請求偽造（CSRF，Cross-site request forgery）是另一種常見的攻擊。攻擊者通過各種方法偽造一個請求，模仿使用者提交表單的行為，從而達到修改使用者的資料，或者執行特定任務的目的。為了假冒使用者的身份，CSRF攻擊常常和XSS攻擊配合起來做，但也可以通過其它手段，例如誘使使用者點擊一個包含攻擊的連結
    解決的思路有:
      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圖片,然而其內容卻包含指令碼,這樣的攻擊無法用檔案名稱過濾來排除，而是必須掃描其檔案內容，才能識別。

WEB網站常見受攻擊方式及解決辦法