越权访问漏洞如何处理

上个月某电商平台做促销，越权一个白帽子顺手把购物车里的访问商品价格改成0.01元，居然直接下单成功了。漏洞理这不是何处黑客技术多高明，而是越权后端接口压根没校验“这个订单是不是属于当前登录用户”。这就是访问典型的越权访问——你用自己的账号，干成了别人的漏洞理事。

越权漏洞分两种。何处水平越权是越权你看得到隔壁老王的订单、地址、访问甚至聊天记录；垂直越权更狠，漏洞理普通用户直接调用管理员接口，何处删库跑路都行。越权我见过最离谱的访问案例，某政府网站的漏洞理分页参数里直接带用户ID，把ID改成别人的，就能看到对方的身份证扫描件。这种漏洞不是难发现，是开发者默认“用户不会乱改参数”。

处理办法其实不复杂。核心就一条：**后端必须校验资源归属权**。前端隐藏按钮、禁用输入框统统不可靠，因为请求可以直接用Postman发。你需要在每个涉及数据查询或操作的接口里，拿当前登录用户的session或token，去和资源所属的用户ID比对。对不上就返回403，别犹豫。

具体落地时，我建议从三个层面堵漏。

第一层，接口设计上强制走统一鉴权中间件。别把“判断是否登录”和“判断是否有权操作”混在一起。登录校验是基础门槛，权限校验是房间钥匙。很多团队只做了前者，以为登录了就万事大吉——大错特错。用户登录后能访问的资源范围，必须由后端逻辑单独划定。

第二层，对资源ID做不可预测化处理。把自增ID换成UUID或者哈希值，能大幅提高水平越权的利用难度。虽然这不是根本解法，但能挡掉大量脚本小子。有个朋友的公司做过统计，把订单号从纯数字改成随机串后，被撞库扫描的频率直接降了七成。

第三层，写自动化测试去模拟越权场景。每次上线前，用两个测试账号互相访问对方的资源，断言返回结果必须是403或404。这个测试用例写起来很快，但绝大多数团队压根没做。原因？排期紧、嫌麻烦、觉得“之前没出过事”。等出了事再补，代价就是用户数据泄露加公关危机。

还有个细节容易漏：批量导出功能。比如导出Excel报表，很多人只校验了“是否登录”，没校验“这些数据是否属于当前角色”。结果一个普通员工能把全公司薪资表拉下来。这类接口建议单独走审批流程，或者强制二次身份验证。

别指望靠安全扫描器全自动发现越权。这类漏洞本质上属于业务逻辑漏洞，扫描器只能扫出“没有鉴权”，扫不出“鉴权范围不对”。最有效的发现方式，还是人工代码审计加渗透测试。找个懂业务的开发，仔细看每个接口的数据流，比上十台扫描设备都管用。

处理越权漏洞没什么高深理论，就是别偷懒。每个接口都问一句：这个用户真的有权看这份数据吗？多问几次，漏洞自然就少了。