CSRF(get)
自己隨便輸點東西，回顯登入失敗，檢視原始碼沒發現什麼
點開提示，登入進去看看
看到可以修改個人資訊，我們把居住改成China,修改成功，沒發現urlhttp://127.0.0.1/pikachu/vul/csrf/csrfget/csrf_get_edit.php有變化
這次我們在submit時抓包看看
/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=111&add=China&email=lili%40pikachu.com&submit=submit
url上並沒有攜帶認證資訊，所以在使用者登入狀態下（其實這個連結裡面是不包含使用者名稱的，誰登入都無所謂，只要有人登入著就行，登入著的使用者的資訊就會被改成url提供的那些），試試改一改上面的連結，比如把性別改一改。payload：
pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=111&add=China&email=lili%40pikachu.com&submit=submit
修改成功
因為這關session時間特別短（大概不到1min）可能會導致使用者登入之後後端檢測結果是使用者未登入
網上有很多短連結網站可以修飾url（百度搜尋“短連結”就有很多）
先檢查是否登入，如果沒登入則跳轉到登入頁面。如果使用者已登入，就不再做任何驗證，直接將前端傳來的資料下到資料庫了（看程式碼這關還有sql注入漏洞呢）。
CSRF(post)
和上一題一樣修改個人資訊的時候用bp抓包
依舊沒有認證資訊，有CSRF漏洞。
但是這一關是post型別，URL不再顯示修改引數，所以無法再使用上述辦法（即透過URL來偽造請求）進行修改，
需要我們去構造一個html，這裡我們直接用burp的工具生成
點選用瀏覽器測試
點選提交
直接跳轉
CSRF token
登入之後，修改個人資訊時bp抓包
發現有token欄位
token驗證原理
CSRF的主要問題是敏感操作的連結容易被偽造
每次請求，都增加一個隨機碼（需要夠隨機，不容易偽造），後臺每次對隨機碼進行驗證
網頁接受從後臺發過來的token,型別不可見。將其一併提交給後臺進行驗證。每次重新整理，後臺傳送過來的token都不一樣，起到了防止偽造的作用。
刪了token行不行，顯然是不行嘟
多抓幾次包發現token是無規律的，在一定程度上防禦了CSRF攻擊
檢視原始碼
修改使用者資訊時，伺服器會比較url中的token欄位和session中的token欄位，如果相同才能修改使用者資訊。
修改完使用者資訊之後，會用set_token()函式生成新的token，將其返回到html表單中並隱藏起來，以便下次使用者修改資訊時代入url。