垂直权限漏洞与水平权限漏洞

一、水平权限漏洞

简单举例：假设A可以更改1 2 3三条数据 而B可以更改 2 3条数据。

那么我们一般会怎么做呢，会让用户A查询到123条数据，而用户B查询到23条数据

但是一般情况下，我们是对接口做的做的权限验证 此时B权限会拿到23条数据，那么B提交修改的时候只需要将修改的id更改成1的id即可（很多情况下我们会使用主键自增长的方式），所以很容易出现问题。

修复方案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来吧。

总结：方案0是不可行方案。

          方案一：说是在web层逻辑中做鉴权限，只能把1数据从数据库中取出，并判断该用户时候有查询该数据的权限，所以说是可以的。

         方案二：是可行的在service中进行校验即可

         方案三：可行，在服务端生成md5参数，并将参数作为token传入到页面，页面提交的时需要提交token及id，提交上来再用md5进行验证一次，就知道该数据是不是页面显示的数据了。

 

二、垂直权限漏洞

指的是没有对访问接口做权限验证。