天天看點
傳回

Web安全：XSS、CSRF以及如何防範

1. XSS

1.1 定義

XSS

，即 Cross Site Script，中譯是跨站腳本攻擊；其原本縮寫是 CSS，但為了和層疊樣式表(Cascading Style Sheet)有所區分，因而在安全領域叫做 XSS。XSS 攻擊是指攻擊者在網站上注入惡意的用戶端代碼，通過惡意腳本對用戶端網頁進行篡改，進而在使用者浏覽網頁時，對使用者浏覽器進行控制或者擷取使用者隐私資料的一種攻擊方式。攻擊者對用戶端網頁注入的惡意腳本一般包括 JavaScript，有時也會包含 HTML 和 Flash。有很多種方式進行 XSS 攻擊，但它們的共同點為：将一些隐私資料像 cookie、session 發送給攻擊者，将受害者重定向到一個由攻擊者控制的網站，在受害者的機器上進行一些惡意操作。XSS攻擊可以分為3類：反射型（非持久型）、存儲型（持久型）、基于DOM。

1.2 xss類型

  1. 反射型 （Reflected XSS ） 送出請求時，XSS代碼出現在url中，作為輸入送出到伺服器端，伺服器端解析後響應，XSS代碼随響應内容一起傳回給浏覽器，最後浏覽器解析執行XSS代碼。這個過程像一次反射，是以叫反射型XSS。
  2. 存儲型存 Stored XSS和 Reflected XSS的差别就在于，具有攻擊性的腳本被儲存到了伺服器端（資料庫，記憶體，檔案系統）并且可以被普通使用者完整的從服務的取得并執行，進而獲得了在網絡上傳播的能力。
  3. DOM型 （DOM-based or local XSS） 即基于DOM或本地的 XSS 攻擊：其實是一種特殊類型的反射型 XSS，它是基于 DOM文檔對象模型的一種漏洞。可以通過 DOM來動态修改頁面内容，從用戶端擷取 DOM中的資料并在本地執行。基于這個特性，就可以利用 JS腳本來實作 XSS漏洞的利用。

1.3 執行個體

  1. 拼接url 擷取使用者敏感資料
  2. 背景存在漏洞拼接sql 盜取資料庫資訊
  3. 舉例有這樣一個網站，可以讓你對某個文章輸入評論：
    Web安全：XSS、CSRF以及如何防範

1.4 防禦措施

  1. 輸入過濾，避免 XSS 的方法之一主要是将使用者輸入的内容進行過濾。對所有使用者送出内容進行可靠的輸入驗證，包括對 URL、查詢關鍵字、POST資料等，僅接受指定長度範圍内、采用适當格式、采用所預期的字元的内容送出，對其他的一律過濾。(用戶端和伺服器都要)

  2. 輸出轉義

    例如： 往 HTML 标簽之間插入不可信資料的時候，首先要做的就是對不可信資料進行 HTML Entity 編碼 HTML 字元實體

    function htmlEncodeByRegExp  (str){  
         var s = "";
         if(str.length == 0) return "";
         s = str.replace(/&/g,"&");
         s = s.replace(/</g,"&lt;");
         s = s.replace(/>/g,"&gt;");
         s = s.replace(/ /g,"&nbsp;");
         s = s.replace(/\'/g,"&#39;");
         s = s.replace(/\"/g,"&quot;");
         return s;  
 }
var tmpStr="<p>123</p>";   
var html=htmlEncodeByRegExp (tmpStr)
console.log(html) //&lt;p&gt;123&lt;/p&gt;
document.querySelector(".content").innerHTML=html; //<p>123</p>

  3. 使用 HttpOnly Cookie

    将重要的cookie标記為httponly，這樣的話當浏覽器向Web伺服器發起請求的時就會帶上cookie字段，但是在js腳本中卻不能通路這個cookie，這樣就避免了XSS攻擊利用JavaScript的document.cookie擷取cookie。

    現代web開發架構如vue.js、react.js等，在設計的時候就考慮了XSS攻擊對html插值進行了更進一步的抽象、過濾和轉義，我們隻要熟練正确地使用他們，就可以在大部分情況下避免XSS攻擊。

2. CSRF

2.1 定義

CSRF

, 即Cross-site request forgery）中譯是跨站請求僞造；CSRF 顧名思義，是僞造請求，冒充使用者在站内的正常操作。我們知道，絕大多數網站是通過 cookie 等方式辨識使用者身份（包括使用伺服器端 Session 的網站，因為 Session ID 也是大多儲存在 cookie 裡面的），再予以授權的。是以要僞造使用者的正常操作，最好的方法是通過 XSS 或連結欺騙等途徑，讓使用者在本機（即擁有身份 cookie 的浏覽器端）發起使用者所不知道的請求。

Web安全：XSS、CSRF以及如何防範

你可以這樣來了解：

攻擊者盜用了你的身份，以你的名義發送惡意請求，對伺服器來說這個請求是完全合法的，但是卻完成了攻擊者所期望的一個操作，比如以你的名義發送郵件、發消息，盜取你的賬号，添加系統管理者，甚至于購買商品、虛拟貨币轉賬等。 如下：其中Web A為存在CSRF漏洞的網站，Web B為攻擊者建構的惡意網站，User C為Web A網站的合法使用者。

2.2 攻擊原理及過程

  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的惡意代碼被執行。

2.3 舉例

受害者 Bob 在銀行有一筆存款，通過對銀行的網站發送請求

http://bank.example/withdraw?account=bob&amount=1000000&for=bob2

可以使 Bob 把 1000000 的存款轉到 bob2 的賬号下。通常情況下，該請求發送到網站後，伺服器會先驗證該請求是否來自一個合法的 session，并且該 session 的使用者 Bob 已經成功登陸。

​ 黑客 Mallory 自己在該銀行也有賬戶，他知道上文中的 URL 可以把錢進行轉帳操作。Mallory 可以自己發送一個請求給銀行：

http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory

。

但是這個請求來自 Mallory 而非 Bob，他不能通過安全認證，是以該請求不會起作用。

​ 這時，Mallory 想到使用 CSRF 的攻擊方式，他先自己做一個網站，在網站中放入如下代碼：

src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”

，并且通過廣告等誘使 Bob 來通路他的網站。當 Bob 通路該網站時，上述 url 就會從 Bob 的浏覽器發向銀行，而這個請求會附帶 Bob 浏覽器中的 cookie 一起發向銀行伺服器。大多數情況下，該請求會失敗，因為他要求 Bob 的認證資訊。但是，如果 Bob 當時恰巧剛通路他的銀行後不久，他的浏覽器與銀行網站之間的 session 尚未過期，浏覽器的 cookie 之中含有 Bob 的認證資訊。這時，悲劇發生了，這個 url 請求就會得到響應，錢将從 Bob 的賬号轉移到 Mallory 的賬号，而 Bob 當時毫不知情。等以後 Bob 發現賬戶錢少了，即使他去銀行查詢日志，他也隻能發現确實有一個來自于他本人的合法請求轉移了資金，沒有任何被攻擊的痕迹。而 Mallory 則可以拿到錢後逍遙法外。

2.4 防範

① 驗證 HTTP Referer 字段，利用 HTTP 頭中的 Referer 判斷請求來源是否合法，Referer記錄了該 HTTP 請求的來源位址。

優點：簡單易行，隻需要在最後給所有安全敏感的請求統一增加一個攔截器來檢查 Referer 的值就可以。特别是對于目前現有的系統，不需要改變目前系統的任何已有代碼和邏輯，沒有風險，非常便捷。

缺點：Referer 的值是由浏覽器提供的，不可全信，低版本浏覽器下 Referer 存在僞造風險。使用者自己可以設定浏覽器使其在發送請求時不再提供 Referer 時，網站将拒絕合法使用者的通路。

② 在請求位址中添加 token 并驗證。CSRF 攻擊之是以能夠成功，是因為黑客可以完全僞造使用者的請求，該請求中所有的使用者驗證資訊都是存在于 cookie 中，是以黑客可以在不知道這些驗證資訊的情況下直接利用使用者自己的 cookie 來通過安全驗證。要抵禦CSRF，關鍵在于在請求中放入黑客所不能僞造的資訊，并且該資訊不存在于 cookie 之中。可以在 HTTP 請求中以參數的形式加入一個随機産生的 token，并在伺服器端建立一個攔截器來驗證這個 token，如果請求中沒有 token 或者 token 内容不正确，則認為可能是 CSRF 攻擊而拒絕該請求。

優點：這種方法要比檢查 Referer 要安全一些，token 可以在使用者登陸後産生并放于 session 之中，然後在每次請求時把 token 從 session 中拿出，與請求中的 token 進行比對。

缺點：對所有請求都添加 token 比較困難。難以保證 token 本身的安全，依然會被利用擷取到 token。

3. 相關擴充

  1. 結合xss和csrf發起攻擊，xss負責擷取被攻擊者的賬戶資訊，csrf通過賬号資訊僞裝成被攻擊者實施攻擊行為
  2. CSRF 的全稱是“跨站請求僞造”，而 XSS 的全稱是“跨站腳本”。看起來有點相似，它們都是屬于跨站攻擊——不攻擊伺服器端而攻擊正常通路網站的使用者，但它們的攻擊類型是不同次元上的分類。
  3. 伺服器受到DDoS攻擊
html 資料 伺服器端 伺服器 用戶端
上一篇: TypeScript reflect-metadata 結合方法裝飾器實作的一個自定義文法檢查的例子
下一篇: TypeScript Mixins 概念介紹

繼續閱讀