越权漏洞原理

一个电商平台，越权原理用户A登录后修改自己的漏洞收货地址，顺手把URL里的越权原理userId=1001改成userId=1002，页面居然显示了用户B的漏洞订单详情。这不是越权原理巧合，也不是漏洞系统抽风，这就是越权原理典型的越权漏洞——你拿到了不属于你的权限，干了不该干的漏洞事。

越权的越权原理本质，是漏洞服务器太信任客户端。它把用户身份的越权原理判断权交给了前端参数，自己却懒得核实。漏洞比如上面的越权原理例子，后端只根据URL里的漏洞userId去数据库查数据，却没验证这个userId是越权原理不是当前登录者。攻击者不需要什么高深技巧，改个数字就能横着走。

这种漏洞分两种。一种是水平越权——你只能看自己的订单，结果能看别人的。另一种是垂直越权——普通用户能访问管理员的后台接口。水平越权是“平级乱窜”，垂直越权是“以下犯上”。两者都致命，但垂直越权往往更隐蔽，因为管理员功能通常藏在深层菜单里，普通用户根本看不到入口。可接口地址就摆在那，比如/admin/deleteUser，你直接拿普通账号的cookie去请求，如果后端没判断角色，系统就乖乖执行了。

我见过最离谱的案例，是一家SaaS公司。他们的文件分享功能，用一串递增的数字当文件ID。用户上传合同后，把分享链接里的ID减1，就能看到前一个用户上传的商业计划书。整个数据库就像一本翻开的书，页码还是连续的。这哪是漏洞，这是把保险柜的密码写在柜门上了。

为什么这种漏洞屡禁不止？因为开发者的思维惯性——默认“用户会按规矩来”。写接口时只想着“查询ID为5的数据”，却忘了问一句“ID为5的数据，属于当前这个用户吗？”尤其是内部管理系统，开发时觉得“反正是内网，没人乱来”，结果一上线就暴露在公网。等被薅羊毛了才醒悟，数据已经被拖走好几轮了。

修复思路其实不复杂。服务端必须强制校验会话身份——所有操作都从session或token里取用户标识，而不是从请求参数里拿。水平越权要检查资源归属，垂直越权要校验角色权限。更狠一点的做法，是给每个资源加随机UUID，让攻击者没法靠猜ID遍历数据。但说到底，最关键的还是开发者脑子里那根弦：永远别信任用户传过来的任何东西，哪怕只是个数字。

越权漏洞不像SQL注入那样需要构造复杂payload，它更像一种“逻辑上的懒惰”。攻击者只是顺着系统的设计逻辑多走了一步，而你恰好没在门口拦他。这提醒我们，安全不只是堆防火墙和WAF，更是每一行代码里对“我是谁，你能干什么”的反复追问。毕竟，漏洞利用的往往不是代码缺陷，而是信任的错付。