CSRF漏洞攻击原理及防御方案

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

CSRF漏洞攻击原理及防御方案
作者美创科技安全实验室
一.CSRF介绍
CSRF(Cross-site request forgery)全称“跨站请求伪造”,也被称为“One Click Attack”或者“Session Riding”,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。

尽管听起来像跨站脚本(XSS),但它与XSS非常不同。

XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。

与XSS攻击相比,CSRF攻击往往更加难以防范。

可以这么理解CSRF攻击:攻击者盗用了你的身份,以你的名义进行某些非法操作。

CSRF能够使用你的账户发送邮件,获取你的敏感信息,甚至盗走你的账户。

二.CSRF的危害
1、篡改目标网站上的用户数据;
2、盗取用户隐私数据;
3、作为其他攻击向量的辅助攻击手法;
4、传播CSRF蠕虫。

三.CSRF攻击原理及过程
如上图所示,CSRF攻击攻击原理及过程如下:
1.用户打开浏览器,访问受信任银行网站A,输入用户名和密码请求登录网站;
2.在用户信息通过验证后,网站产生Cookie信息并返回给浏览器,此时用户登录网站成功,可以正常发送请求到网站;
3.用户未退出银行网站之前,在同一浏览器中,打开一个TAB页访问其他网站B;
4.这时候网站B已被黑客注入诱导信息,假如是一张图片,图片地址指向黑客构造的恶意url,该url能完成黑客想干的某件事,比如修改用户的密码;
5.多数情况下,浏览器接收到这个url请求会失败,因为它要求用户的认证信息。

但是,如果用户还未退出网站A,或者当时恰巧刚访问网站A不久,他的浏览器与网站A之间的session尚未过期,浏览器的cookie之中含有用户的认证信息。

这时,悲剧发生了,这个url请求就会得到响应,黑客就能以用户的权限修改密码,且用户毫不知情。

CSRF攻击的本质原因:
CSRF攻击是源于WEB的隐式身份验证机制!WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器,但却无法保证该请求是用户批准发送的!
四.CSRF的特点
➢攻击一般发起在第三方网站,而不是被攻击的网站。

被攻击的网站无法防止攻击发生。

➢攻击利用受害者在被攻击网站的登录凭证,冒充受害者提交操作;而不是直接窃取数据。

➢整个过程攻击者并不能获取到受害者的登录凭证,仅仅是“冒用”。

➢跨站请求可以用各种方式:图片URL、超链接、CORS、Form提交等等。

部分请求方式可以直接嵌入在第三方论坛、文章中,难以进行追踪。

CSRF通常是跨域的,因为外域通常更容易被攻击者掌控。

但是如果本域下有容易被利用的功能,比如可以发图和链接的论坛和评论区,攻击可以直接在本域下进行,而且这种攻击更加危险。

五.CSRF漏洞利用
利用DVWA靶场进行CSRF漏洞演练:
修改密码为123456,点击change,网页url中暴露出要修改的密码,并且能够发现url的构造如下:
http://127.0.0.1/dwva/vulnerabilities/csrf/?password_new=admin&password_conf=ad min&Change=Change#
为此,我们可以利用漏洞,构造链接:
http://127.0.0.1/DVWA/vulnerabilities/csrf/?password_new=111&password_conf=111 &Change=Change
诱导受害者点击这个页面,当受害者进入这个页面时,就已经受到了csrf的攻击。

当他重新登录时会发现用自己修改的密码(123456)登录不上
用攻击方设定的密码(111)就可以成功登陆。

六.CSRF防御方案
1.检验HTTP Referer来源
2.在请求地址中添加token并验证
3.在HTTP头中自定义属性并验证
4.设置验证码
5.尽量使用POST接口,限制GET接口
下面就分别对这5种策略进行详细介绍:
①检验HTTP Referer来源:
根据HTTP协议,在HTTP头中有一个字段叫Referer,它记录了该HTTP请求的来源地址。

大多数情况下,当浏览器发起一个HTTP请求,其中的Referer标识了请求是从哪里发起的。

如果HTTP头里包含有Referer的时候,我们可以区分请求是同域下还是跨站发起的,因为Referer 标明了发起请求的URL。

网站也可以通过判断有问题的请求是否是同域下发起的来防御CSRF 攻击。

但是即使这样,验证HTTP Referer字段这种方式也存在安全隐患:
1.对于某些浏览器,比如IE6或FF2,目前已经有一些方法可以篡改Referer值
2.用户自己可以设置浏览器使其在发送请求时不再提供Referer
②在请求地址中添加token并验证
CSRF攻击之所以能够成功,是因为黑客可以完全伪造用户的请求,该请求中所有的用户验证信息都是存在于cookie中,因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的cookie来通过安全验证。

要抵御CSRF,关键在于在请求中放入黑客所不能伪造的信息,并且该信息不存在于cookie之中。

可以在HTTP请求中以参数的形式加入一个随机产生的token,并在服务器端建立一个拦截器来验证这个token,如果请求中没有token或者token内容不正确,则认为可能是CSRF攻击而拒绝该请求。

这种方法要比检查Referer要安全一些,token可以在用户登陆后产生并放于session之中,然后在每次请求时把token从session中拿出,与请求中的token进行比对。

③在HTTP头中自定义属性并验证
这种方法也是使用token并进行验证,和上一种方法不同的是,这里并不是把token以参数的形式置于HTTP请求之中,而是把它放到HTTP头中自定义的属性里。

通过XMLHttpRequest这个类,可以一次性给所有该类请求加上csrftoken这个HTTP头属性,并把token值放入其中。

这样解决了上种方法在请求中加入token的不便,同时,通过XMLHttpRequest请求的地址不会被记录到浏览器的地址栏,也不用担心token会透过Referer泄露到其他网站中去。

④验证码
在发送请求前先需要输入基于服务端判断的验证码,强制用户必须与应用进行交互,才能完成最终请求。

在通常情况下,验证码能很好遏制CSRF攻击。

但是出于用户体验考虑,网站不能给所有的操作都加上验证码。

因此验证码只能作为一种辅助手段,不能作为主要解决方案。

⑤尽量使用POST接口,限制GET接口
GET接口太容易被拿来做CSRF攻击,只要构造一个链接,便可以进行CSRF攻击。

接口最好限制为POST使用,降低攻击风险。

当然POST并不是万无一失,攻击者只要构造一个form就可以,但需要在第三方页面做,这样就增加暴露的可能性。

相关文档
最新文档