一.漏洞解释
CSRF(Cross-site request forgery),也称XSRF,跨站请求伪造:攻击者诱导受害者进入第三方网站,在第三方网站中,向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证,绕过后台的用户验证,达到冒充用户对被攻击的网站执行某项操作的目的。与XSS相似,但与XSS相比更难防范,是一种广泛存在于网站中的安全漏洞,经常与XSS一起配合攻击。
二.发生原因
1.URL请求所有的参数均可确定
2.URL请求的审核不严格,如:只验证了Cookie
三.漏洞发生过程
1.受害者登录a.com,并保留了Cookie。
2.攻击者引诱受害者访问了b.com。
3.b.com 向 a.com 发送了一个请求:a.com/act=xx。浏览器会默认携带a.com的Cookie。
4.a.com接收到请求后,对请求进行验证,并确认是受害者的凭证,误以为是受害者自己发送的请求。
5.a.com以受害者的名义执行了act=xx。
6.攻击完成,攻击者在受害者不知情的情况下,冒充受害者,让a.com执行了自己定义的操作
四.常见危害
1.篡改目标网站上的用户数据;
2.盗取用户隐私数据;
3.作为其他攻击向量的辅助攻击手法;
4.传播CSRF蠕虫。
五.漏洞利用方式
1.通过HTML标签发送合法的跨域请求
2.通过Ajax发送请求(由于CORS机制的存在,一般不使用)
六.Referer头绕过
1.检测referer是否检测路径
假设原referer如下:
Referer: http://admin.teagle.top/test/
发现删除referer删除后失败后
删除域名后边的东西,成功则说明不检测路径(呃,一般不检测路径)
Referer: http://admin.teagle.top/
2.检测referer是否属于指定域
将二级域名替换为别的字符,成功则说明后台检测的是referer是否属于teagle.top域
Referer: http://aaaaa.teagle.top/
绕过:
寻找个任意二级域名*.teagle.top,构造xss
<img src=payload>
3.检测referer中包含指定关键字
将admin.teagle.top放到路径位置,域名换为别的;
成功则说明服务器检测了关键字
Referer: http://www.baidu.com/admin.teagle.top/
绕过:
构造admin.teagle.top目录,将文件放到该目录下
4.检测referer中是否含有指定的域
构造如下Referer,如果成功,则说明服务器检测了域
Referer: http://admin.teagle.top.baidu.com/
绕过:
在自己的域名上添加解析,然后将指定的域名包含进去
其他
昨天遇到一种情况,点击添加购物车后,后面跟了四个请求,针对这种情况,可以按照如下操作来决定决定性请求是哪一个:
1.四个请求走完流程
2.关掉firefox的代理,将history中的四个条目逐个发送到repeate模块
3.删除刚才添加到购物车里的东西
4.四个请求,逐个发送,每发送一次边刷新一次购物车
5.找到那个决定性请求后,删除刚才添加到购物的东西
6.再发送一次刚才发现的请求
7.如果成功,那么说明添加购物车只需要这一个请求,在这个请求上尝试csrf即可
8.如果失败,说明需要多个链接,也就意味着接近GG
七.漏洞防御方式
1) Token
我们知道CSRF攻击的请求除了Cookie以外,其他的内容必须提前确定好,那么如果我们在服务端要求提交的某一个参数中是随机的值呢?
这里我们称这个随机的、无法被预计的值叫做Token,一般是由服务端在接收到用户端请求后生成,返回给用户的Token通常放置在hidden表单或用户的Cookie里。
当用户打开正常的发送请求的页面时,服务器会生成一串随机的Token值给浏览器,在发送请求时带上此Token,服务端验证Token值,如果相匹配才执行相应的操作、销毁原Token以及生成并返回新的Token给用户,这样做不仅仅起到了防御CSRF的作用,还可以防止表单的重复提交。
由于HTML标签产生的合法跨域只能是单向请求,无法通过CSRF直接取返回的内容,所以我们无法使用CSRF先取Token值再构造请求,这使得Token可以起到防御CSRF的作用。
注意Token不应该放置在网页的Url中,如果放在Url中当浏览器自动访问外部资源,如img标签的src属性指向攻击者的服务器,Token会出现作为Referer发送给外部服务器
2) Referer
前边我们提到,CSRF伪造的请求与用户正常的请求相比最大的区别就是请求头中的Referer值不同,使用我们可以根据这点来防御CSRF。
在接收请求的服务端判断请求的Referer头是否为正常的发送请求的页面,如果不是,则进行拦截。
不过此方法有时也存在着一定的漏洞,比如可绕过等,所以最好还是使用Token。
判断Referer的一般方法就是利用正则进行判断,而判断Referer的正则一定要写全,不然就会如上所说,可绕过!曾经的Wooyun上就有许多CSRF的漏洞是由于Referer的正则不规范导致。
比如^http\:\/\/a\.com,只验证了是否Referer是否以http://a.com开头,可是没想到我们可以在自己的顶级域名添加一个子域名http://a.com.hacker.com;还有http\:\/\/a\.com\/,通过http://hacker.com/?http://a.com/绕过。
有些网站由于历史原因会允许空Referer头,当https向http进行跳转时,使用Html标签(如img、iframe)进行CSRF攻击时,请求头是不会带上Referer的,可以达到空Referer的目的。
3)设置SameSite
具体见我博客的另外一篇文章
4) 验证码
在发送请求前先需要输入基于服务端判断的验证码,机制与Token类似,防御CSRF效果非常好,不过此方法对用户的友好度很差。
5) 关注点
关于CSRF的防护应首先关注高危操作的请求,比如:网上转账、修改密码等,其次应重点关注那些可以散播的,比如:分享链接、发送消息等,再者是能辅助散播的,如取用户好友信息等,因为前者加上后者制造出来的CSRF蠕虫虽不如XSS蠕虫威力大,可是也不可小觑。最后应关注那些高权限账户能够进行的特权操作,如:上传文件、添加管理员,在许多渗透测试中,便是起初利用这点一撸到底。
八.CSRF的常用检测方法
1) 黑盒
1.首先肯定确定是否除Cookie外其他参数均可确定,即:无验证码,无Token等。
2.再者如果发现是Referer头判断的话,可以尝试是否可以绕过正则。
3.还有就是考虑能不能绕过Token,比如Url处的Token用加载攻击者服务器上的图片来获取。
4.最后可以考虑与XSS结合,如:攻击者使用iframe跨域,存在xss漏洞的网站插入的XSS执行代码为eval(window.name),那么我们构造的iframe标签里可以添加个name属性与子页面进行通信,
2) 白盒
1.查看是否有Token,验证码,Referer等不确定参数判断。
2.判断Referer的正则是否安全。
3.判断Token返回的位置是否为安全位置。
4.判断生成的Token是否足够随机,毫无规律。
(从上到下挖掘难度依次递增)
参考:
https://www.0x002.com/2019/%E5%85%B3%E4%BA%8ECSRF%E7%9A%84%E9%82%A3%E7%82%B9%E4%BA%8B%E5%84%BF/#0x02-CSRF%E5%8E%9F%E7%90%86
https://www.cnblogs.com/-qing-/p/11015075.html
http://www.teagle.top/index.php/archives/71/