摘要：瀏覽器對(duì)這種行為進(jìn)行了限制。大多數(shù)情況下，該請(qǐng)求會(huì)失敗，因?yàn)樗蟮恼J(rèn)證信息。在請(qǐng)求頭中添加自定義例如在知乎中給文章點(diǎn)贊結(jié)合中對(duì)的的介紹，知乎的這種方式被稱為。

CSRF，Cross Site Request Forgery，跨站請(qǐng)求偽造。

為什么跨站的請(qǐng)求需要偽造？

因?yàn)闉g覽器實(shí)現(xiàn)了同源策略，這里可以將站和源視為同一個(gè)概念。

The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin. It is a critical security mechanism for isolating potentially malicious documents.。 ——MDN

JavaScript可以通過(guò)document.origin查看當(dāng)前文檔所屬的源，但是不能改變?cè)?；源由協(xié)議(https)，域名(segmentfault)和端口(默認(rèn)為80)構(gòu)成；所謂同源，要求協(xié)議，域名和端口都相同。

從一個(gè)源加載的文檔或腳本與另一個(gè)源的資源進(jìn)行交互，可以理解為，從當(dāng)前源（網(wǎng)站）加載的文檔或腳本向另一源（網(wǎng)站）發(fā)送請(qǐng)求（請(qǐng)求的URL中包含了另一源）。瀏覽器對(duì)這種行為進(jìn)行了限制。

分別在segmentfault和baidu發(fā)送xhr請(qǐng)求，請(qǐng)求一篇segmentfault的文檔，其url為https://segmentfault.com/a/11...，相關(guān)截圖如下

在segmentfault中發(fā)送請(qǐng)求后Console，Network中Headers和Response顯示如下

這里我們要關(guān)注一下幾點(diǎn)，控制臺(tái)沒(méi)有報(bào)錯(cuò)，請(qǐng)求時(shí)包含cookie，響應(yīng)成功，且返回的文檔可見(jiàn)。

在baidu中發(fā)送請(qǐng)求后Console，Network中Headers和Response顯示如下

首先控制臺(tái)里報(bào)錯(cuò)了，No "Access-Control-Allow-Origin" header is present on the requested resource. Origin "https://www.baidu.com" is therefore not allowed access.；其次請(qǐng)求時(shí)沒(méi)有包含cookie，響應(yīng)雖然成功，但返回的內(nèi)容不可見(jiàn)。

通過(guò)Response Headers，我們可以判斷請(qǐng)求已經(jīng)發(fā)給segmentfault，并被處理，segmentfault也給了我們請(qǐng)求的文檔。那么所謂的限制呢？其一，在源為百度的文檔中，通過(guò)JavaScript發(fā)送給segmentfault的請(qǐng)求沒(méi)有帶上segmentfault的cookie；其二，segmentfault其實(shí)有返回的內(nèi)容，但是瀏覽器不讓我們看，not allowed access。

The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin. It is a critical security mechanism for isolating potentially malicious documents.。 ——MDN

這里用了restricts，也就是還有允許的。比如說(shuō)，在一個(gè)網(wǎng)站中可以引用其他網(wǎng)站的圖片，腳本等，它們都是有src屬性的標(biāo)簽。

如果在baidu中通過(guò)img的src標(biāo)簽發(fā)送請(qǐng)求 https://segmentfault.com/a/11... 會(huì)如何？

與之前發(fā)送xhr相比，通過(guò)img標(biāo)簽發(fā)送請(qǐng)求，這會(huì)把cookie給帶上了?。?！還發(fā)出去了?。?！雖然返回的結(jié)果依然不可見(jiàn)。

引用CSRF 攻擊的應(yīng)對(duì)之道的例子

CSRF 攻擊可以在受害者毫不知情的情況下以受害者名義偽造請(qǐng)求發(fā)送給受攻擊站點(diǎn)，從而在并未授權(quán)的情況下執(zhí)行在權(quán)限保護(hù)之下的操作。比如說(shuō)，受害者 Bob 在銀行有一筆存款，通過(guò)對(duì)銀行的網(wǎng)站發(fā)送請(qǐng)求 http://bank.example/withdraw?... 可以使 Bob 把 1000000 的存款轉(zhuǎn)到 bob2 的賬號(hào)下。通常情況下，該請(qǐng)求發(fā)送到網(wǎng)站后，服務(wù)器會(huì)先驗(yàn)證該請(qǐng)求是否來(lái)自一個(gè)合法的 session，并且該 session 的用戶 Bob 已經(jīng)成功登陸。黑客 Mallory 自己在該銀行也有賬戶，他知道上文中的 URL 可以把錢進(jìn)行轉(zhuǎn)帳操作。Mallory 可以自己發(fā)送一個(gè)請(qǐng)求給銀行：http://bank.example/withdraw?...。但是這個(gè)請(qǐng)求來(lái)自 Mallory 而非 Bob，他不能通過(guò)安全認(rèn)證，因此該請(qǐng)求不會(huì)起作用。這時(shí)，Mallory 想到使用 CSRF 的攻擊方式，他先自己做一個(gè)網(wǎng)站，在網(wǎng)站中放入如下代碼： src=”http://bank.example/withdraw?... ”，并且通過(guò)廣告等誘使 Bob 來(lái)訪問(wèn)他的網(wǎng)站。當(dāng) Bob 訪問(wèn)該網(wǎng)站時(shí)，上述 url 就會(huì)從 Bob 的瀏覽器發(fā)向銀行，而這個(gè)請(qǐng)求會(huì)附帶 Bob 瀏覽器中的 cookie 一起發(fā)向銀行服務(wù)器。大多數(shù)情況下，該請(qǐng)求會(huì)失敗，因?yàn)樗?Bob 的認(rèn)證信息。但是，如果 Bob 當(dāng)時(shí)恰巧剛訪問(wèn)他的銀行后不久，他的瀏覽器與銀行網(wǎng)站之間的 session 尚未過(guò)期，瀏覽器的 cookie 之中含有 Bob 的認(rèn)證信息。這時(shí)，悲劇發(fā)生了，這個(gè) url 請(qǐng)求就會(huì)得到響應(yīng)，錢將從 Bob 的賬號(hào)轉(zhuǎn)移到 Mallory 的賬號(hào)，而 Bob 當(dāng)時(shí)毫不知情。等以后 Bob 發(fā)現(xiàn)賬戶錢少了，即使他去銀行查詢?nèi)罩?，他也只能發(fā)現(xiàn)確實(shí)有一個(gè)來(lái)自于他本人的合法請(qǐng)求轉(zhuǎn)移了資金，沒(méi)有任何被攻擊的痕跡。而 Mallory 則可以拿到錢后逍遙法外。

引用[淺談CSRF攻擊方式](https://www.cnblogs.com/hyffffd...

并不是所有的請(qǐng)求都要進(jìn)行CSRF防御，很多讀取數(shù)據(jù)的請(qǐng)求不用進(jìn)行CSRF防御，因?yàn)榉祷氐慕Y(jié)果本來(lái)就不可見(jiàn)；那些操作數(shù)據(jù)的請(qǐng)求往往需要進(jìn)行CSRF防御，例如修改賬戶信息之類的。

CSRF只是發(fā)送請(qǐng)求時(shí)帶上了相應(yīng)的cookie，但這個(gè)cookie對(duì)攻擊者來(lái)說(shuō)還是不可見(jiàn)，不可操作的，同時(shí)攻擊者所擁有的也只有這個(gè)他自己不可見(jiàn)，不可操作的cookie。所以防御的基本思想就是在請(qǐng)求中添加額外的驗(yàn)證信息（token），不僅僅通過(guò)cookie來(lái)驗(yàn)證請(qǐng)求，方法大體有以下幾種：

對(duì)于每個(gè)請(qǐng)求，驗(yàn)證其Referrer，是否同源

例如在segmentfault中給文章點(diǎn)贊，就會(huì)發(fā)送這樣的請(qǐng)求

我揣測(cè)segmentfault的防御機(jī)制是這樣的，每當(dāng)用戶請(qǐng)求頁(yè)面時(shí)，頁(yè)面里會(huì)包含一段隨機(jī)數(shù)（token），在發(fā)送關(guān)健請(qǐng)求時(shí)，token會(huì)作為請(qǐng)求的參數(shù)被帶上。CSRF的攻擊者無(wú)法得到token，而服務(wù)端憑借此token判斷請(qǐng)求正常與否。此外，即使同樣的用戶發(fā)出同樣的請(qǐng)求，得到頁(yè)面里的token還是會(huì)不一樣。親測(cè)實(shí)驗(yàn)證明，在一定時(shí)間范圍內(nèi)，token不會(huì)變化，可以說(shuō)token是有有效期的。

例如在知乎中給文章點(diǎn)贊

結(jié)合wiki中對(duì)CSRF的Prevention的介紹，知乎的這種方式被稱為Cookie-to-header token。其主要過(guò)程如下，

服務(wù)端發(fā)送cookie，其中含有xsrf=fajflafjaajf21ejlkja，其值為隨機(jī)數(shù)（token）

客戶端讀取cookie，并將token讀取出來(lái)

客戶端在發(fā)送需要csrf防御的請(qǐng)求時(shí)，例如知乎例子中的點(diǎn)贊，就會(huì)將token設(shè)為請(qǐng)求頭的值，例如知乎例子中X-Xsrftoken，添加至請(qǐng)求中（csrf,xsrf是一個(gè)玩意兒）

服務(wù)端會(huì)根據(jù)token與cookie中值是否相符，判斷請(qǐng)求的合法性

要實(shí)現(xiàn)這樣的過(guò)程，就要求cookie中xsrf字段沒(méi)有設(shè)置httpOnly
其次這樣做能防御csrf，是因?yàn)槠渌粗械腏avaScript無(wú)法讀取知乎源的cookie，只有知乎自己源下的JavaScript可以讀取自己的cookie。對(duì)應(yīng)之前的說(shuō)明圖中，即使用戶在沒(méi)有登出A網(wǎng)站的情況下，訪問(wèn)B網(wǎng)站，B網(wǎng)站帶著A網(wǎng)站的cookie向A網(wǎng)站發(fā)出請(qǐng)求，但是B網(wǎng)站無(wú)法讀取A網(wǎng)站的cookie，發(fā)出的請(qǐng)求中無(wú)法帶有相應(yīng)的請(qǐng)求頭，或請(qǐng)求頭中的值無(wú)法與cookie匹配，例如知乎中的X-Xsrftoken。A網(wǎng)站收到這樣的請(qǐng)求，就能辨別出它是惡意的請(qǐng)求了。

Same-origin policy

CSRF 攻擊的應(yīng)對(duì)之道

淺談CSRF攻擊方式

CSRF Introduction and what is the Same-Origin Policy? - web 0x04

Wiki中CSRF

Cross-Site Request Forgery (CSRF))

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet_Prevention_Cheat_Sheet#Viewstate_.28ASP.NET.29)