Can you summarize the following document?
        
  跨站請求攻擊,簡單地說,是攻擊者通過一些技術手段欺騙使用者的瀏覽器去訪問一個自己曾經認證過的網站並執行一些操作(如發郵件,發訊息,甚至財產操作如轉賬和購買商品)。由於瀏覽器曾經認證過,所以被訪問的網站會認為是真正的使用者操作而去執行。這利用了web中使用者身份驗證的一個漏洞:簡單的身份驗證只能保證請求發自某個使用者的瀏覽器,卻不能保證請求本身是使用者自願發出的。

  假如一家銀行用以執行轉賬操作的URL地址如下: http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName  那麼,一個惡意攻擊者可以在另一個網站上放置如下程式碼: <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">  如果有賬戶名為Alice的使用者訪問了惡意站點,而她之前剛訪問過銀行不久,登入資訊尚未過期,那麼她就會損失1000資金。  這種惡意的網址可以有很多種形式,藏身於網頁中的許多地方。此外,攻擊者也不需要控制放置惡意網址的網站。例如他可以將這種地址藏在論壇,部落格等任何使用者生成內容的網站中。這意味著如果伺服器端沒有合適的防禦措施的話,使用者即使訪問熟悉的可信網站也有受攻擊的危險。  透過例子能夠看出,攻擊者並不能通過CSRF攻擊來直接獲取使用者的賬戶控制權,也不能直接竊取使用者的任何資訊。他們能做到的,是欺騙使用者的瀏覽器,讓其以使用者的名義執行操作。

  

  令牌同步模式(,簡稱STP)。原理是:當使用者傳送請求時,伺服器端應用將令牌(,一個保密且唯一的值)嵌入HTML表格,併傳送給客戶端。客戶端提交HTML表格時候,會將令牌傳送到服務端,令牌的驗證是由服務端實行的。令牌可以通過任何方式生成,只要確保隨機性和唯一性(如:使用隨機種子【】的雜湊鏈 )。這樣確保攻擊者傳送請求時候,由於沒有該令牌而無法通過驗證。  Django框架預設帶有STP功能: <form method="post"> </form>  渲染後的效果如下: <form method="post"> </form>  STP能很好在HTML下執行,但導致的是服務端的複雜度升高,複雜度源於令牌的生成和驗證。因為令牌是唯一且隨機,如果每個表格都使用一個唯一的令牌,那麼當頁面過多時,伺服器由於生產令牌而導致的負擔也會增加。而使用會話()等級的令牌代替的話,伺服器的負擔將沒有那麼重。

  HTTP頭中有一個Referer欄位,這個欄位用以標明請求來源於哪個地址。在處理敏感資料請求時,通常來說,Referer欄位應和請求的地址位於同一域名下。以上文銀行操作為例,Referer欄位地址通常應該是轉賬按鈕所在的網頁地址,應該也位於www.examplebank.com之下。而如果是CSRF攻擊傳來的請求,Referer欄位會是包含惡意網址的地址,不會位於www.examplebank.com之下,這時候伺服器就能識別出惡意的訪問。  這種辦法簡單易行,工作量低,僅需要在關鍵訪問處增加一步校驗。但這種辦法也有其侷限性,因其完全依賴瀏覽器傳送正確的Referer欄位。雖然http協議對此欄位的內容有明確的規定,但並無法保證來訪的瀏覽器的具體實現,亦無法保證瀏覽器沒有安全漏洞影響到此欄位。並且也存在攻擊者攻擊某些瀏覽器,篡改其Referer欄位的可能。

  由於CSRF的本質在於攻擊者欺騙使用者去訪問自己設定的地址,所以如果要求在訪問敏感資料請求時,要求使用者瀏覽器提供不儲存在cookie中,並且攻擊者無法偽造的資料作為校驗,那麼攻擊者就無法再執行CSRF攻擊。這種資料通常是表單中的一個資料項。伺服器將其生成並附加在表單中,其內容是一個偽亂數。當客戶端通過表單提交請求時,這個偽亂數也一併提交上去以供校驗。正常的訪問時,客戶端瀏覽器能夠正確得到並傳回這個偽亂數,而通過CSRF傳來的欺騙性攻擊中,攻擊者無從事先得知這個偽亂數的值,伺服器端就會因為校驗token的值為空或者錯誤,拒絕這個可疑請求。
跨站請求偽造(英語:Cross-site request forgery),也被稱為 one-click attack 或者 session riding,通常縮寫為 CSRF 或者 XSRF, 是一種挾制使用者在當前已登入的Web應用程式上執行非本意的操作的攻擊方法。 跟跨網站指令碼(XSS)相比,XSS 利用的是使用者對指定網站的信任,CSRF 利用的是網站對使用者網頁瀏覽器的信任。