本文主要介紹了 XSS 和 CSRF 的攻擊原理和防御措施及兩者區別。接下來我們來了解下。
XSS
一、XSS原理
Xss(cross-site scripting)攻擊：通過向某網站寫入js腳本或插入惡意 html標簽來實現攻擊。
比如：攻擊者在論壇中放一個看似安全的鏈接，騙取用戶點擊后，竊取cookie中的用戶私密信息；
或者攻擊者在論壇中加一個惡意表單，當用戶提交表單的時候，卻把信息傳送到攻擊者的服務器中，而不是用戶原本以為的信任站點。
二、XSS攻擊的類型
分為存儲性（持久型）、反射型（非持久型）、基於DOM
1、存儲性（持久型）
用戶輸入的帶有惡意腳本的數據存儲在服務器端。當瀏覽器請求數據時，服務器返回腳本並執行。
常見的場景：
攻擊者在社區或論壇上寫下一篇包含惡意 Js代碼的文章或評論，文章或評論發表后，所有訪問該文章或評論的用戶，都會在他們的瀏覽器中執行這段惡意的 JavaScript 代碼。
2、反射型（非持久型）
把用戶輸入的數據"反射"給瀏覽器。通常是，用戶點擊鏈接或提交表單時，攻擊者向用戶訪問的網站注入惡意腳本。
常見的場景：
在正常頁面上添加一個惡意鏈接。惡意鏈接的地址指向localhost:8080。然后攻擊者有一個node服務來處理對localhost:8080的請求:
當用戶點擊惡意鏈接時，頁面跳轉到攻擊者預先准備的localhost:8080頁面，執行了 惡意的js 腳本，產生攻擊。
3、基於DOM
基於DOM的XSS是指通過惡意腳本修改頁面的DOM結構。是純粹發生在 客戶端的攻擊。
三、XSS防范方法
1) 內容安全策略 (CSP) -（https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CSP）
它是一個額外的安全層，用於檢測並削弱某些特定類型的攻擊，包括跨站腳本 (XSS) 和數據注入攻擊等。無論是數據盜取、網站內容污染還是散發惡意軟件，這些攻擊都是主要的手段。
其實質就是白名單制度，開發者明確告訴客戶端，哪些外部資源可以加載和執行，等同於提供白名單。它的實現和執行全部由瀏覽器完成，開發者只需提供配置。
兩種方法可以啟用 CSP：
- 設置 HTTP 的
Content-Security-Policy頭部字段 - 設置網頁的<meta>標簽。
服務器端Set-Cookie字段設置HttpOnly參數，這樣可以避免。（想了解Set-Cookie, 可參考https://www.cnblogs.com/renzm0318/p/11643841.html)
這時候，客戶端的Document.cookie API無法訪問帶有 HttpOnly 標記的Cookie, 但可以設置cookie。
注：發起XSS的攻擊者既然可以通過注入惡意腳本獲取用戶的 Cookie 信息。
所以，嚴格來說，HttpOnly 並非阻止 XSS 攻擊，而是能阻止 XSS 攻擊后的 Cookie 劫持攻擊。
CSRF
一、CSRF原理
CSRF(Cross Site Request Forgery)，跨站請求偽造。
CSRF 攻擊是攻擊者借助用戶的 Cookie 騙取服務器的信任，以用戶名義偽造請求發送給服務器。如：在請求的url后加入一些惡意的參數
換句話說，CSRF就是利用用戶的登錄態發起惡意請求。
場景：
假設某銀行網站A以GET請求來發起轉賬操作，轉賬的地址為www.xxx.com/transfer.do?accountNum=l000l&money=10000，參數accountNum表示轉賬的賬戶，參數money表示轉賬金額。
而某大型論壇B上，一個惡意用戶上傳了一張圖片，而圖片的地址欄中填的並不是圖片的地址，而是前而所說的磚賬地址：<img src="http://www.xxx.com/transfer.do?accountNum=l000l&money=10000">
當你登錄網站A后，沒有及時登出，這時你訪問了論壇B，不幸的事情發生了，你會發現你的賬號里面少了10000塊...
上述只是舉例呦，轉賬怎么可能是get請求，為了保險，肯定是post請求，更何況銀行的交易付款會有登錄密碼和支付密碼等一系列屏障，流程復雜得多，安全系數也高得多
二、CSRF防范
1、添加 token 驗證
在 HTTP 請求中以參數的形式加入一個隨機產生的 token，並在服務器端建立一個攔截器來驗證這個 token，若請求無 token 或者 token 不正確，則認為可能是 CSRF 攻擊而拒絕該請求。
2、Referer Check
在HTTP頭中有一個字段叫做Referer,它記錄了該HTTP請求的來源地址。通過Referer Check,可以檢查是否來自合法的"源".
例如：
從www.user.com發起的刪帖請求，那么Referer值是http://www.user.com, 刪帖請求應該被允許；
而如果是從CSRF攻擊者構造的頁面www.attack.com發起刪帖請求， 那么Referer值是http://www.attack.com, 刪帖請求應該被阻止。
3、驗證碼
驗證碼會強制用戶必須與應用進行交互，才能完成最終請求，但是也不能給網站所有的操作都加上驗證碼，所以只能作為防御 CSRF 的一種輔助手段，而不能作為最終的解決方案
XSS和CSRF區別：
- XSS是利用用戶對指定網站的信任
- CSRF是利用網站對用戶的信任