内容摘要：某次渗透测试，甲方给了一个内部管理系统。登录框干干净净，密码框上方赫然写着“仅限内网使用”。我随手在URL末尾加了/admin，服务器回了个200。页面加载出来，是个用户管理后台，连登录校验都没有——

某次渗透测试，网站甲方给了一个内部管理系统。权限登录框干干净净，绕过密码框上方赫然写着“仅限内网使用”。网站我随手在URL末尾加了/admin，权限服务器回了个200。绕过页面加载出来，网站是权限个用户管理后台，连登录校验都没有——开发把“内网”当成了安全边界，绕过忘了外网也能访问这台机器。网站

这类问题太常见了。权限权限绕过的绕过本质，不是网站攻击者多高明，而是权限开发对“信任边界”的理解出了偏差。他们默认某些路径、绕过某些接口、某些请求方式天然安全，可现实里，这些假设脆弱得像纸糊的墙。

另一种典型是越权。平行越权最无脑：修改URL里的ID，比如把user_id=1001改成1002，就能看到别人的订单。垂直越权稍微费点劲，但也没多难。有次测试一个OA系统，普通账号访问/api/exportAllUsers，接口直接吐回全部员工手机号。后端只校验了“是否登录”，压根没校验“是否有权限”。

你问修复难吗？难，也不难。难在开发得先承认自己写错了，不难在方法就那几招。服务端做二次鉴权，每个请求都校验角色和资源归属，别信前端隐藏按钮那套把戏。前端隐藏菜单只是UI层面的“眼不见为净”，后端接口该暴露还是暴露。

还有个隐蔽角落——HTTP方法篡改。某系统删除功能只允许POST，但后端没限制方法。我用PUT /deleteUser试了试，服务器愣了半秒，然后返回200。开发只拦了POST，忘了其他方法也能触发同一个业务逻辑。这类问题在RESTful接口里尤其多，因为开发者习惯性把“POST=增、DELETE=删”当教条，却没在代码里真正实现方法级控制。

说到这，得提一嘴参数污染。一个支付系统，金额字段在前端被加密，看似安全。我直接往请求里多塞了个同名参数，比如amount=100&amount=0，后端取参数时取了第一个，校验通过；但真正扣款逻辑用了第二个。结果呢？0元买了100块的会员。这种漏洞在PHP和Java的某些框架里特别容易出，因为不同解析器对重复参数的处理规则不一样。

写这些不是让你去黑谁，是想说：权限绕过往往不是技术对抗，而是逻辑博弈。攻击者做的，就是找出开发脑子里那个“想当然”的瞬间。你多问一句“如果这个请求不是浏览器发出来的呢”，很多洞就能提前堵上。

最后补个真实观察：我见过的权限绕过漏洞，超过一半不是黑客挖出来的，是开发自己测试时不小心发现的——只是他们改完代码就忘了删测试入口。所以啊，别光盯着外部攻击，先把自己留的后门清干净。安全这活儿，有时候就是跟自己较劲。