摘要：瀏覽器對這種行為進行了限制。大多數情況下，該請求會失敗，因為他要求的認證信息。在請求頭中添加自定義例如在知乎中給文章點贊結合中對的的介紹，知乎的這種方式被稱為。

CSRF，Cross Site Request Forgery，跨站請求偽造。

為什么跨站的請求需要偽造？

因為瀏覽器實現了同源策略，這里可以將站和源視為同一個概念。

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可以通過document.origin查看當前文檔所屬的源，但是不能改變源；源由協議(https)，域名(segmentfault)和端口(默認為80)構成；所謂同源，要求協議，域名和端口都相同。

從一個源加載的文檔或腳本與另一個源的資源進行交互，可以理解為，從當前源（網站）加載的文檔或腳本向另一源（網站）發送請求（請求的URL中包含了另一源）。瀏覽器對這種行為進行了限制。

分別在segmentfault和baidu發送xhr請求，請求一篇segmentfault的文檔，其url為https://segmentfault.com/a/11...，相關截圖如下

在segmentfault中發送請求后Console，Network中Headers和Response顯示如下

這里我們要關注一下幾點，控制臺沒有報錯，請求時包含cookie，響應成功，且返回的文檔可見。

在baidu中發送請求后Console，Network中Headers和Response顯示如下

首先控制臺里報錯了，No "Access-Control-Allow-Origin" header is present on the requested resource. Origin "https://www.baidu.com" is therefore not allowed access.；其次請求時沒有包含cookie，響應雖然成功，但返回的內容不可見。

通過Response Headers，我們可以判斷請求已經發給segmentfault，并被處理，segmentfault也給了我們請求的文檔。那么所謂的限制呢？其一，在源為百度的文檔中，通過JavaScript發送給segmentfault的請求沒有帶上segmentfault的cookie；其二，segmentfault其實有返回的內容，但是瀏覽器不讓我們看，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，也就是還有允許的。比如說，在一個網站中可以引用其他網站的圖片，腳本等，它們都是有src屬性的標簽。

如果在baidu中通過img的src標簽發送請求 https://segmentfault.com/a/11... 會如何？

與之前發送xhr相比，通過img標簽發送請求，這會把cookie給帶上了！！！還發出去了！！！雖然返回的結果依然不可見。

引用CSRF 攻擊的應對之道的例子

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

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

并不是所有的請求都要進行CSRF防御，很多讀取數據的請求不用進行CSRF防御，因為返回的結果本來就不可見；那些操作數據的請求往往需要進行CSRF防御，例如修改賬戶信息之類的。

CSRF只是發送請求時帶上了相應的cookie，但這個cookie對攻擊者來說還是不可見，不可操作的，同時攻擊者所擁有的也只有這個他自己不可見，不可操作的cookie。所以防御的基本思想就是在請求中添加額外的驗證信息（token），不僅僅通過cookie來驗證請求，方法大體有以下幾種：

對于每個請求，驗證其Referrer，是否同源

例如在segmentfault中給文章點贊，就會發送這樣的請求

我揣測segmentfault的防御機制是這樣的，每當用戶請求頁面時，頁面里會包含一段隨機數（token），在發送關健請求時，token會作為請求的參數被帶上。CSRF的攻擊者無法得到token，而服務端憑借此token判斷請求正常與否。此外，即使同樣的用戶發出同樣的請求，得到頁面里的token還是會不一樣。親測實驗證明，在一定時間范圍內，token不會變化，可以說token是有有效期的。

例如在知乎中給文章點贊

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

服務端發送cookie，其中含有xsrf=fajflafjaajf21ejlkja，其值為隨機數（token）

客戶端讀取cookie，并將token讀取出來

客戶端在發送需要csrf防御的請求時，例如知乎例子中的點贊，就會將token設為請求頭的值，例如知乎例子中X-Xsrftoken，添加至請求中（csrf,xsrf是一個玩意兒）

服務端會根據token與cookie中值是否相符，判斷請求的合法性

要實現這樣的過程，就要求cookie中xsrf字段沒有設置httpOnly
其次這樣做能防御csrf，是因為其他源中的JavaScript無法讀取知乎源的cookie，只有知乎自己源下的JavaScript可以讀取自己的cookie。對應之前的說明圖中，即使用戶在沒有登出A網站的情況下，訪問B網站，B網站帶著A網站的cookie向A網站發出請求，但是B網站無法讀取A網站的cookie，發出的請求中無法帶有相應的請求頭，或請求頭中的值無法與cookie匹配，例如知乎中的X-Xsrftoken。A網站收到這樣的請求，就能辨別出它是惡意的請求了。

Same-origin policy

CSRF 攻擊的應對之道

淺談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)