第三章 CSRF跨站请求伪造
1.CSRF漏洞概述及原理
2.通过CSRF进行地址修改
我们先随便登录一下试试看，同时后台打开burp suite进行抓包
我们登录一下，随便修改一个信息并提交，看看后台的抓包。
我们可以看到，get请求是向后台发送了所有的参数。在这个里面我们并没有看到CSRF的token，说明后台没有做防CSRF的措施。
我们来构造一下语句，把地址改成shanxi，补全语句。
再打开一个页面，访问一下
在敲下回车的一刹那，她的浏览器就是以她当前的登录状态向后台发送了一个请求。实际上这个时候她的信息已经被改掉了。刷新一下之前的页面
成功修改
POST型的
还是登录一下
把地址改为beijing
这个是post请求，所有的参数是在请求体里传出的。所以无法通过url去伪造请求。
这个时候，需要我们跟之前一样，就建一个站点，在这个站点上做一个表单，然后让lucy去点击这个恶意站点的表单的url。通过这个url向存在CSRF漏洞的页面发送post请求。
3.token详解及常见防范措施
原理：当年每次去请求这个个人信息修改的页面时，后台就会去调用这个函数，先查看SESSION里面有没有token，如果有先销毁掉，然后去生成一个新的token，然后复制到SESSION里。这样就是实现了每当刷新这个页面时，都会生成一个新的token，把老的token销毁掉，然后把这个新的token放到筛选里，目的是为了下次提交请求过来的时候，进行对比。
场景演示：
看抓包情况
这个请求部分，唯一跟之前不一样的就是多出来一个token部分
那么，后端生成token后，前端如何拿到token，以及如何提交到后端进行认证。
我们来打开这个检查器，来看一下
当我们每次点击这个”修改个人信息时”，进入的这个页面，就会去访问token_get_edit.php这个文件。只要一访问，这个文件就会生成一个token。
那这个token echo到前端时，放在了哪里？查看一下整个表单
这个是被隐藏的。每次点提交，这个token会被同时提交到后台。后台会对这个token进行验证，如果跟当前生成的筛选里面的token相等，就可以提交。否则不会。
查看一下后端代码
