CSRF（get类型）
登陆：
修改一下个人信息并提交，同时利用BurpSuite抓包查看修改个人信息的请求内容：
从提交的请求来看，后台没做CSRF token，同时也是通过GET请求来提交修改信息，我们拿到这个，修改一下，然后让lucy点击就好，我们构造的URL中把地址add改为hacker。lucy一点击就修改了地址。
http://192.168.5.100/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=12345678922&add=hack&email=lucy%40pikachu.com&submit=submit HTTP/1.1
这个看似很厉害，但是实际上满足条件比较严苛，比如lucy必须是登陆状态，而且防范意识较低，才可以。
另外这个与反射型的XSS也不同，反射型XSS可以获取用户cookie得到了shell，而get型CSRF并没有得到用户的shell。
CSRF（post）：
登陆之后修改信息，发现post型并没有显示url中，抓包发现是以form表单的请求体提交：
这里的攻击方式跟XSS中POST类型是类似的，攻击者可以搭建一个站点，在站点上做一个表单，诱导lucy点击这个链接，当用户点击时，就会自动向存在CSRF的服务器提交POST请求修改个人信息。
然后把攻击网页放在服务器上，诱骗受害者点击链接：
192.168.5.100/pikachu/pkxss/csrf/post.html
然后发现信息已经更改：
CSRF之token防御
CSRF的主要问题是敏感操作容易被伪造，我们可以加入Token让请求不容易被伪造
每次请求，都增加一个随机码（需要够随机，不容易被伪造），后台每次对这个随机码进行验证
我们进入Pikachu平台的CSRF（token）页面并登录，我们可以看一下这个GET请求
看下控制台源码，看下这个表单，每次点击修改个人信息 都会去访问 token_get_edit_.php 这个文件，这个文件就会生成一个token，value就是后端发过来的，type是隐藏的额，在前端看不到，但是在源码中能看到。每次点提交，token也会被提交到后台，后台会对token进行验证，如果和当前session里面的token相等，才会让你提交。