詳記CSRF攻擊與XSS攻擊

原文鏈接：https://segmentfault.com/a/1190000020285558

一、CSRF（跨站請求僞造）

是一種挾制用戶在當前已登錄的Web應用程序上執行非本意的操作的攻擊方法。

1、攻擊過程

跨站請求攻擊，簡單地說，是攻擊者通過一些技術手段欺騙用戶的瀏覽器去訪問一個自己曾經認證過的網站並運行一些操作（如發郵件，發消息，甚至財產操作如轉賬和購買商品）。這個過程可以這樣來看：

• 用戶登錄了sueRimn.com，並保留了登錄憑證（Cookie）
• 攻擊者引誘用戶點擊訪問了sb.com（用戶自身不知道）
• sb.com向sue.com發送請求：sue.com/act=xx，瀏覽器會默認攜帶sue.com的cookie
• sue.com接收到請求後，對請求進行驗證，發現是曾經用戶保留的cookie，誤以爲是用戶本人操作，然後允許了執行請求
• 在用戶不知情的情況下，攻擊者暗地完成了自己的攻擊操作

可見完成一次CSRF攻擊，用戶必須依次存在着兩個操作：

• 登錄信任網站A，並保存Cookie
• 在不登出網站A的情況下，點擊危險網站B

由於瀏覽器曾經認證過，所以被訪問的網站會認爲是真正的用戶操作而去運行。這利用了web中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求本身是用戶自願發出的。

攻擊者並不能通過CSRF攻擊來直接獲取用戶的賬戶控制權，也不能直接竊取用戶的任何信息。他們能做到的，是欺騙用戶瀏覽器，讓其以用戶的名義運行操作。

2、CSRF特點

• 攻擊一般發起在第三方網站，而不是被攻擊的網站。被攻擊的網站無法防止攻擊發生
• 攻擊利用受害者在被攻擊網站的登錄憑證，冒充受害者提交操作；而不是直接竊取數據
• 整個過程攻擊者並不能獲取到受害者的登錄憑證，僅僅是“冒用”
• 跨站請求可以用各種方式：圖片URL、超鏈接、CORS、Form提交等等。部分請求方式可以直接嵌入在第三方論壇、文章中，難以進行追蹤

CSRF通常是跨域的，因爲外域通常更容易被攻擊者掌控。但是如果本域下有容易被利用的功能，比如可以發圖和鏈接的論壇和評論區，攻擊可以直接在本域下進行，而且這種攻擊更加危險。

3、常見CSRF攻擊類型

（1）GET類型

GET類型的CSRF利用非常簡單，只需要一個HTTP請求，一般會這樣利用：

<img src="http://bank.example/withdraw?amount=10000&for=hacker" > 

在受害者訪問含有這個img的頁面後，瀏覽器會自動向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker發出一次HTTP請求。bank.example就會收到包含受害者登錄信息的一次跨域請求。

（2）POST類型

這種類型的CSRF利用起來通常使用的是一個自動提交的表單，如：

 <form action="http://bank.example/withdraw" method=POST>
    <input type="hidden" name="account" value="xiaoming" />
    <input type="hidden" name="amount" value="10000" />
    <input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script> 

訪問該頁面後，表單會自動提交，相當於模擬用戶完成了一次POST操作。

POST類型的攻擊通常比GET要求更加嚴格一點，但仍並不複雜。任何個人網站、博客，被黑客上傳頁面的網站都有可能是發起攻擊的來源，後端接口不能將安全寄託在僅允許POST上面。

（3）鏈接類型

鏈接類型的CSRF並不常見，比起其他兩種用戶打開頁面就中招的情況，這種需要用戶點擊鏈接纔會觸發。這種類型通常是在論壇中發佈的圖片中嵌入惡意鏈接，或者以廣告的形式誘導用戶中招，攻擊者通常會以比較誇張的詞語誘騙用戶點擊，例如：

 <a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">
  重磅消息！！
  <a/>

由於之前用戶登錄了信任的網站A，並且保存登錄狀態，只要用戶主動訪問上面的這個PHP頁面，則表示攻擊成功。

4、防禦措施

CSRF通常從第三方網站發起，被攻擊的網站無法防止攻擊發生，只能通過增強自己網站針對CSRF的防護能力來提升安全性。

上文中講了CSRF的兩個特點：

• CSRF（通常）發生在第三方域名
• CSRF攻擊者不能獲取到Cookie等信息，只是使用

針對以上兩個特點制定兩個反向的防禦措施，如下：

（1）阻止不明外域的訪問

主要的方式有：

• 同源檢測
• Samesite Cookie

1）同源檢測

既然CSRF大多來自第三方網站，那麼我們就直接禁止外域（或者不受信任的域名）對我們發起請求。

那麼問題來了，我們如何判斷請求是否來自外域呢？

在HTTP協議中，每一個異步請求都會攜帶兩個Header，用於標記來源域名：

• Origin Header
• Referer Header

這兩個Header在瀏覽器發起請求時，大多數情況會自動帶上，並且不能由前端自定義內容。 服務器可以通過解析這兩個Header中的域名，確定請求的來源域。

使用Origin Header確定來源域名

在部分與CSRF有關的請求中，請求的Header中會攜帶Origin字段。字段內包含請求的域名（不包含path及query）。

如果Origin存在，那麼直接使用Origin中的字段確認來源域名就可以。

但是Origin在以下兩種情況下並不存在：

• IE11同源策略：
• 302重定向：

檢查Referer字段

HTTP頭中有一個Referer字段，這個字段用以標明請求來源於哪個地址。在處理敏感數據請求時，通常來說，Referer字段應和請求的地址位於同一域名下。

這種辦法簡單易行，工作量低，僅需要在關鍵訪問處增加一步校驗。但這種辦法也有其侷限性，因其完全依賴瀏覽器發送正確的Referer字段。雖然http協議對此字段的內容有明確的規定，但並無法保證來訪的瀏覽器的具體實現，亦無法保證瀏覽器沒有安全漏洞影響到此字段。並且也存在攻擊者攻擊某些瀏覽器，篡改其Referer字段的可能。

設置Referrer Policy的方法有三種：

1. 在CSP設置
2. 頁面頭部增加meta標籤
3. a標籤增加referrerpolicy屬性

上面說的這些比較多，但我們可以知道一個問題：攻擊者可以在自己的請求中隱藏Referer。如果攻擊者將自己的請求這樣填寫，這個請求發起的攻擊將不攜帶Referer：

![](https://awps-assets.meituan.net/mit-x/blog-images-bundle-2018b/ff0cdbee.example/withdraw?amount=10000&for=hacker)

另外在以下情況下Referer沒有或者不可信：

1. IE6、7下使用window.location.href=url進行界面的跳轉，會丟失Referer
2. IE6、7下使用window.open，也會缺失Referer
3. HTTPS頁面跳轉到HTTP頁面，所有瀏覽器Referer都丟失
4. 點擊Flash上到達另外一個網站的時候，Referer的情況就比較雜亂，不太可信

綜上所述：同源驗證是一個相對簡單的防範方法，能夠防範絕大多數的CSRF攻擊。但這並不是萬無一失的，對於安全性要求較高，或者有較多用戶輸入內容的網站，我們就要對關鍵的接口做額外的防護措施。

2）Samesite Cookie屬性

爲了從源頭上解決這個問題，Google起草了一份草案來改進HTTP協議，那就是爲Set-Cookie響應頭新增Samesite屬性，它用來標明這個 Cookie是個“同站 Cookie"，同站Cookie只能作爲第一方Cookie，不能作爲第三方Cookie，Samesite有兩個屬性值，分別是Strict和 Lax

（2）提交時要求附加本域才能獲取的信息

1）添加校驗token

由於CSRF的本質在於攻擊者欺騙用戶去訪問自己設置的地址，所以如果要求在訪問敏感數據請求時，要求用戶瀏覽器提供不保存在cookie中，並且攻擊者無法僞造的數據作爲校驗，那麼攻擊者就無法再運行CSRF攻擊。

CSRF Token的防護策略分爲三個步驟：

• 將CSRF Token輸出到頁面中
• 頁面提交的請求攜帶這個Token
• 服務器驗證Token是否正確

2）雙重Cookie驗證

在會話中存儲CSRF Token比較繁瑣，而且不能在通用的攔截上統一處理所有的接口。

那麼另一種防禦措施是使用雙重提交Cookie。利用CSRF攻擊不能獲取到用戶Cookie的特點，我們可以要求Ajax和表單請求攜帶一個Cookie中的值。

雙重Cookie採用以下流程：

• 在用戶訪問網站頁面時，向請求域名注入一個Cookie，內容爲隨機字符串（例如csrfcookie=v8g9e4ksfhw）。
• 在前端向後端發起請求時，取出Cookie，並添加到URL的參數中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。
• 後端接口驗證Cookie中的字段與URL參數中的字段是否一致，不一致則拒絕。

雙重Cookie防禦CSRF的優缺點：

• 優點：
  • 無需使用Session，適用面更廣，易於實施
  • Token儲存於客戶端中，不會給服務器帶來壓力
  • 相對於Token，實施成本更低，可以在前後端統一攔截校驗，而不需要一個個接口和頁面添加
• 缺點：
  • Cookie中增加了額外的字段
  • 如果有其他漏洞（例如XSS），攻擊者可以注入Cookie，那麼該防禦方式失效
  • 難以做到子域名的隔離
  • 爲了確保Cookie傳輸安全，採用這種防禦方式的最好確保用整站HTTPS的方式，如果還沒切HTTPS的使用這種方式也會有風險

（3）其他防禦措施

1）CSRF測試

步驟：

• 1：設置瀏覽器代理
• 2：使用合法賬戶訪問網站開始測試
• 3：通過CSRF修改並僞造請求
• 4：拿到結果如有漏洞進行修復

2）CSRF監控

CSRF攻擊有着比較明顯的特徵：

• 跨域請求。
• GET類型請求Header的MIME類型大概率爲圖片，而實際返回Header的MIME類型爲Text、JSON、HTML。

在網站的代理層監控所有的接口請求，如果請求符合上面的特徵，就可以認爲請求有CSRF攻擊嫌疑。我們可以提醒對應的頁面和項目負責人，檢查或者 Review其CSRF防護策略。

5、CSRF攻擊簡單總結

• CSRF自動防禦策略：同源檢測（Origin和Referer 驗證）
• CSRF主動防禦措施：Token驗證 或者 雙重Cookie驗證 以及配合Samesite Cookie
• 保證頁面的冪等性，後端接口不要在GET頁面中做用戶操作

二、XSS（跨站腳本攻擊）

XSS攻擊是指在用戶在訪問信任的網站時注入惡意攻擊腳本（主要是JavaScript），對客戶端網頁進行篡改，對用戶瀏覽器進行控制或者獲取用戶隱私數據的一種攻擊方式。

攻擊者對客戶端網頁注入的惡意腳本一般包括 JavaScript，有時也會包含HTML 和Flash。有很多種方式進行XSS攻擊，但它們的共同點爲：獲取用戶隱私數據像 cookie、session，進行一些惡意操作。

用戶是通過哪種方法“注入”惡意腳本的呢？

不僅僅是業務上的“用戶的 UGC內容”可以進行注入，包括URL 上的參數等都可以是攻擊的來源。在處理輸入時，以下內容都不可信：

• 來自用戶的 UGC 信息
• 來自第三方的鏈接
• URL參數
• POST 參數
• Referer（可能來自不可信的來源）
• Cookie（可能來自其他子域注入）

1、XSS注入方式

• 在HTML中內嵌的文本中，惡意內容以script標籤形成注入。
• 在內聯的JavaScript中，拼接的數據突破了原本的限制（字符串，變量，方法名等）。
• 在標籤屬性中，惡意內容包含引號，從而突破屬性值的限制，注入其他屬性或者標籤。
• 在標籤的 href、src等屬性中，包含 javascript: 等可執行代碼。
• 在 onload、onerror、onclick等事件中，注入不受控制代碼。
• 在style 屬性和標籤中，包含類似 background-image:url("javascript:..."); 的代碼（新版本瀏覽器已經可以防範）。
• 在 style 屬性和標籤中，包含類似 expression(...) 的 CSS 表達式代碼（新版本瀏覽器已經可以防範）。

總之，如果開發者沒有將用戶輸入的文本進行合適的過濾，就貿然插入到 HTML 中，這很容易造成注入漏洞。攻擊者可以利用漏洞，構造出惡意的代碼指令，進而利用惡意代碼危害數據安全。

2、XSS攻擊的分類

根據攻擊的來源，XSS攻擊可分爲存儲型、反射型和 DOM型三種。

（1）存儲型XSS

存儲型 XSS 的攻擊步驟：

1. 攻擊者將惡意代碼提交到目標網站的數據庫中。
2. 用戶打開目標網站時，網站服務端將惡意代碼從數據庫取出，拼接在 HTML 中返回給瀏覽器。
3. 用戶瀏覽器接收到響應後解析執行，混在其中的惡意代碼也被執行。
4. 惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操作。

這種攻擊常見於帶有用戶保存數據的網站功能，如論壇發帖、商品評論、用戶私信等。

（2）反射型XSS

反射型XSS的攻擊步驟：

1. 攻擊者構造出特殊的URL，其中包含惡意代碼。
2. 用戶打開帶有惡意代碼的URL時，網站服務端將惡意代碼從URL中取出，拼接在 HTML中返回給瀏覽器。
3. 用戶瀏覽器接收到響應後解析執行，混在其中的惡意代碼也被執行。
4. 惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操作。

反射型 XSS 跟存儲型 XSS的區別是：存儲型 XSS的惡意代碼存在數據庫裏，反射型 XSS 的惡意代碼存在 URL裏。

反射型 XSS 漏洞常見於通過URL 傳遞參數的功能，如網站搜索、跳轉等。

由於需要用戶主動打開惡意的 URL 才能生效，攻擊者往往會結合多種手段誘導用戶點擊。

POST 的內容也可以觸發反射型 XSS，只不過其觸發條件比較苛刻（需要構造表單提交頁面，並引導用戶點擊），所以非常少見。

（3）DOM型XSS

DOM型 XSS的攻擊步驟：

1. 攻擊者構造出特殊的URL，其中包含惡意代碼。
2. 用戶打開帶有惡意代碼的URL。
3. 用戶瀏覽器接收到響應後解析執行，前端 JavaScript 取出 URL中的惡意代碼並執行。
4. 惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操作。

DOM型 XSS跟前兩種 XSS的區別：DOM 型 XSS攻擊中，取出和執行惡意代碼由瀏覽器端完成，不需要服務器解析響應的直接參與，屬於前端 JavaScript自身的安全漏洞，而其他兩種 XSS 都屬於服務端的安全漏洞。

對比表格

XSS攻擊類型	存儲位置	插入點
存儲型XSS	後端數據庫	HTML
反射型XSS	URL	HTML
DOM型XSS	後端數據庫/前端存儲/URL	前端JavaScript

3、XSS攻擊的防禦措施

（1）輸入過濾

只要有輸入數據的地方，就存在XSS攻擊，XSS攻擊就有兩大因素：

• 攻擊者提交惡意代碼
• 瀏覽器執行惡意代碼

所以，防禦措施主要從這兩個方面下手：

針對用戶輸入過程

在用戶輸入過程中，前端過濾輸入的惡意代碼，然後再提交給後端，這是不可行的，攻擊者完全可以繞過前端過濾，直接構造請求提交惡意代碼。

對於明確的輸入類型，例如數字、URL、電話號碼、郵件地址等等內容，進行輸入過濾是必要的。

所以不僅需要前端對輸入的格式進行格式檢查，然後後端做相關的過濾檢查。

針對瀏覽器執行惡意代碼

輸入過濾不是萬全之策，那就要防止瀏覽器執行惡意代碼，這個分爲兩步進行：

• 防止HTML中出現注入
• 防止JavaScript執行時，執行惡意代碼

（2）預防存儲型和反射型XSS攻擊

存儲型和反射型 XSS 都是在服務端取出惡意代碼後，插入到響應 HTML裏的，攻擊者刻意編寫的“數據”被內嵌到“代碼”中，被瀏覽器所執行。

預防這兩種漏洞，有兩種常見做法：

• 純前端渲染，代碼和數據分離
• 轉義HTML

1）純前端渲染

純前端渲染的過程：

1. 瀏覽器先加載一個靜態 HTML，此 HTML 中不包含任何跟業務相關的數據
2. 然後瀏覽器執行 HTML中的 JavaScript
3. JavaScript通過 Ajax加載業務數據，調用 DOM API更新到頁面上

在純前端渲染中，會明確的告訴瀏覽器：下面要設置的內容是文本（.innerText），還是屬性（.setAttribute），還是樣式（.style）等等。瀏覽器不會被輕易的被欺騙，執行預期外的代碼了。

但純前端渲染還需注意避免DOM型 XSS漏洞（例如 onload 事件和 href 中的 javascript:xxx 等，請參考下文”預防 DOM 型 XSS 攻擊“部分）。

在很多內部、管理系統中，採用純前端渲染是非常合適的。但對於性能要求高，或有 SEO 需求的頁面，我們仍然要面對拼接 HTML的問題。

2）轉義HTML

如果拼接 HTML 是必要的，就需要採用合適的轉義庫，對 HTML模板各處插入點進行充分的轉義。

常用的模板引擎，如 doT.js、ejs、FreeMarker 等，對於 HTML轉義通常只有一個規則，就是把 & < > " ' / 這幾個字符轉義掉，確實能起到一定的 XSS防護作用，但並不完善：

|XSS 安全漏洞|簡單轉義是否有防護作用| |-|-| |HTML 標籤文字內容|有| |HTML 屬性值|有| |CSS 內聯樣式|無| |內聯 JavaScript|無| |內聯 JSON|無| |跳轉鏈接|無|

所以要完善 XSS 防護措施，我們要使用更完善更細緻的轉義策略。

（3）預防DOM型XSS攻擊

DOM型XSS攻擊，實際上就是網站前端JavaScript代碼本身不夠嚴謹，把不可信的數據當作代碼執行了。

在使用 .innerHTML、.outerHTML、document.write() 時要特別小心，不要把不可信的數據作爲 HTML 插到頁面上，而應儘量使用 .textContent、.setAttribute() 等。

如果用 Vue/React 技術棧，並且不使用 v-html/dangerouslySetInnerHTML 功能，就在前端 render 階段避免 innerHTML、outerHTML 的 XSS 隱患。

DOM 中的內聯事件監聽器，如 location、onclick、onerror、onload、onmouseover 等，<a> 標籤的 href 屬性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作爲代碼運行。如果不可信的數據拼接到字符串中傳遞給這些 API，很容易產生安全隱患，請務必避免。

<!-- 內聯事件監聽器中包含惡意代碼 -->
![](https://awps-assets.meituan.net/mit-x/blog-images-bundle-2018b/3e724ce0.data:image/png,)

<!-- 鏈接內包含惡意代碼 -->
<a href="UNTRUSTED">1</a>

<script>
// setTimeout()/setInterval() 中調用惡意代碼
setTimeout("UNTRUSTED")
setInterval("UNTRUSTED")

// location 調用惡意代碼
location.href = 'UNTRUSTED'

// eval() 中調用惡意代碼
eval("UNTRUSTED")
</script>

（4）其他防禦措施

雖然在渲染頁面和執行JavaScript 時，通過謹慎的轉義可以防止XSS的發生，但完全依靠開發的謹慎仍然是不夠的。以下介紹一些通用的方案，可以降低 XSS 帶來的風險和後果。

1）Content Security Policy

嚴格的 CSP在 XSS的防範中可以起到以下的作用：

• 禁止加載外域代碼，防止複雜的攻擊邏輯。
• 禁止外域提交，網站被攻擊後，用戶的數據不會泄露到外域。
• 禁止內聯腳本執行（規則較嚴格，目前發現 GitHub使用）。
• 禁止未授權的腳本執行（新特性，Google Map移動版在使用）。
• 合理使用上報可以及時發現 XSS，利於儘快修復問題。

2）輸入內容長度控制

對於不受信任的輸入，都應該限定一個合理的長度。雖然無法完全防止XSS發生，但可以增加XSS 攻擊的難度。

3）其他

• HTTP-only Cookie: 禁止 JavaScript 讀取某些敏感 Cookie，攻擊者完成 XSS 注入後也無法竊取此 Cookie
• 驗證碼：防止腳本冒充用戶提交危險操作
• 白名單: 對於顯示富文本來說，不能通過上面的辦法來轉義所有字符，因爲這樣會把需要的格式也過濾掉。這種情況通常採用白名單過濾的辦法，當然也可以通過黑名單過濾，但是考慮到需要過濾的標籤和標籤屬性實在太多，更加推薦使用白名單的方式

4、XSS攻擊檢測

兩種方法：

（1）使用通用 XSS攻擊字符串手動檢測XSS漏洞

jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e

這個字符串能夠檢測到存在於 HTML 屬性、HTML文字內容、HTML註釋、跳轉鏈接、內聯 JavaScript字符串、內聯CSS樣式表等多種上下文中的 XSS漏洞，也能檢測 eval()、setTimeout()、setInterval()、Function()、innerHTML、document.write() 等 DOM 型 XSS漏洞，並且能繞過一些 XSS過濾器。

只要在網站的各輸入框中提交這個字符串，或者把它拼接到 URL 參數上，就可以進行檢測了。

http://xxx/search?keyword=jaVasCript%3A%2F*-%2F*%60%2F*%60%2F*%27%2F*%22%2F**%2F(%2F*%20*%2FoNcliCk%3Dalert()%20)%2F%2F%250D%250A%250d%250a%2F%2F%3C%2FstYle%2F%3C%2FtitLe%2F%3C%2FteXtarEa%2F%3C%2FscRipt%2F--!%3E%3CsVg%2F%3CsVg%2FoNloAd%3Dalert()%2F%2F%3E%3E

（2）使用掃描工具自動檢測 XSS 漏洞

常見自動掃描工具尋找 XSS 漏洞，例如 Arachni、Mozilla HTTP Observatory、w3af 等

5、XSS攻擊簡單總結

• 防禦存儲型和反射型 XSS 是後端的責任。而 DOM 型XSS是前端 的責任。防禦XSS是需要後端和前端共同參與的系統工程
• 轉義應該在輸出 HTML時進行，而不是在提交用戶輸入時
• 不同的上下文，如HTML屬性、HTML文字內容、HTML註釋、跳轉鏈接、內聯 JavaScript字符串、內聯CSS樣式表等，所需要的轉義規則不一致。 業務 需要選取合適的轉義庫，並針對不同的上下文調用不同的轉義規則
• 不僅需要在全部需要轉義的位置，對數據進行對應的轉義。而且要防止多餘和錯誤的轉義，避免正常的用戶輸入出現亂碼
• 總結以下原則減少漏洞的產生：
  • 利用模板引擎 ：開啓模板引擎自帶的HTML轉義功能。例如：
    • 在ejs 中，儘量使用 <%= data %> 而不是 <%- data %>
    • 在 doT.js中，儘量使用 {{! data } 而不是 {{= data }
    • 在 FreeMarker 中，確保引擎版本高於 2.3.24，並且選擇正確的 freemarker.core.OutputFormat
  • 避免內聯事件： 儘量不要使用 onLoad="onload('{{data}}')"、onClick="go('{{action}}')" 這種拼接內聯事件的寫法。在 JavaScript中通過 .addEventlistener() 事件綁定會更安全
  • 避免拼接 HTML ：前端採用拼接 HTML的方法比較危險，如果框架允許，使用 createElement、setAttribute 之類的方法實現。或者採用比較成熟的渲染框架，如 Vue/React等
  • 時刻保持警惕 ：在插入位置爲 DOM屬性、鏈接等位置時，要打起精神，嚴加防範
  • 增加攻擊難度，降低攻擊後果 ：通過CSP、輸入長度配置、接口安全措施等方法，增加攻擊的難度，降低攻擊的後果
  • 主動檢測和發現： 可使用XSS攻擊字符串和自動掃描工具尋找潛在的XSS漏洞

三、區別

XSS利用的是用戶對網站的信任，CSRF利用的是網站對用戶網頁瀏覽器的信任。

參考文章：

前端安全系列（一）：如何防止XSS攻擊

前端安全系列（二）：如何防止CSRF攻擊

前端面試查漏補缺–（七）XSS攻擊魚CSRF攻擊