CSRF漏洞介紹
跨站點(diǎn)請求偽造（Cross Site Request Forgery）又被稱作 CSRF，是惡意站點(diǎn)或程序通過已認(rèn)證用戶的瀏覽器在受信任站點(diǎn)上執(zhí)行非正常操作?？蛇M(jìn)行的惡意操作局限于已在網(wǎng)站通過身份驗證的用戶的功能。
例如，Jane 可能會在查看電子郵件的同時登錄了她的網(wǎng)上銀行，然后可能會點(diǎn)進(jìn)釣魚郵件中的自帶轉(zhuǎn)賬請求的鏈接（比如迷惑性的短鏈接），要求 Jane 的銀行轉(zhuǎn)賬至被攻擊者控制的賬戶里。
由于 Jane 已經(jīng)登陸了銀行，該轉(zhuǎn)賬請求會被自動執(zhí)行，因為是通過已被 Jane 授權(quán)了的瀏覽器發(fā)出的請求。
什么是 HTTP 請求（Requests）和 Cookie?
HTTP GET 請求
這個請求用于向 Web 服務(wù)器請求數(shù)據(jù)（比如輸入 URL（請求網(wǎng)站）加載）。
HTTP POST 請求
這個請求用于向 Web 服務(wù)器發(fā)送數(shù)據(jù)（比如提交 Web 表單）。
某些 GET 和 POST 請求會自動觸發(fā)，無需用戶交互（例如獲取搜索建議或使用?img src?屬性加載圖像內(nèi)容）。
會話 Cookies
會話 cookie 是 HTTP 處理狀態(tài)的一種方式（因為它本身不處理狀態(tài)）。 網(wǎng)站使用會話 cookie（包含唯一 ID）來識別用戶并保留他們的會話。
設(shè)置會話 cookie 后，用戶瀏覽器會在每次請求時將 cookie 發(fā)送到服務(wù)器，以供站點(diǎn)識別用戶。
攻擊者可以通過強(qiáng)制用戶瀏覽器發(fā)送請求來利用 cookie 來冒充用戶，如果用戶已經(jīng)登錄到站點(diǎn)，cookie 將隨請求自動發(fā)送。
跨站點(diǎn)請求偽造是如何工作的?
攻擊者進(jìn)行 CSRF 攻擊需要滿足以下幾點(diǎn)：
攻擊者想在網(wǎng)站應(yīng)用中執(zhí)行一種操作 — 例如更改密碼、轉(zhuǎn)賬等。
不包含不可猜測的請求參數(shù) — 攻擊者可以猜測（或知道）網(wǎng)站應(yīng)用的此類請求中需要的所有參數(shù)。
該操作僅依賴 cookie 來驗證請求是否來自用戶，并可以通過 HTTP 請求執(zhí)行。
CSRF 會影響網(wǎng)站使用 cookie，瀏覽器身份驗證或客戶端證書對用戶進(jìn)行身份驗證的 Web 應(yīng)用程序?；旧?CSRF 可能發(fā)生在應(yīng)用程序自動將用戶證書或身份添加到請求的任何情況下。
CSRF 攻擊可以利用 GET 請求或 POST 請求（由于 POST 請求更復(fù)雜，因此不常見）。
兩者都需要攻擊者先誘騙受害者加載或?qū)⑿畔⑻峤坏?Web 應(yīng)用程序。這可以通過多種方式發(fā)生 - 例如釣魚鏈接。
另外，類似于 XSS（跨站點(diǎn)腳本），CSRF 可以是一個可以被存儲型漏洞。 比如攻擊者將攻擊代碼存儲在被接受的 HTML 代碼中就會導(dǎo)致存儲型 CSRF（例如?IMG?或?IFRAME?標(biāo)簽）時。這意味著瀏覽該頁面的任何人都可能受到影響。 該漏洞可以偽裝成普通鏈接或隱藏在圖像標(biāo)簽中。
例如，作為網(wǎng)頁上的普通鏈接?<a href=“malicious link”>Unsubscribe here</a>
或者偽裝成圖片標(biāo)簽:?<img src=“malicious link” width=“0” height=“0” border=“0”>
CSRF 示例
想象一下，你的銀行（bank.com）使用 GET 請求處理轉(zhuǎn)賬，其中包括幾個參數(shù)（收款人身份以及轉(zhuǎn)賬的金額）。
例如，如果 Jim 想給他的朋友 Bob 10 美元，請求可能如下所示：
http://bank.com/transfer?recipient=Bob&amount=10
該請求還包括一個會話 cookie，用于標(biāo)識帳戶所持有人，以便銀行知道從哪里取款。
現(xiàn)在，攻擊者可能成功使 Jim 單擊如下所示的鏈接（但已被巧妙的用縮短器或超鏈接縮短）：
http://bank.com/transfer?recipient=Hacker&amount=100000
因為 Jim 已經(jīng)登錄，他的瀏覽器會將他的 cookie 和請求一并發(fā)送 — 所以他的銀行相信他本人正在請求轉(zhuǎn)賬于是執(zhí)行了轉(zhuǎn)賬請求。
如何防止 CSRF 攻擊
謹(jǐn)慎選擇網(wǎng)站框架
使用內(nèi)置了防護(hù) CSRF 的框架，例如?.NET。 正確的配置很重要。如果你使用的框架沒有保護(hù)，可以使用 Anti-CSRF 令牌添加保護(hù)。
使用 Anti-CSRF 令牌
令牌（也稱為令牌同步模式）是一種服務(wù)器端的保護(hù)方式，服務(wù)器向用戶的瀏覽器提供唯一的、隨機(jī)生成的令牌，并檢查每個請求來查看瀏覽器是否在執(zhí)行請求之前將其發(fā)回。
這個令牌通過隱藏字段發(fā)送，應(yīng)該是一個會在很短的時間內(nèi)失效的不可預(yù)測的隨機(jī)數(shù)，且不能重復(fù)使用。
根據(jù)不同頁面的信息敏感程度，可以針對每個請求使用不同的令牌，或者僅針對不同的表單。令牌應(yīng)該以安全的方式進(jìn)行對比驗證（例如比較哈希值），并且不應(yīng)在 HTTP GET 請求中發(fā)送，防止作為 URL 的一部分或者 Referrer 泄漏。
在 Cookie 中使用 SameSite 標(biāo)記
SameSite 標(biāo)記的 cookie，只能發(fā)送來自同域名的請求。
基本上，www.bank.com 可以被允許向www.bank.com/updatepassword?提交 request 請求。 但www.maliciousdomain.com向 www.bank.com/updatepassword 發(fā)出請求時不能發(fā)送會話 cookie，因此無法進(jìn)行攻擊。
現(xiàn)在大多數(shù)瀏覽器都支持這個標(biāo)志，但不是全部。它應(yīng)該是綜合防御戰(zhàn)略的一部分。
深入練習(xí)防御
你可以進(jìn)行許多其他的控制措施并配合其他措施使用，可以提供針對 CSRF 的保護(hù)。
例如，你可以采取以下一些其他保護(hù)措施
使用標(biāo)準(zhǔn)頭文件驗證來源（確定請求的來源和目標(biāo)位置是否匹配）
使用自定義的請求頭文件（站點(diǎn)將不接受沒有相應(yīng)的頭文件的請求）
雙重提交 cookie（尤其是一秒鐘隨機(jī)生成且未知的 cookie；對于攻擊者來說，必須提交該參數(shù)才能正常請求）。
讓用戶參與交易流程
對于轉(zhuǎn)賬或密碼更改等敏感操作，要求用戶行為（如 CAPTCHA、一次性令牌或重新身份驗證）。
無效的措施示例：
多步驟交易：?只要攻擊者可以預(yù)測/確定每個步驟，有多少步驟并不重要。
HTTPS：?總是一個好的安全措施，但對于 CSRF 無效
URL 改寫：?這可以防止攻擊者在 CSRF 攻擊期間猜測受害者的會話 ID，但隨后攻擊者可以在 URL 中看到它。用一個缺陷替換另一個缺陷并不是一個好主意。
使用私密（Secret）Cookie：?私密 cookie 同樣是作為請求的一部分提交，也就是仍然可以被攻擊者利用。
只接受 POST 請求/避免 GET 請求：?偽造的 POST 請求仍可用于執(zhí)行 CSRF 攻擊。
CSRF的其他稱呼
CSRF 也被稱作 XSRF，Sea Surf（CSRF 發(fā)音），會話疊置（Session Riding），跨站點(diǎn)引用偽造（Cross-Site Reference Forgery），惡意連接（Hostile Linking），一鍵攻擊（One-Click Attack）。
