CSRF（跨站請求偽造）概述
CSRF（Cross-Site Request Forgery），即跨站請求偽造，是一種攻擊手段，攻擊者利用受害者在網(wǎng)站上已認(rèn)證的身份信息，誘使受害者發(fā)起未經(jīng)授權(quán)的請求，從而對受害者賬戶執(zhí)行不希望的操作。由于受害者的身份信息（如cookie）會(huì)自動(dòng)隨請求發(fā)送，攻擊者可以借此執(zhí)行一些惡意操作。
CSRF攻擊原理

1.攻擊者準(zhǔn)備惡意請求：攻擊者構(gòu)造一個(gè)惡意的請求，例如修改密碼、轉(zhuǎn)賬等，通常這個(gè)請求會(huì)嵌入到一個(gè)網(wǎng)站、郵件或網(wǎng)頁廣告等地方。該請求通常是向一個(gè)已經(jīng)登錄的用戶所訪問的站點(diǎn)發(fā)起的。
2.受害者訪問惡意頁面：受害者無意間訪問了這個(gè)惡意頁面，通常這個(gè)頁面會(huì)包含惡意的鏈接、表單、圖片等，可能通過 XSS 或社交工程學(xué)等方式誘使受害者點(diǎn)擊或加載。
3.瀏覽器自動(dòng)發(fā)送請求：當(dāng)受害者訪問該惡意頁面時(shí)，瀏覽器會(huì)攜帶當(dāng)前登錄用戶的認(rèn)證信息（如cookie）自動(dòng)發(fā)送請求。例如，如果用戶已經(jīng)登錄了某個(gè)銀行網(wǎng)站，惡意請求可能會(huì)是一個(gè)轉(zhuǎn)賬請求，瀏覽器會(huì)自動(dòng)帶上該銀行網(wǎng)站的登錄cookie。
4.惡意請求執(zhí)行：由于請求看似是合法用戶發(fā)起的，服務(wù)器無法識別請求的真正來源，最終執(zhí)行了攻擊者預(yù)設(shè)的操作。

CSRF的攻擊場景

5.用戶在登錄狀態(tài)下，點(diǎn)擊攻擊者精心設(shè)計(jì)的惡意鏈接。
6.惡意鏈接會(huì)以用戶的名義向受害者已經(jīng)登錄的網(wǎng)站發(fā)起請求，執(zhí)行一些危害性操作（如修改用戶資料、轉(zhuǎn)賬、提交表單等）。

例如，假設(shè)攻擊者希望在一個(gè)受害者的賬戶上轉(zhuǎn)賬，攻擊者可以構(gòu)造如下的惡意鏈接：
<img src="http://bank.com/transfer?amount=1000&toAccount=attackerAccount" />

當(dāng)受害者訪問此鏈接時(shí)，瀏覽器會(huì)自動(dòng)發(fā)送請求，且該請求帶有受害者的身份認(rèn)證信息（如cookie），因此服務(wù)器會(huì)認(rèn)為這是合法的請求并執(zhí)行。
CSRF的預(yù)防措施
為了防止CSRF攻擊，通常采取以下幾種策略：
1. 使用Token防護(hù)（Anti-CSRF Token）

7.原理：每當(dāng)用戶發(fā)起請求時(shí)，服務(wù)器會(huì)在頁面中插入一個(gè)隨機(jī)的token，這個(gè)token是一個(gè)難以猜測的唯一標(biāo)識符。每次用戶發(fā)起請求時(shí)，都會(huì)將該token與請求一起發(fā)送，服務(wù)器根據(jù)token來驗(yàn)證請求是否合法。
8.實(shí)現(xiàn)方式：在表單中加入一個(gè)隱藏的字段，包含服務(wù)器生成的token，每次請求時(shí)客戶端必須發(fā)送這個(gè)token。服務(wù)器驗(yàn)證請求中的token與當(dāng)前會(huì)話中的token是否一致，如果不一致則拒絕請求。
例如，在HTML表單中插入一個(gè)隱藏的token字段：

? ?<form method="POST" action="/transfer">
? ? ? ?<input type="hidden" name="csrf_token" value="randomGeneratedToken">
? ? ? ?<input type="text" name="amount" value="1000">
? ? ? ?<input type="text" name="toAccount" value="1234567890">
? ? ? ?<input type="submit" value="Transfer">
? ?</form>

每次提交時(shí)，服務(wù)器會(huì)驗(yàn)證 csrf_token 是否與用戶會(huì)話中的token一致。
2. 使用SameSite Cookie屬性

9.原理：SameSite 是一個(gè)cookie屬性，限制了瀏覽器在跨站請求時(shí)是否會(huì)攜帶cookie。它可以幫助防止CSRF攻擊，因?yàn)闉g覽器在發(fā)起跨站請求時(shí)不會(huì)自動(dòng)攜帶cookie，從而阻止了攻擊者偽造請求。
10.實(shí)現(xiàn)方式：將cookie的SameSite屬性設(shè)置為Strict或Lax，可以防止瀏覽器在跨站請求時(shí)自動(dòng)附帶cookie。
例如：

? ?Set-Cookie: session_id=abc123; SameSite=Strict; Secure; HttpOnly;

11.SameSite=Strict：完全阻止跨站請求發(fā)送cookie。
12.SameSite=Lax：允許一些類型的跨站請求（例如GET請求），但阻止復(fù)雜的跨站請求（例如POST請求）。

3. Referer Header檢查

13.原理：通過檢查請求頭中的 Referer 或 Origin 字段，來確認(rèn)請求是否來自合法的源站。合法的請求應(yīng)該來自同一個(gè)域名。如果請求頭中的Referer或Origin字段為空或者與期望的源站不匹配，則可以判定該請求為潛在的CSRF攻擊。
14.實(shí)現(xiàn)方式：服務(wù)器可以根據(jù)請求的Referer和Origin字段來驗(yàn)證請求來源，拒絕不符合的請求。
例如，服務(wù)器檢查 Referer：

? ?if (request.headers['referer'] !== 'https://example.com') {
? ? ? ?return res.status(403).send('Forbidden');
? ?}

4. 雙重認(rèn)證（Two-Factor Authentication）

15.原理：通過增加額外的身份驗(yàn)證步驟，例如要求用戶輸入驗(yàn)證碼或手機(jī)短信驗(yàn)證碼，在重要操作（如轉(zhuǎn)賬、密碼更改等）時(shí)，進(jìn)一步提高安全性，防止CSRF攻擊。
16.實(shí)現(xiàn)方式：在敏感操作時(shí)，要求用戶輸入驗(yàn)證碼、短信或其他第二種驗(yàn)證信息，以確認(rèn)操作是由用戶本人發(fā)起的。

5. 避免 GET 請求修改數(shù)據(jù)

17.原理：根據(jù)HTTP規(guī)范，GET請求應(yīng)該是冪等的，不應(yīng)該用于修改服務(wù)器狀態(tài)。所有修改數(shù)據(jù)的操作應(yīng)使用POST、PUT、PATCH等方法，而GET請求應(yīng)該僅用于獲取資源。
18.實(shí)現(xiàn)方式：確保所有可能導(dǎo)致數(shù)據(jù)修改的請求都使用POST方法，并且不依賴GET請求來提交表單或執(zhí)行操作。

6. 用戶行為確認(rèn)

19.原理：某些情況下，可以通過要求用戶再次確認(rèn)他們的意圖來避免惡意操作，例如，在重要操作（如轉(zhuǎn)賬、刪除賬戶）時(shí)要求用戶再次輸入密碼或通過其他方式確認(rèn)。
20.實(shí)現(xiàn)方式：要求用戶再次確認(rèn)操作或提供額外的身份驗(yàn)證信息。

總結(jié)
CSRF是通過冒充合法用戶發(fā)起惡意請求的攻擊方式，主要依賴于受害者的瀏覽器自動(dòng)攜帶身份認(rèn)證信息（如cookie）發(fā)送請求。為了防止CSRF攻擊，可以采用以下幾種策略：

21.使用CSRF Token：為每個(gè)請求生成唯一的token，確保請求是合法用戶發(fā)起的。
22.使用SameSite Cookies：通過限制cookie的發(fā)送范圍，避免跨站請求偽造。
23.Referer/Origin頭檢查：通過檢查請求的來源，確認(rèn)請求是否來自合法的站點(diǎn)。
24.雙重認(rèn)證：增加額外的身份驗(yàn)證步驟，防止未授權(quán)操作。
25.避免GET請求修改數(shù)據(jù)：將所有可能修改服務(wù)器狀態(tài)的請求限制為POST請求。
26.用戶行為確認(rèn)：通過額外的確認(rèn)步驟確保操作是由用戶本人發(fā)起的。

這些措施能夠有效地防止CSRF攻擊，保護(hù)用戶數(shù)據(jù)安全。