跨站点请求伪造漏洞(转自javaeye)

项目用appscan探测出的安全问题,以前没有接触过这方面的知识,在javaeye上看到一篇还不错的文章。

在不追求成功率的情况下,跨站点请求伪造的攻击成本相对较低,门槛儿也不高,有点姜太公钓鱼,愿者上钩的味道。实际上,JE就从一定程度上存在此漏洞,不过根据我的实验结果,JE已经从很大程度上防范了此攻击,所以风险不大。下面我来讲解一下如何利用JE的此漏洞干点儿坏事。
鉴于这里都是Ajax高手,以下说明中尽量避免出现代码,只说原理。有兴趣的话自己动手一试便知。
攻击目标:让被攻击者A在自己不知情的情况下给B发送若干条站内短信。
步骤:
    1. 确定JE发送站内短信的http请求地址,参数等。你自己可以随便给一个好友发送一条站内短信,同时使用httpwatch或firebug记录请求内容即可。
2. 发布一个有诱惑性的网页,上面写些技术文章或者别的能吸引A的东西。最重要的是,要有一个指向JE的超链接。
3. 在上述网页中跑一段JS代码,这段代码循环调用第1步中你记录的地址以及包含你自己构造的短信内容的请求参数。注意,请求要用post方式发送,因为JE已经在发端信的请求处理上禁用了get方式。
至此,大功告成,剩下的就是等着A登录JE。一旦他登录,你的JS代码就可以发起攻击了。B下次上线后会收到A发送的若干条站内短信,而短信内容完全由你决定。
以上就是跨站点请求伪造的基本思路。
真的这么简单吗?当然不是,以上攻击需要至少两个条件才能成功。首先,A要使用IE6这种经过他自己确认就可以跨站点发送请求的浏览器(所谓愿者上钩),而FF和chrome都不允许。其次,A打开JE后没有关闭你的页面,这就要看你的造化了。
其实正是因为JE禁止了get请求,才使得这个攻击的成功率大打折扣。如果其他被攻击的站点允许发送get请求,那么我们就可以大大地强化攻击。那就是跨域的利器img和script。只要给这两个html元素的src赋值,它们便会自动发起跨域请求,而且浏览器不会给出任何安全提示。设想一个极其粗糙的银行网站如果具备被攻击的条件的话将会是什么后果?你完全不需要知道客户的卡号和密码就可以把他的钱轻松转帐了。实际上早期的gmail就存在这样的漏洞,攻击者可以轻松搞到被攻击者的联系人列表。
如何防范呢?目前我了解的有两种思路。
方案一:每个请求都带上一个由服务器生成的随机参数。然后在服务器端和对该参数,如果和下发的随机数不同,则可以认为有人在伪造请求。因为攻击者无法知道他本次攻击的http请求需要带什么样的随机数才是有效的。
方案二:跨域伪造之所以能成功,主要决定因素是攻击者的页面和稍候被打开的目标页面共享session信息。受害者登录后,攻击者的页面通过ajax向被攻击网站的关键业务发起的请求便自动带上了合法的session信息。但是,根据javascript的同源策略可知,挂有A域名的窗口,不能获取挂有B域名窗口中的任何信息,不管B是如何被打开的。据此,我们有了另一套防范策略。在客户端的每个要保护的业务链接上增加一个参数sessionId,这个参数可以通过js从cookie中获得。然后,在务器端获取此参数,并同真正的sessionId做对比,如果不同,则认为请求是伪造的。因为攻击者的窗口无法从被攻击网站的窗口中取得这个sessionId。据说很多ajax框架都已经自带了此功能。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值