Zhbk
- 关注
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
前言
和小伙伴在公司边上班边挖挣外快,怎么挣各位师傅应该知道的,看到他挖到了某平台的CSRF,挣到了外快,心里很不是滋味,凭啥他可以,我就不行。我不信,我一定能挖出一个CSRF。
CSRF介绍
以下内容摘自百度百科:
CSRF一般指跨站请求伪造是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨网站脚本(XSS)相比,XSS 利用的是用户对指定网站的信任,CSRF 利用的是网站对用户网页浏览器的信任。
跨站请求攻击,简单地说,是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作(如发邮件,发消息,甚至财产操作如转账和购买商品)。由于浏览器曾经认证过,所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞:简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的。
作者的自我理:
假设有攻击者A和被攻击者B,网站服务器为Server
此时,B正在访问网站服务器Server且在登陆状态,A发送了构造的攻击页面给B,B在登陆状态时点击攻击页面,那么此时就会构成B向Server发送A想要攻击的东西。站在Server角度来讲,Server接受到的请求包是B给我的,因此对B产生一些变化(可能是密码、发帖等)。
CSRF危害
CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于购买商品,虚拟货币转账……造成的问题包括:个人隐私泄露以及财产安全。(还是蛮严重的,在挖掘的过程中发现很多中小企业都不重视,包括一些漏洞平台)
CSRF防御
检查Referer字段
HTTP头中有一个Referer字段,这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时,通常来说,Referer字段应和请求的地址位于同一域名下。
添加校验token
由于CSRF的本质在于攻击者欺骗用户去访问自己设置的地址,所以如果要求在访问敏感数据请求时,要求用户浏览器提供不保存在cookie中,并且攻击者无法伪造的数据作为校验,那么攻击者就无法再运行CSRF攻击。
记一次CSRF
模拟攻击者A,模拟被攻击者B
重码!!!(有点丑,你忍一下!!)
登陆A账号,进来后发现有修改密码模块,这就想起CSRF了,毕竟小伙伴刚分享过,这不点进去瞧一瞧
看到输入框只让我输入新密码和确认新密码,这口水流下来了,这不百分八十拿捏了存在CSRF漏洞??
输入密码进行抓包,可以看到请求包中的参数只有password,两次输入的密码,并没有token什么的,做到这里暗自窃喜。(心里想着:好家伙,百分九十就是有了!!!)
接下来利用burp生成csrf的poc,虽然简单,但是能用就行(真香.jpg)
将生成的poc复制到自己建立的页面1.html中
分析分析poc,就是一个简单的html语句,当然,为了讲究真实,可以加上其他元素,让它变成一个精美的网站,然后在挂到网上或者哪里,就可以构成一个钓鱼页面。
接下来,模拟被攻击者B
还是一样,先登陆网站
模拟攻击者点击A建立的攻击页面,这儿我们可以抓包看一下,点击后,他发送更改密码的请求包到服务器上。
正常点击后会出现下面这张图的情况,经过unicode解码,发现这串的意思是,修改失败。但是,然并卵,人家真的就只是一串字符串而已,是真修改成功了。
发现密码还是修改成功,并且能成功登陆。
总结
还记得第一次学到CSRF还是从老师的课件上学到的,一直没能亲身实践,入职后小伙伴跟我说自己挖了个CSRF的洞,让我瞧一瞧才想起来的。其实感觉很多中小企业的网站都存在这个漏洞,虽然这个漏洞的利用条件有点苛刻,但是如果真正带来损失了,那平台是有一定的责任的。
如需授权、对文章有疑问或需删除稿件,请联系 FreeBuf 客服小蜜蜂(微信:freebee1024)