其他分享
首页 > 其他分享> > Web系统常见安全漏洞介绍及解决方案-CSRF攻击

Web系统常见安全漏洞介绍及解决方案-CSRF攻击

作者:互联网

简介

CSRF跨站请求伪造,全称Cross-site request forgery,是指利用受害者尚未失效的身份认证信息(cookie、会话等),诱骗其点击恶意链接或者访问包含攻击代码的页面,在受害人不知情的情况下以受害者的身份向(身份认证信息所对应的)服务器发送请求,从而完成非法操作(如转账、改密等)。CSRF是Web安全中最容易被忽略的一种攻击方式,但某些时候却能产生强大的破坏性。
在这里插入图片描述

CSRF 攻击原理

伪造GET/POST请求

在CSRF攻击流行之初,曾经很多人认为CSRF只能由GET请求发起,因此很多开发者认为只要把重要的操作改成只允许POST请求就能防止CSRF攻击。
这种错误的观点形成的原因在于,大多数CSRF发起攻击时,使用的都是 //

在2007年Gmail CSRF漏洞攻击过程中安全研究者pdp展示了这个技巧:
首先用户需要登录Gmail账户以便获取Gmail的临时Cookie,然后攻击者诱使用户访问一个恶意页面,在这个恶意页面中隐藏了一个iframe,iframe的地址指向pdp写的一个恶意链接,这个链接的实际作用就是把参数生成一个POST表单并提交。pdp的攻击脚本会在邮箱的Filter中新建一条规则,把所有带附件的邮件都转发到攻击者指定的邮箱,由于浏览器中已经存在Gmail的临时Cookie,所以这个请求会成功。

CSRF 蠕虫

2008年9月百度曾经受到CSRF蠕虫病毒攻击,漏洞出现在百度用户中心的发送短消息功能中:

http://msg.baidu.com/?ct=22&cm=MailSend&tn=bmSubmit&sn=用户账户&con=消息内容

这个链接只要修改参数sn即可对指定的用户发送短消息,而攻击者发现另一个接口能查询出某个用户的所有好友,将两者结合起来,可以组成一个CSRF Worm-让一个百度用户查看恶意页面后,将给他的所有好友发送一条短消息,然后这个短消息中又包含一张图片,其地址再次指向CSRF页面,使得这些好友再次将消息发给他们的好友,这个Worm因此得以传播。
这个蠕虫很好的展示了CSRF的破坏性-即使没有Xss漏洞,仅仅是CSRF也是能够发起大规模蠕虫攻击的

CSRF 防御

下面看看有什么方法可以防御这种攻击。

1.验证码

验证码被认为是对抗CSRF攻击最简洁而有效的防御方法。
CSRF攻击的过程,往往是在用户不知情的情况下构造了网络请求,而验证码强制用户必须与应用进行交互才能完成最终请求。但是很多时候,出于对用户体验考虑,网站不能给所有的操作都加上验证码,因此验证码只能作为防御CSRF的一种辅助手段,而不能作为最主要的解决方案。

2.Referer Check

Referer Check即通过验证 HTTP请求头中的Referer 字段检查请求是否来自合法的“源”,检查Referer是否合法来判断用户是否被CSRF攻击。HTTP 头中有一个字段叫 Referer,它记录了该 HTTP 请求的来源地址。比如一个发博客的操作,正常情况下需要先登录到发博客页面,提交“发布”的表单时Referer的只必然是发博客表单所有的页面,如果Referer的值不是这个页面,甚至不是发博客的域,则很有可能受到CSRF攻击。
Referer Check的缺陷在于,服务器并非什么时候都能够取到Referer,很多用户(或浏览器)出于隐私保护的考虑,限制了Referer的发送。

3.使用token验证

CSRF为什么能攻击成功?其本质原因时重要操作的所有参数都是可以被攻击者猜测到的。现在业界对CSRF的防御,一致的做法就是增加一个参数–Token。Token必须足够随机(使用足够安全的随机数生成算法),它应该作为一个“秘密”存在于服务器和浏览器中,不被第三方知晓。由于Token的存在,攻击者无法再构造出一个完整的url实施攻击。实际应用时,Token可以放在用户的Session或者浏览器的Cookie中,在提交请求时,服务器只需验证表单中的Token与用户传过来的Token(Session或Cookie中)是否一致,如果一致则认为是合法请求;如果不一致,则认为请求不合法,可能发生了CSRF攻击。

转自:程序员 https://www.dianjilingqu.com/

标签:Web,浏览器,请求,攻击,用户,Referer,CSRF,安全漏洞
来源: https://www.cnblogs.com/yuanyuzhou/p/16495834.html