水平权限漏洞一般出现在一个用户对象关联多个其他对象 (订单地址等) 并且要实现对关联对象的 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); 在处理请求时, 用 addressIdsessionId 和 key 来验证 token 这样的方案实现起来很简单, 又不增加额外的 SQL 查询开销, 看起来比方案 1 更好可我之前没有想到过这种方案, 乍一看又是把鉴权和操作这一串同步的操作异步化了(实际上是在生成表单的时候鉴权并生成 token, 然后在操作时只验证 token 而不鉴权), 所以一时还拿不准这样会不会有啥问题~不过我是想了半天也找不到漏洞哈~
修复方案 4:
把这种属主权限对象操作的场景抽象成一个统一的框架, 在框架内一个地方实现权限的管理和检查当然这个说起来有点扯淡了, 在产品设计阶段是不是有人愿意花大成本来设计相关框架呢? 如果最开始没有框架, 那么什么时候愿意花更大的成本去迁移呢? 我想最终还是会按方案 123 来吧
另外的方法:
1 可对 ID 加密
2 使用 GUID
3 每一个信息增加一个发布人的字段, 修改的人必须与发布的人为同一个人才可以访问
来源: http://www.bubuko.com/infodetail-2499140.html