本质：挟制用户在当前已登录的Web应用程序上执行非本意的操作（由客户端发起）
耐心看完皮卡丘靶场的这个例子你就明白什么是CSRF了
CSRF(get)
使用提示里给的用户和密码进行登录（这里以lili为例）
登录成功后显示用户个人信息，并且提供修改个人信息的链接
点击修改个人信息，这里我们可以修改：性别、手机、住址、邮箱
尝试对用户信息进行修改
点击submit提交后，发现用户信息已经被修改
看到这里你肯定还是没明白CSRF到底是啥，攻击体现在哪儿
我们使用burpsuite来对请求进行抓包
提取url
/vul/csrf/csrfget/csrf_get_edit.php?sex=sex&phonenum=phone&add=address&email=email&submit=submit拼接好完整的URL（我这里是在自己服务器上搭建的靶场）
http://snert.vip:10005/vul/csrf/csrfget/csrf_get_edit.php?sex=sex&phonenum=phone&add=address&email=email&submit=submit
访问这个url，即可实现对用户信息的修改
注意：实际加载出来的URL里面是看不到这些信息的（姓名、手机、地址等）
我们对payload进行修改
http://snert.vip:10005/vul/csrf/csrfget/csrf_get_edit.php?sex=SSS&phonenum=NNN&add=AAA&email=EEE&submit=submit访问该url
可以看到用户信息被再次修改
回到csrf的本质上：挟制用户在当前已登录的Web应用程序上执行非本意的操作
换句话说，这个修改的操作只能是用户本生自己去进行的（客户端发起的请求），只是说用户他自己并不知情，他不知道自己只是点了一个链接竟然就修改了自己的信息或者密码。
比如我们换一个浏览器（没有进行过登录没有cookie信息缓存），并尝试访问上一个URL
http://snert.vip:10005/vul/csrf/csrfget/csrf_get_edit.php?sex=sex&phonenum=phone&add=address&email=email&submit=submit
回显的是要求我们登录的页面
假如我不知道lili的密码，我只有vince的密码
使用vince的账号登录后，再次访问上述url看看会怎样
这是vince原始的信息：
访问
http://snert.vip:10005/vul/csrf/csrfget/csrf_get_edit.php?sex=sex&phonenum=phone&add=address&email=email&submit=submit发现被修改掉的是vince自己的信息
也就是说：登录的用户是谁，产生的效果（payload）就作用于谁
至于怎样构造这样的URL，如果我们在某个平台有自己的账户，我们是不是就可以通过抓包来知道了呢，从而构造出恶意的URL，让其他用户点击，就可以实现对其他用户信息的修改。
当然，上面的这种URL看着太明显了，我们需要对恶意的URL进行一定处理，不被受害者察觉，
最简单的方法就是进行短链接处理（有很多的在线网站），比如对
http://snert.vip:10005/vul/csrf/csrfget/csrf_get_edit.php?sex=SSS&phonenum=NNN&add=AAA&email=EEE&submit=submit处理之后就变成了
http://mrw.so/6vyWU4
http://i7q.cn/5xoQ1t
http://mtw.so/6vMlGu
这还能看出来是进行密码或者信息修改的操作吗？
当用户随便访问了其中的一个链接，就会对用户信息的进行修改。
有些平台的短链接需要进行跳转，不建议使用这种
https://dlj.li/2vq1G
目前来说，对抗CSRF攻击最简洁而有效的方法就是使用验证码。CSRF攻击是在用户不知情的情况下构造了网络请求，而验证码则是强制要求用户与应用程序进行交互，才能完成最终请求。
关于CSRF的基本介绍就到这里，希望这篇博客能让你了解到什么是CSRF。
