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。
__EOF__
