XSS、CSRF/XSRF、CORS介紹

• 1 XSS
• • 1.1 名詞解釋
  • 1.2 作用原理
  • 1.3 防範措施
• 2 CSRF/XSRF
• • 2.1 名詞解釋
  • 2.2 作用原理
  • 2.3 防範措施
  • • 2.3.1 驗證碼
    • 2.3.2 Referer Check
    • 2.3.3 添加 token 驗證(token==令牌)
• 3 CORS
• • 3.1 名詞解釋
  • 3.2 作用原理
  • 3.3 防範措施
  • • 3.3.1 簡單請求
    • 3.3.2 非簡單請求

1 XSS

1.1 名詞解釋

XSS，即：Cross Site Script，中譯是跨站腳本攻擊；其原本縮寫是 CSS，但為了和網站前端技術領域——層疊樣式表(Cascading Style Sheet)有所區分，因而在安全領域叫做 XSS。

1.2 作用原理

XSS是注入攻擊的一種，其特點是不對伺服器端造成任何傷害。

XSS 攻擊是指攻擊者在網站上注入惡意的用戶端代碼，通過惡意腳本對用戶端網頁進行篡改，進而導緻：在使用者浏覽網頁時，如果用戶端浏覽器或者伺服器端沒有過濾或轉義掉這些腳本，而是将其作為内容釋出到了頁面上，則其他使用者通路這個頁面的時候就會運作這些腳本。

攻擊者對用戶端網頁注入的惡意腳本一般包括 JavaScript，有時也會包含 HTML 和 Flash。有很多種方式進行 XSS 攻擊，但它們的共同點為：将一些隐私資料像 cookie、session發送給攻擊者，将受害者重定向到一個由攻擊者控制的網站，在受害者的機器上進行一些惡意操作。

XSS攻擊可以分為3類：反射型（非持久型）、存儲型（持久型）、基于DOM。

1.3 防範措施

我們不需要使用者輸入HTML而隻想讓他們輸入純文字，那麼把所有使用者輸入進行HTML轉義輸出是個不錯的做法。似乎很多 Web 開發架構、模版引擎的開發者也發現了這一點，Django 内置模版和 Jinja2 模版總是預設轉義輸出變量的。

大多數 Web 開發者都了解 XSS 并知道如何防範，往往大型的 XSS 攻擊都是由于疏漏。建議在使用模版引擎的 Web 項目中，開啟（或不要關閉）類似 Django Template、Jinja2 中“預設轉義”（Auto Escape）的功能。在不需要轉義的場合，我們可以用類似 的方式取消轉義。這種白名單式的做法，有助于降低我們由于疏漏留下 XSS 漏洞的風險。

2 CSRF/XSRF

2.1 名詞解釋

CSRF，即：Cross Site Request Forgery，中譯是跨站請求僞造，是一種劫持受信任使用者向伺服器發送非預期請求的攻擊方式。

XSS是實作 CSRF 的諸多途徑中的一條，但絕對不是唯一的一條。一般習慣上把通過 XSS 來實作的 CSRF 稱為 XSRF，即：Cross Site Request Forgery，中譯是跨站請求僞造。

2.2 作用原理

通常情況下，CSRF 攻擊是攻擊者借助受害者的 Cookie 騙取伺服器的信任，可以在受害者毫不知情的情況下以受害者名義僞造請求發送給受攻擊伺服器，進而在并未授權的情況下執行在權限保護之下的操作。

CSRF 并不一定要有站内的輸入，因為它并不屬于注入攻擊，而是請求僞造。被僞造的請求可以是任何來源，而并不一定都是站内。是以我們唯有一條路可行，就是過濾請求的處理者。

2.3 防範措施

目前，對 CSRF 攻擊的防範措施主要有如下幾種方式。

2.3.1 驗證碼

驗證碼被認為是對抗 CSRF 攻擊最簡潔而有效的防禦方法。

CSRF 攻擊往往是在使用者不知情的情況下構造了網絡請求。而驗證碼會強制使用者必須與應用進行互動，才能完成最終請求。因為通常情況下，驗證碼能夠很好地遏制 CSRF 攻擊。

但驗證碼并不是萬能的，因為出于使用者考慮，不能給網站所有的操作都加上驗證碼。是以，驗證碼隻能作為防禦 CSRF 的一種輔助手段，而不能作為最主要的解決方案。

2.3.2 Referer Check

根據 HTTP 協定，在 HTTP 頭中有一個字段叫 Referer，它記錄了該 HTTP 請求的來源位址。通過 Referer Check，可以檢查請求是否來自合法的”源”。

比如，如果使用者要删除自己的文章，那麼先要登入 www.c.com，然後找到對應的頁面，發起删除文章的請求。此時，Referer 的值是 http://www.c.com；當請求是從 www.a.com 發起時，Referer 的值是 http://www.a.com 了。是以，要防禦 CSRF 攻擊，隻需要對于每一個删帖請求驗證其 Referer 值，如果是以 www.c.com 開頭的域名，則說明該請求是來自網站自己的請求，是合法的。如果 Referer 是其他網站的話，則有可能是 CSRF 攻擊，可以拒絕該請求。

對于釋出文章這一類建立資源的操作，應該隻接受 POST 請求，而 GET 請求應該隻浏覽而不改變伺服器端資源。當然，最理想的做法是使用REST風格的API接口設計，GET、POST、PUT、DELETE 四種請求方法對應資源的讀取、建立、修改、删除。現在的浏覽器基本不支援在表單中使用 PUT 和 DELETE請求方法，我們可以使用ajax送出請求。也可以使用隐藏域指定請求方法，然後用POST模拟PUT和DELETE（Ruby on Rails 的做法）。這麼一來，不同的資源操作區分的非常清楚。

2.3.3 添加 token 驗證(token==令牌)

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

3 CORS

3.1 名詞解釋

CORS是一個W3C标準，全稱是”跨域資源共享”（Cross-origin resource sharing）。它允許浏覽器向跨源伺服器，發出XMLHttpRequest請求，進而克服了AJAX隻能同源使用的限制。

3.2 作用原理

由于跨域通路的允許，是以，即使伺服器本機域上阻止了XSS威脅，攻擊者還可以利用其他任意子域上XSS漏洞（如客戶第三方業

務系統），發送跨域請求到目标重要域網站，進而擷取敏感内容。

3.3 防範措施

現代浏覽器預設都會基于安全原因而阻止跨域的ajax請求，這是現代浏覽器中必備的功能，但是往往給開發帶來不便。

浏覽器将CORS請求分成兩類：簡單請求（simple request）和非簡單請求(not-so-simple request)。

3.3.1 簡單請求

對于簡單請求，浏覽器直接發出CORS請求。具體來說，就是在頭資訊之中，增加一個Origin字段。

Origin字段用來說明，本次請求來自哪個源（協定 + 域名 + 端口）。伺服器根據這個值，決定是否同意這次請求。

3.3.2 非簡單請求

非簡單請求是那種對伺服器有特殊要求的請求，比如請求方法是PUT或DELETE，或者Content-Type字段的類型是application/json。

浏覽器發現，這是一個非簡單請求，就自動發出一個”預檢”請求，要求伺服器确認可以這樣請求。

“預檢”請求用的請求方法是OPTIONS，表示這個請求是用來詢問的。頭資訊裡面，關鍵字段是Origin，表示請求來自哪個源。

除了Origin字段，”預檢”請求的頭資訊包括兩個特殊字段。

—————————————————————————————

參考文獻：

【1】https://blog.csdn.net/ccyutaotao/article/details/78348567；

【2】https://blog.csdn.net/luojinbai/article/details/50763182.