水平与垂直越权:最容易被忽略的「少一行判断」
越权漏洞常年排在 Web 漏洞前列,因为实现成本太低:把 URL 里的 id 改一下就能看别人的数据。
根因是「认证做了,授权没做」:知道你是谁,但没检查这个东西是不是你的。
先说结论
每个对象访问都要校验归属,且默认拒绝。 把校验放进统一中间件,别散落在业务代码里。
- 对象级鉴权:查库时带上 user_id 条件
- 接口默认拒绝,显式放行
- 管理接口与用户接口分离,别靠前端隐藏
- 记录敏感访问日志,便于事后追溯
漏洞是怎么产生的
越权的两种形态:水平(同角色访问他人数据)和垂直(低权限执行高权限操作)。前者更常见,也更容易被扫描器发现。
防御的关键是「以请求者为维度过滤数据」,而不是先取出再判断。
修复与验证
修复不是改一行代码,而是四件事一起做:
- 梳理所有带对象 ID 的接口
- 查询语句加上归属条件(WHERE id=? AND user_id=?)
- 管理类接口做角色校验,且不依赖前端隐藏
- 统一在中间件里做资源归属检查,减少遗漏
- 记录访问日志:谁、什么时候、访问了哪个对象
攻击面与检测点
按影响面排序,先修影响最大的:
| 类型 | 例子 | 修法 |
|---|---|---|
| 水平越权 | 改 order_id 看他人订单 | 查询加 user_id |
| 垂直越权 | 普通用户调管理接口 | 角色校验 |
| 批量接口 | 列表返回全量数据 | 按用户过滤 |
| 间接引用 | 分享链接可猜 | 随机 token + 有效期 |

几个容易踩的坑
下面这些是最常见的错误做法:
- 只在页面隐藏按钮:接口照样能调
- 先查全量再过滤:日志与缓存都可能泄露
- 用自增 ID 做分享链接:可枚举
- 管理员接口用同一套鉴权:角色判断缺失
写在最后
越权不是「技术漏洞」,是「流程漏洞」。把归属校验变成框架能力,才不会再犯。
安全不是一次加固,是持续的假设:假设输入不可信、假设边界会破、假设有人会看错。
评论 (3)
修复清单比漏洞描述有用多了,很多文章只讲怎么打不讲怎么防。
白名单那条永远是最有效的,正则黑名单迟早绕过。
建议再补一条:把这类检查加到 CI 里,靠人记必然漏。
发表评论