“跨站請求偽造”（Cross-site request forgery）妻怎，也被稱為“one-click attack”或者 “session riding”炫惩，通吃廾郑縮寫為 “CSRF”或者“XSRF”店读， 是一種挾制用戶在當前已登錄的Web應用程序上執(zhí)行非本意的操作的攻擊方法 跟 利用的是網站對用戶網頁瀏覽器的信任纫普。
攻擊方式
攻擊者通過一些技術手段欺騙用戶的瀏覽器去訪問一個自己曾經認證過的網站并執(zhí)行一些操作（如發(fā)郵件嫁艇，發(fā)消息朗伶，甚至財產操作如轉賬和購買商品）。由于瀏覽器曾經認證過步咪，所以被訪問的網站會認為是真正的用戶操作而去執(zhí)行腕让。這利用了web中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發(fā)自某個用戶的瀏覽器，卻不能保證請求本身是用戶自愿發(fā)出的。例子
假如一家銀行用以執(zhí)行轉賬操作的URL地址如下： http://www.examplebank.com/withdrawaccount=AccoutName&amount=1000&for=PayeeName
那么纯丸，一個惡意攻擊者可以在另一個網站上放置如下代碼： http://www.examplebank.com/withdrawaccount=Alice&amount=1000&for=Badman
如果有賬戶名為Alice的用戶訪問了惡意站點偏形，而她之前剛訪問過銀行不久，登錄信息尚未過期觉鼻，那么她就會損失1000資金俊扭。
這種惡意的網址可以有很多種形式，藏身于網頁中的許多地方坠陈。此外萨惑，攻擊者也不需要控制放置惡意網址的網站。例如他可以將這種地址藏在論壇仇矾，博客等任何[用戶生成內容]的網站中庸蔼。這意味著如果服務器端沒有合適的防御措施的話，用戶即使訪問熟悉的可信網站也有受攻擊的危險贮匕。
透過例子能夠看出姐仅，攻擊者并不能通過CSRF攻擊來直接獲取用戶的賬戶控制權，也不能直接竊取用戶的任何信息刻盐。他們能做到的掏膏，是欺騙用戶瀏覽器，讓其以用戶的名義執(zhí)行操作敦锌。防御措施
1.檢查Referer字段
HTTP頭中有一個Referer字段馒疹，這個字段用以標明請求來源于哪個地址。在處理敏感數據請求時乙墙，通常來說颖变，Referer字段應和請求的地址位于同一域名下。以上文銀行操作為例听想，Referer字段地址通常應該是轉賬按鈕所在的網頁地址腥刹，應該也位于www.examplebank.com之下。而如果是CSRF攻擊傳來的請求哗魂，Referer字段會是包含惡意網址的地址肛走，不會位于www.examplebank.com之下漓雅，這時候服務器就能識別出惡意的訪問录别。
這種辦法簡單易行，工作量低邻吞，僅需要在關鍵訪問處增加一步校驗组题。但這種辦法也有其局限性，因其完全依賴瀏覽器發(fā)送正確的Referer字段抱冷。雖然http協議對此字段的內容有明確的規(guī)定崔列，但并無法保證來訪的瀏覽器的具體實現，亦無法保證瀏覽器沒有安全漏洞影響到此字段。并且也存在攻擊者攻擊某些瀏覽器赵讯，篡改其Referer字段的可能盈咳。
2.添加校驗token
由于CSRF的本質在于攻擊者欺騙用戶去訪問自己設置的地址，所以如果要求在訪問敏感數據請求時边翼，要求用戶瀏覽器提供不保存在cookie中鱼响，并且攻擊者無法偽造的數據作為校驗，那么攻擊者就無法再執(zhí)行CSRF攻擊组底。這種數據通常是表單中的一個數據項丈积。服務器將其生成并附加在表單中，其內容是一個偽亂數债鸡。當客戶端通過表單提交請求時江滨，這個偽亂數也一并提交上去以供校驗。正常的訪問時厌均，客戶端瀏覽器能夠正確得到并傳回這個偽亂數唬滑，而通過CSRF傳來的欺騙性攻擊中，攻擊者無從事先得知這個偽亂數的值莫秆，服務器端就會因為校驗token的值為空或者錯誤间雀，拒絕這個可疑請求。
以上內容來源于維基百科,說明的很清楚就搬過來了镊屎。
