概念
跨站請求偽造（Cross-site request forgery，簡稱為CSRF），也被稱為one-click attack或者session riding。
攻擊者透過一些手段偽造請求模仿使用者提交表單的行為，從而達到修改使用者資料或執行特定任務的目的。通常是攻擊者欺騙使用者瀏覽器來訪問一個認證過的網站並進行一些步驟（比如發訊息、購物、轉賬等），由於簡單的網站使用者身份驗證只要驗證了請求發自使用者的瀏覽器就會被執行，因此這種方法能夠輕而易舉地欺騙網站從而透過身份驗證。
假如，一家銀行用來執行轉賬操作的URL地址如下：
examplebank。com/withdraw？account=AccoutName&amount=1000&for=PayeeName
一個惡意攻擊者可以在另一個網站上放置如下程式碼：
假如有個賬戶名為wangdun的使用者訪問了惡意站點，而他在這之前才剛訪問過銀行不久、登陸資訊尚未過期，馬上就會發現自己的銀行賬戶莫名其妙地少了100元。
危害
現在有很多形式的惡意網址被大量釋出於網路中，攻擊者不需要控制這些網址，只需要將大量地址藏匿於部落格、論壇等任何能夠釋出資訊的網站中就可以。
這意味著，假如服務端沒有合適的防禦措施，使用者即使訪問已透過安全稽核的網頁也有遭受攻擊的危險。
解決方法
（一）增加攻擊的難度。GET請求是很容易建立的，使用者點選一個連結就可以發起GET型別的請求，而POST請求相對比較難，攻擊者往往需要藉助JavaScript才能實現；因此，確保form表單或者服務端介面只接受POST型別的提交請求，可以增加系統的安全性。
（二）對請求進行認證，確保該請求確實是使用者本人填寫表單或者發起請求並提交的，而不是第三者偽造的。
正常情況下一個使用者提交表單的步驟如下：
1）使用者點選連結→網站顯示錶單→使用者填寫資訊並提交→網站接受使用者的資料並儲存
而一個CSRF攻擊則不會走這條路線，而是直接偽造第二步網站顯示錶單從而提交使用者資訊
2）攻擊者通常直接跳到第二步（網站顯示錶單）→偽造要修改的資訊並提交→網站接受攻擊者修改引數資料並儲存
只要能夠區分這兩種情況，就能夠預防CSRF攻擊。那麼如何區分呢？ 就是對第二步中所提交的資訊進行驗證，確保資料來源自第一步的表單。具體的驗證過程如下：
3）、使用者點選連結→網站顯示錶單，表單中包含特殊的token同時把token儲存在session中→使用者填寫資訊並提交，同時發回token資訊到服務端→網站比對使用者發回的token和session中的token應該一致，則接受資料並儲存
這樣，假如攻擊者偽造了修改的資訊並提交，是沒辦法直接訪問到session的，所以也沒辦法拿到實際的token值；請求傳送到服務端，服務端進行token校驗的時候發現不一致則直接拒絕此次請求。
