水平权限漏洞的修复方案

作者: 康康 分类: Web安全 发布时间: 2017-04-17 21:17

原文:http://hi.baidu.com/kussa/item/a85912058445c7dcdce5b01d

水平权限漏洞一般出现在一个用户对象关联多个其他对象(订单、地址等)、并且要实现对关联对象的CRUD的时候。开发容易习惯性的在生成CRUD表单(或AJAX请求)的时候根据认证过的用户身份来找出其有权限的被操作对象id,提供入口,然后让用户提交请求,并根据这个id来操作相关对象。在处理CRUD请求时,往往默认只有有权限的用户才能得到入口,进而才能操作相关对象,因此就不再校验权限了。可悲剧的是大多数对象的ID都被设置为自增整型,所以攻击者只要对相关id加1、减1、直至遍历,就可以操作其他用户所关联的对象了。

 

水平权限漏洞的原理看似简单,但他和开发的思维、编码习惯刚好相反,因此会经常冒出来。尤其是WAP和AJAX接口,开发者往往不把这些接口当作HTTP请求看,增加了很多其实不存在的有利于安全假设条件,从而导致更加忽视对权限的鉴别。

 

因为这类关联对象的操作都和业务相关,且接口独立,所以很难实现通用的预防或解决方案,这也是这类漏洞让人头疼的原因之一。今天在修复一个水平权限漏洞时,给开发同学介绍了下水平权限漏洞的修复方案,而开发同学又提出了一个我之前没想过的方法,因此决定一起整理出来。

 

漏洞示例:

getAddress.do?addressId=12345

攻击者修改addressId即可得到他人的address信息。

 

修复方案0:

先看一个有问题的方案:将addressid改成一个具有一定长度的随机字符串,如5d41402abc4b2a76b9719d911017c592,认为只有有权限的人才能得到这个入口,而且不能通过加1、减1的方式预测别人的入口,因此不再做进一步的权限检查(很多初级的招聘页面都是以这种方式来管理简历的)。这个方案看上去没有问题,可是和国内的环境结合起来就会悲剧——至少我遇到过的,搜狗浏览器会把用户发送的请求上传到服务器上,作为其搜索引擎爬虫的爬取源,这样爬虫就会通告查询操作得到相关的对象信息,并展示在搜索引擎上,如果对象信息包含敏感内容,则产生隐私泄露的安全事件。

 

修复方案1:

这个是最直接有效的修复方案:在web层的逻辑中做鉴权,检查提交CRUD请求的操作者(通过session信息得到)与目标对象的权限所有者(查数据库)是否一致,如果不一致则阻断。这个方案实现成本低、能确保漏洞的修复质量,缺点是增加了一次查库操作。我之前一直用这种方案来对已发生的水平权限漏洞做紧急修复。

 

修复方案2:

我认为最正规的方案:把权限的控制转移到数据接口层中,避免出现select/update/delete … where addressID=#addressID#的SQL语句,使用selectt/update/delete… where addressID=#addressID# and ownerId=#userId#来代替,要求web层在调用数据接口层的接口时额外提供userid,而这个userid在web层看来只能通过seesion来取到。这样在面对水平权限攻击时,web层的开发者不用额外花精力去注意鉴权的事情,也不需要增加一个SQL来专门判断权限——如果权限不对的话,那个and条件就满足不了,SQL自然就找不到相关对象去操作。而且这个方案对于一个接口多个地方使用的情况也比较有利,不需要每个地方都鉴权了。但这个方案的缺陷在于实现起来要改动底层的设计,所以不适合作为修复方案,更适合作为统一的控制方案在最开始设计时就注意这方面的问题。

 

修复方案3:

今天开发同学提到一种我之前没想到过的方式,实际上是对方案1的修改:在生成表单时,增加一个token参数,而token=md5(addressId+sessionId+key);在处理请求时,用addressId、sessionId和key来验证token。这样的方案实现起来很简单,又不增加额外的SQL查询开销,看起来比方案1更好。可我之前没有想到过这种方案,乍一看又是把鉴权和操作这一串同步的操作异步化了(实际上是在生成表单的时候鉴权并生成token,然后在操作时只验证token而不鉴权),所以一时还拿不准这样会不会有啥问题~不过我是想了半天也找不到漏洞哈~

 

修复方案4:

把这种属主、权限、对象、操作的场景抽象成一个统一的框架,在框架内一个地方实现权限的管理和检查。当然这个说起来有点扯淡了,在产品设计阶段是不是有人愿意花大成本来设计相关框架呢?如果最开始没有框架,那么什么时候愿意花更大的成本去迁移呢?我想最终还是会按方案1、2、3来吧。

 

 

 

 

另外的方法:

1、可对ID加密

2、使用GUID

3、每一个信息增加一个发布人的字段,修改的人必须与发布的人为同一个人才可以访问

发表评论

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