CSRF(跨站请求伪造)
概述
Cross-site request forgery 简称为“CSRF”,在CSRF的攻击场景中攻击者会伪造一个请求(这个请求一般是一个链接),然后欺骗目标用户进行点击,用户一旦点击了这个请求,整个攻击就完成了。所以CSRF攻击也成为"one click"攻击。
CSRF与XSS的区别:
CSRF是借用户的权限完成攻击,攻击者并没有拿到用户的权限,而XSS是直接盗取到了用户的权限,然后实施破坏。
因此,网站如果要防止CSRF攻击,则需要对敏感信息的操作实施对应的安全措施,防止这些操作出现被伪造的情况,从而导致CSRF。比如:
1. CSRF(get)
题干
解题过程
首先随便登录一个账户:
点击修改信息,更改信息后提交并抓包,根据包的内容可以判断该请求使用的是GET传参:
GET传参的一大特点就是会将传的参直接反映在url中,因此可以构造以下url:
localhost/pikachao/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=337845818&add=China&email=337845818%40qq.com&submit=submit
只要该用户在登录状态下访问了该url,其账户信息便会悄无声息地变成url中设定好的信息:
2. CSRF(post)
题干
解题过程
首先登录一个账户:
同样是修改个人信息,使用bp抓包:
判断是POST传参,POST传参是通过表单的形式放在请求体里进行的,不会直接体现在url中,所以这里效仿之前反射型xss(post)中的方法,构造一个访问可以自动提交请求的网页,以此来实现url利用:
-
首先复制一份相同的网页文件
csrf_post_edit_hack.php
,找到POST传参的部分: -
修改为指定的个人信息:
-
添加自动提交的脚本:
-
最后被攻击者只要在登录的情况下访问以下url,个人信息便会自动修改并提交:
http://localhost/pikachao/vul/csrf/csrfpost/csrf_post_hack.php
甚至自动提交后还自动跳转到了正常的页面,真正做到了“神不知鬼不觉”:
3. CSRF Token
题干
解题过程
依旧是老套路,登录账户,更改个人信息并抓包:
可见这次虽然是GET传参,但多了个难搞的token。
选择直接白盒查看后台代码,路径为pikachao/vul/csrf/csrftoken/get_token_edit.php
:
一开始会对能否成功修改做判断,其中便包含了对token的比较,此处可见是将GET传入的token与存储在SESSION中的token进行比较,但我们主要关心的还是第48行的set_token()函数,跟进查看:
如上图中红框内容,在每次调用set_token()函数时(即刷新网页时),都会先检测当前SESSION中是否存在token,存在的话便会先销毁,然后重新创建一个新的token保存在SESSION中。这也是本题无法利用url的原因。
至于其他的有用信息,大概就是第92行显示生成的token会以hidden的类型出现在前端页面中,这解释了为什么可以通过抓包获得当前token:
至于利用,由于本题是GET传参,理论上可以通过简单地访问url实现CSRF攻击,但由于token的存在,每次访问url都会产生新的token,所以暂时无法想到应该怎么实现。
综合看来,添加token对于防范CSRF攻击还是很有效的。
防范措施
-
增加token验证(常用的做法):
- 对关键操作增加token参数,token值必须随机,每次都不一样;
-
关于安全的会话管理(避免会话被利用);
-
不要在客户端端保存敏感信息(比如身份认证信息);
-
测试直接关闭,退出时,的会话过期机制;
-
设置会话过期机制,比如15分钟内无操作,则自动登录超时。
-
-
访问控制安全管理:
-
敏感信息的修改时需要对身份进行二次认证,比如修改账号时,需要判断旧密码;
-
敏感信息的修改使用post,而不是get ;
-
通过http头部中的referer来限制原页面。
-
-
增加验证码∶
-
一般用在登录(防暴力破解),也可以用在其他重要信息操作的表单中(需要考虑可用性)
判断旧密码; -
敏感信息的修改使用post,而不是get ;
-
通过http头部中的referer来限制原页面。
-
-
增加验证码∶
- 一般用在登录(防暴力破解),也可以用在其他重要信息操作的表单中(需要考虑可用性)