概述
1.CSRF(get)
抓包看看
發現其參數直接用get提交,並且沒做什么認證(即攻擊者不需要任何用戶的信息即可構造請求,如果防御的話我覺得應該利用cookie等認證用戶的信息添加到get請求里)
用戶點擊該網站鏈接時會以用戶的身份提交攻擊者提前准備好的數據
2.CSRF(post)
抓包看看
其實與上面那個同理,只是稍微麻煩點,需要自己搭建一個網站(或用戶能訪問到的網站),然后用戶點擊該網站鏈接時,該網站向目標網站提交攻擊者事先准備好的表單
3.CSRF Token
有token驗證了唉
我們看看源碼對token是怎樣設置的
emmmm隨機數的話就比較麻煩了.
我們易得知該token是用戶進入token_get_edit.php時,頁面給他返回一個隨機的token,對用戶在提交時擁有的會話token進行驗證.這樣就有點麻煩了.....(token走的應該是用用戶自己的信息驗證自己的信息吧,服務器這樣操作會不會加重服務器的內存負擔,並且需要對應好哪個用戶對應哪個token)
資料如下:
雖然確實都是“客戶端記錄，每次訪問攜帶”，但 token 很容易設計為自包含的，也就是說，后端不需要記錄什么東西，每次一個無狀態請求，每次解密驗證，每次當場得出合法 /非法的結論。這一切判斷依據，除了固化在 CS 兩端的一些邏輯之外，整個信息是自包含的。這才是真正的無狀態。
而 sessionid ，一般都是一段隨機字符串，需要到后端去檢索 id 的有效性。萬一服務器重啟導致內存里的 session 沒了呢？萬一 redis 服務器掛了呢？