CSRF漏洞复习总结

一.漏洞解释

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

具体见我博客的另外一篇文章

SameSite cookies科普

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/

为您推荐

发表评论

电子邮件地址不会被公开。 必填项已用*标注