第三章 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相等,就可以提交。否则不会。
查看一下后端代码