原文：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、每一个信息增加一个发布人的字段，修改的人必须与发布的人为同一个人才可以访问