csrf攻擊的原理:
1、當使用者成功登陸**a時，瀏覽器紀錄本次會話cookie。
解決辦法:
token
token一般用在兩個地方:
防止表單重複提交
csrf攻擊（跨站點請求偽造）。
兩者在原理上都是通過session token來實現的。當客戶端請求頁面時，伺服器會生成乙個隨機數token，並且將token放置到session當中，然後將token發給客戶端（一般通過構造hidden表單）。下次客戶端提交請求時，token會隨著表單一起提交到伺服器端。
然後，如果應用於"anti csrf攻擊"，則伺服器端會對token值進行驗證，判斷是否和session中的token值相等，若相等，則可以證明請求有效，不是偽造的。
不過，如果應用於"防止表單重複提交"，伺服器端第一次驗證相同過後，會將session中的token值更新下，若使用者重複提交，第二次的驗證判斷將失敗，因為使用者提交的表單中的token沒變，但伺服器端session中token已經改變了。
上面的session應用相對安全，但也叫繁瑣，同時當多頁面多請求時，必須採用多token同時生成的方法，這樣占用更多資源，執行效率會降低。因此，也可用cookie儲存驗證資訊的方法來代替session token。比如，應對"重複提交"時，當第一次提交後便把已經提交的資訊寫到cookie中，當第二次提交時，由於cookie已經有提交記錄，因此第二次提交會失敗。
不過，cookie儲存有個致命弱點，如果cookie被劫持（xss攻擊很容易得到使用者cookie），那麼又一次gameover。黑客將直接實現csrf攻擊。
所以，安全和高效相對的。具體問題具體對待吧。
此外，要避免"加token但不進行校驗"的情況，在session中增加了token，但服務端沒有對token進行驗證，根本起不到防範的作用。
還需注意的是，對資料庫有改動的增刪改操作，需要加token驗證，對於查詢操作，一定不要加token，防止攻擊者通過查詢操作獲取token進行csrf攻擊。但並不是這樣攻擊者就無法獲得token，只是增大攻擊成本而已。
CSRF攻擊原理
假設a.cn這個 是乙個xx管理系統，我只有這個系統的普通使用者的賬戶，這個賬戶功能很有限，沒有管理員賬戶的許可權大，只有管理員賬戶能新增其它的管理員賬戶，我在使用這個 的過程中發現這個 在新增管理員的時候沒有驗證碼或者token驗證，只需要輸入賬號和密碼就可以新增管理員了，這樣的話意味著可以被cs...
CSRF攻擊原理
csrf cross site request forgery 跨站請求偽造，也被稱為 one click attack 或者session riding，通常縮寫為csrf或者xsrf，是一種對 的惡意利用。儘管聽起來像跨站指令碼 xss 但它與xss非常不同，xss利用站點內的信任使用者，而cs...
防止CSRF攻擊
2.新增校驗token。前端發出請求時，加入從後端返回的token欄位的值 不能儲存在cookie中 攻擊者無法偽造的值 如果token不正確，不通過請求。3.設定 cookie 的samesite屬性 lax 相對嚴格模式，大多數情況下不傳送 cookie，導航到目標 的 get 請求除外。請求型...