1. 访问控制漏洞的本质与分类做Web安全的时间久了你会发现真正难搞的往往不是SQL注入、文件上传这类“看起来就危险”的漏洞而是藏在业务逻辑里的访问控制问题。所谓访问控制简单讲就是系统判断“你是谁”以及“你能做什么”的那道门。一旦这道门的设计有缺陷攻击者不需要什么花哨的注入技巧只需要在正常请求里稍微动点手脚就能干出越权的事情。我最早系统接触这块内容是在某知名Web安全训练平台上刷访问控制模块一个Lab一个Lab过从最初的“直接访问隐藏管理页”到后面利用参数覆盖绕过限制每次攻破一个Lab都会有一种“原来如此”的顿悟。这个平台把访问控制相关的漏洞场景做得非常实战化每种漏洞模式都有对应的靶场环境非常适合用来建立攻防直觉。1.1 从逻辑漏洞的视角理解访问控制访问控制漏洞之所以被归为逻辑漏洞是因为它往往不是代码层面的语法错误而是业务逻辑设计上的缺陷。比如某个URL没有做权限校验、某个接口信任了前端传过来的角色参数、某个下载功能直接用了用户可控的文件名。这些问题不像SQL注入那样有统一的特征更多时候要靠手动测试和业务理解去发现。从攻击者的角度访问控制的核心关注点是系统是否在服务端严格验证了每一个请求的权限。很多开发人员以为隐藏了入口、或者在前端把按钮藏起来就安全了实际上服务端不做校验就等同于把门敞开。我听A同学分享过一次经历他们公司内部系统有个管理后台URL是/admin开发觉得这个地址没人知道就安全了结果被扫描器直接爬出来后台页面完全没有任何鉴权直接用浏览器打开就能看到所有用户数据。这就是典型的基于URL的访问控制缺失。1.2 三种越权类型及其危害访问控制漏洞在实战中最常见的就是越权按方向可以分三类类型简单理解典型场景未授权访问不需要登录或未被授权就能访问受限资源管理后台、内页接口、敏感API水平越权同级别用户之间跨越访问A用户操作B用户的订单、查看他人私密信息垂直越权低权限用户访问高权限功能普通用户执行管理员操作、访问管理接口三种越权的危害都很直接。未授权访问可能导致整个后台沦陷水平越权能批量获取用户隐私垂直越权则是权限体系的崩塌。在攻防演练中越权漏洞是红队最爱的突破口之一因为利用成本低、成功率高很多时候只需要改一个ID或者加一个参数。2. 基于URL的访问控制绕过这一章是访问控制最基础但也最容易踩坑的环节。基于URL的访问控制通常指系统通过路径来判断权限比如管理员页面在/admin下普通用户不能访问。实际测试时这类漏洞的利用方式非常丰富远不止“直接访问URL”那么简单。2.1 隐藏目录与直接请求我在刷靶场时碰到的第一个经典案例就是“未受保护的管理功能”。系统在导航菜单中把Admin面板的链接隐藏了只给管理员角色的用户显示。很多人以为这样就安全了但直接访问/admin路径发现页面完全可访问权限校验只存在于前端渲染层面服务端没有拒绝普通用户的请求。测试要点很简单把正常的浏览请求丢进代理工具比如Burp Suite观察所有响应包和JS文件用目录扫描或者手动猜测常见路径。如果一个管理功能的URL可以被普通用户直接请求且返回200那就说明未授权访问存在。注意这里有一个很容易被忽略的点就是“登录后”的未授权访问。很多系统要求登录后才可访问/admin但任何登录用户包括普通用户都能访问管理员功能这同样属于访问控制缺陷。测试时要同时关注“未登录直接访问”和“低权限登录用户访问高权限路径”两种情况。实操时建议用Burp的站点地图先把应用完整爬一遍然后逐个请求点右键“Send to Repeater”手工检查响应码和响应内容。如果看到一个管理接口返回了普通数据别急着高兴先确认当前请求的Cookie是普通用户还是匿名状态避免判断错误。2.2 参数篡改与HTTP方法变换这一章最值得玩味的是绕过手法。有些系统会在URL参数里传角色标识比如/admin?admintrue或者通过隐藏参数roleuser来区分权限。开发的初衷可能是方便调试但一旦上线没删掉就变成了一扇后门。我见过一个靶场案例用户资料页面可以修改昵称请求POST到/account参数里带了一个roleid1。最初我以为只是普通信息更新但这其实是一个“角色由请求参数控制”的漏洞。把roleid改成2并提交再次访问/admin时就获得了管理员权限。整个流程没有任何绕过只是多提交了一个参数。另一个常见手法是HTTP方法变换。有些服务端配置限制了GET /admin/deleteUser但没有限制POST、HEAD、OPTIONS等。比如某系统只对GET方法做了权限校验把请求改成POST /admin/deleteUser居然就能绕过。这本质上是框架或中间件配置问题但测试时非常实用。我通常会在Repeater里手动切换Method或者在Burp的Intruder里批量跑方法看哪个方法能返回成功。顺便提一个容易被忽略的“路径规范化”绕过/admin、/admin/、//admin、/./admin、/admin%20这些写法在部分中间件里会被解析成同一个路径但权限过滤器分组时不一定能覆盖所有写法。碰到拦截严格的系统可以尝试这些变体。3. 基于身份的越权实战如果说URL层面的访问控制是“门锁”那基于身份的越权就是“门卡发错了”。系统能识别用户是谁但在判断用户该不该访问某个对象时出了纰漏。这种漏洞在业务系统里特别常见尤其是那些直接暴露ID的接口。3.1 水平越权IDOR实例详解IDORInsecure Direct Object References不安全的直接对象引用是水平越权最常见的形式之一。比如一个查看订单详情的接口/api/order?id1001本来只允许“用户A”查看自己的订单。但服务端只校验了参数id对应的订单是否存在没有校验当前登录用户是否属于这个订单那么把id改成1002就能查看别人的订单。在靶场练习时我遇到一个“通过请求参数中的用户ID越权”的Lab。操作路径是登录账号A后用Burp抓包查看个人信息接口请求路径是/myaccount?idalice。把id换成bob响应中直接返回了bob的API key。破解思路很简单但要真的在真实系统中落地还需要先弄清楚用户标识是用户名还是数字ID、是明文还是编码后的字符串。有些系统会做一层“障眼法”比如把ID做一次base64编码、把数字ID换成UUID。我见过一个系统把用户ID用十六进制字符串传输开始以为无法猜测后来发现就是十进制ID的十六进制表示1001变成0x3E9。这种看似安全、实则没用的编码反而能误导开发人员的检查。实操心得测试水平越权时建议准备两个低权限测试账号如user1、user2先分别抓取各自的正常请求保存好Cookie。然后用user1的会话去请求user2特有的资源比如订单、私信、文件逐一替换ID字段。观察响应里的业务数据是否包含对方的敏感信息。如果条件允许可以用Burp的Comparer对比两个响应的差异快速定位越权点。3.2 垂直越权角色参数与信息泄露水平越权是“同级别窜门”垂直越权则是“用员工卡刷开了经理办公室”。垂直越权通常表现为低权限用户能操作高权限功能最常见的实现原因是角色信息被前端传给了后端并直接采用。我刷过一个“用户角色由请求参数控制”的Lab登录普通账号个人信息接口返回的JSON里包含role: 1。修改为role: 2后再请求管理功能接口响应码从403变成了200。很多新手容易忽略一点后端到底拿什么参数判断角色是Cookie里的session是Header字段还是请求体里的字段这需要逐个尝试。有些系统会把角色信息写进JWT或Cookie但没有做签名验证用户可以直接篡改里面role字段再重新提交。测试时把Cookie或Token丢到jwt.io解码基地看一下如果没有签名或者使用弱密钥如secret就可以本地修改role为admin重新构造Token提交。另外有时候垂直越权不直接体现在一个接口上而是信息泄露。比如管理员打开一个包含用户列表的页面时用了和普通用户一样的接口/api/userlist但普通用户请求时返回403。问题往往出在某处缓存或默认页面上。有一次我测试某系统普通用户访问/admin被拦截但直接访问/admin/userlist居然返回了完整数据因为前端路由做了拦截后端接口却没有按目录统一鉴权。4. 其他绕过手法与多维防护访问控制测试不能只盯着URL和参数HTTP头、跨域策略、JSONP回调、文件下载路径等都可能成为绕过点。这一节我把自己实际用过的几个技巧整理出来顺带聊聊怎么从防御角度堵住这些口子。4.1 Referer、CORS与特殊场景处理有些系统用Referer头来判断请求来源认为只要Referer是本站域名就放行否则拦截。绕过方法很简单把请求改成GET /admin/deleteUser?usernamex然后手动在Repeater里删掉Referer头或者改成https://example.com/admin/anything很多基于Referer的校验就会被绕过。因为Referer本身就是一个客户端可控的请求头用来做鉴权等同于裸奔。CORS跨域资源共享错误配置同样值得关注。如果系统反射了请求中的Origin头到响应头的Access-Control-Allow-Origin并且允许携带Cookie那攻击者可以构造一个恶意页面在受害者浏览器里向目标系统发送跨域请求读取敏感响应。测试方法是在Burp里发送请求时加上Origin: https://evil.com观察响应是否包含Access-Control-Allow-Origin: https://evil.com和Access-Control-Allow-Credentials: true。如果两个同时出现就存在CORS越权风险。还有一种场景是文件下载路径的直接对象引用。比如接口/download?filereport.pdf没有校验文件归属把参数改成../../etc/passwd或他人文件名就能下载任意文件。这种问题和IDOR本质相同重点在于服务端没有把“当前用户是否有权访问该文件”纳入校验。JSONP接口也偶尔会踩坑。某些网站为了解决跨域取数开放了?callbackjsonpCallback这样的接口响应直接是callback({...})。如果返回的数据包含用户隐私且接口没有校验Referer恶意网站就能通过script标签读取这些数据。测试时关注响应是否包含敏感业务数据以及校验强度是否只依赖Referer。4.2 纵深防御与修复建议防住越权绝不能只依赖前端隐藏按钮或URL不可预测。真正稳妥的做法是在代码层面统一做权限校验具体来说有这几个方向第一服务端强制鉴权。任何管理功能接口在后端入口处就要校验当前用户角色不能信任前端传过来的角色字段。建议用统一的鉴权框架在过滤器或拦截器里集中校验而不是在每个Controller里零散判断。第二对象级权限校验。对于通过ID操作资源的接口不能只校验资源是否存在还要校验当前登录用户是否与该资源有关联。比如订单接口要从服务端获取当前用户的userId去订单表里检查这个订单是否属于该用户而不是直接信任请求里的userId参数。第三避免在URL中出现敏感角色参数。admintrue这种参数一旦上线就是定时炸弹。如果有历史代码建议做全局搜索把这类参数全部移除或改为后端会话读取。第四配置好HTTP方法策略。限制管理接口仅接受POST或PUT避免通过GET修改数据同时在网关上配置允许的方法白名单过滤掉HEAD、OPTIONS等非常规请求。提示防御视角和攻击视角是镜像关系。每次做完越权测试我都建议从开发者的角度再走一遍这个资源如果在服务端强制鉴权了没有如果我把请求里的所有可控参数去掉接口还能不能正常工作能说明逻辑上可能存在问题。5. 常见问题与排查技巧实录访问控制测试看起来简单实际操作中坑却不少。有些问题不是漏洞不存在而是我们没测对。下面把我在练习和实战中遇到的典型问题整理成一个速查表顺便分享几个能提高效率的小工具习惯。5.1 抓包工具配置要点用Burp套件测试访问控制时最基础但也最常出错的点就是代理设置。如果你用的是浏览器插件方式千万记得把“通过Burp代理”打开并且装好HTTPS证书否则抓不到HTTPS明文包。在Burp里我习惯这样配置Proxy - Options - Proxy Listeners确认监听地址是127.0.0.1:8080浏览器代理指向这里。安装证书后在Proxy Settings里开启“Intercept”开关逐个检查请求也可以关掉拦截让流量直接经过从HTTP History里筛选。测试越权时一定要在Repeater里修改请求而不是用浏览器开发者工具改因为浏览器工具没法方便地修改Cookie和Header组合。有一个小技巧如果目标应用使用的是JSON API建议在HTTP History顶部过滤时输入/api/快速看到所有接口。再用Burp的“Site map”展开功能树重点看哪些路径含有admin、user、account、role这些关键词通常漏洞点就藏在这里面。5.2 越权测试踩坑记录踩坑一没区分“未登录”和“普通用户”状态。我发现不少新手在测试某接口时直接用未登录状态下发请求看到403就认为存在访问控制。这不一定准确因为很多接口要求先登录但登录后用普通用户请求却是200。反过来有些接口未登录可以访问但登录后被拒这种情况也值得深挖。最稳妥的做法是准备三套状态未登录、普通用户A、普通用户B分别测试目标接口。踩坑二丢了原始Cookie。在Repeater里测试时最好每一套账号的Cookie单独保存下来放在不同Repeater Tab里。不要一边测试一边复制粘贴Cookie很容易混淆尤其是目标系统Cookie带会话超时的时候白忙一场。踩坑三只测了GET没测POST。很多访问控制漏洞只在某个方法上放开比如POST接口做了鉴权但GET接口没有或者反过来。建议每个URL都至少换Method测一遍。方法变了服务端的路由匹配和过滤链可能会有完全不一样的行为。踩坑四忽略了响应码的误导。有些接口对越权请求返回200但响应体是统一的错误提示JSON如果没仔细看响应内容就以为漏洞成立会导致误报。判断越权成功的标准应该是“响应中是否包含目标用户的真实数据”而不是只看响应码。踩坑五没有验证数据的“可见性”。有时候改了ID发现响应里确实多了一些字段但这些字段可能本来就是公开信息比如商品价格、状态。真正的高危越权往往涉及手机号、邮箱、订单收货地址、管理操作记录等敏感数据。所以判断越权时要关注数据敏感度而不是把所有能改ID的接口都当成洞。个人经验做访问控制测试前我会先花10分钟梳理目标系统的用户体系和资源模型画出简单的权限矩阵。哪些接口是面向普通用户的哪些是面向管理员的哪些对象属于用户私有资源理清之后再动手测试效率会高很多。如果拿到一个接口就能看出它的资源归属和权限要求后面基本就是在验证猜测了。对我个人来说越权漏洞之所以迷人就在于它纯粹是“逻辑上的疏忽”不需要复杂的工具链也不需要0day一条改过ID的HTTP请求就能撬开整栋楼。但反过来说这类漏洞的修复成本也极低只要后端每一层都守住校验攻击者的所有花招都会失效。希望这篇基于靶场实战的梳理能帮你在攻防思路和权限模型理解上都更进一步。
