1. 项目背景与前置思路1.1 一次授权测试中的意外突破这篇文章要分享的不是教科书中那种拿到源码慢慢推导的完美漏洞挖掘过程而是我在一次内部授权测试中真实走过的野路子。目标是一个用于安全演练的模拟项目下称靶场系统X包含小程序端和对应的后端管理系统。整个测试过程都有明确的授权和范围限制所有操作都发生在受控的测试环境里这也是一切漏洞挖掘工作的底线。一开始我在小程序端漫无目的地翻功能点原本只想找几个常规的越权问题交差。结果没想到从一个不起眼的越权接口入手顺着数据链一路追最后竟然拿到了任意用户登录的能力。整个过程没有用到什么高深的技术甚至没打数据库纯粹是逻辑层面的一步步推演。如果你是安全测试新人这篇文章可以帮你建立一条完整的测试思路小程序怎么抓包、接口怎么梳理、越权怎么验证、越权数据怎么进一步利用。如果你是开发人员这篇文章同样值得看——很多漏洞不是被“攻破”的而是被“设计”出来的了解攻击者的思考路径才能在后端设计时提前封堵。1.2 越权漏洞为什么如此普遍在开始讲具体过程之前我想先聊一个行业观察在各类安全报告中越权漏洞长期占据Web漏洞排行的前列远超SQL注入和XSS。原因很简单——越权不是某个组件的问题而是业务逻辑层面的缺陷。拿生活打个比方你去银行柜台取钱柜员看了你的身份证知道你是户主本人于是给你办了业务。但如果柜员只看了你的身份证号不核对身份证上的照片和你的脸是否一致那任何人拿着你的身份证号都能取走你的钱。后端接口就是那个柜员它拿到了“用户ID”这个参数却不去核对这个ID对应的会话凭证是否属于当前登录者于是越权就发生了。这种问题的隐蔽性在于正常功能完全可用登录用户A能查到用户A的数据流程上毫无异常。只有测试者刻意去修改请求中的关键标识绕过前端页面的限制才会暴露出权限校验的缺失。2. 小程序测试工具链与流量入口2.1 小程序流量抓包的底层原理小程序和Web网站最大的区别在于入口Web页面跑在浏览器里而小程序跑在宿主App提供的运行时环境中。但无论前端怎么变它终究要向后端发起HTTP/HTTPS请求。只要抓住流量小程序的业务逻辑就对测试者打开了大门。抓包的核心思路是中间人代理——在手机和目标服务器之间架设一个代理节点让所有请求都经过它。常规做法是让手机和电脑处于同一局域网把手机代理指向电脑上监听的代理端口同时给手机安装对应的根证书让代理能解密HTTPS流量。我在实际测试中常用的工具组合是Burp Suite配合手机端代理配置。Burp监听电脑上的8080端口手机开启手动代理后所有小程序发出的请求都会在Burp里呈现包括接口地址、请求参数、响应内容、Cookie和Token。这里有个关键点不少读者会卡在证书安装这一步。小程序宿主环境对自带证书有较严格的校验部分版本的客户端会忽略用户手动安装的根证书导致HTTPS流量照样看不到。解决思路有两种一是优先使用模拟器环境在模拟器里安装证书后抓包成功率更高二是利用宿主App的调试模式在特定启动参数下关闭证书校验这种方式需要在可控环境里操作不在本文展开。提示抓包的关键不是“装上工具”而是理解证书信任链的完整路径——手机信任代理证书、代理替换服务端证书、客户端对证书的校验被规避。任何一个环节失败流量都会静默断开。2.2 接口资产梳理方法抓包成功只是第一步。小程序的流量是碎片化的需要把它变成一张清晰的接口地图才能定位到有价值的目标。我习惯把接口按照功能模块分类梳理登录注册、个人中心、消息通知、订单管理、文件上传、支付回调、管理后台。每个模块单独记录接口路径和请求方式重点关注涉及用户数据的接口例如包含用户ID、订单号、手机号、邮箱这类业务标识的请求。小程序有一个Web网站没有的特点它的前端代码本质上是一份被打包保存的静态资源包括页面逻辑、API调用地址、交互行为都在一起。反编译小程序包后可以直接看到所有API路径清单比纯靠抓包更全面。工具方面常用的小程序解包工具能把小程序包解压成可读的JS源码再配合关键词搜索搜索“api”、“token”、“userId”等接口资产的收集效率会高很多。实际操作中我一般先反编译得到接口清单再在Burp上根据清单逐一向服务端发起请求验证这样能在短时间内覆盖大量接口避免遗漏。2.3 从抓包到发现主路径在靶场系统X的这次测试里我发现小程序的主路径很清晰登录页 → 授权获取手机号 → 绑定账号 → 进入业务首页。首页有几个功能模块其中一个叫“客户档案查询”输入客户编号就能查询对应的档案信息。出于习惯我立刻对这个查询功能上了心。因为它接收外部输入客户编号又必然触发服务端数据查询是越权和注入的高发地带。我在Burp里重新触发了一次查询拿到了完整的请求结构POST /api/customer/query Host: demo-target.example.com Content-Type: application/json X-Access-Token: eyJhbGciOiJIUzI1NiIs...请求体如下{customer_id: 10086}响应返回了该客户的姓名、联系方式和最近的服务记录。整个请求看起来人畜无害但我总感觉哪里不对劲。继续翻小程序页面我发现个人中心里还有一个“我的档案”入口它也有一个查询接口请求体里带的是当前登录用户的ID而不是客户编号。到这里我的注意力集中在了这两类接口——带业务标识的查询接口通常是越权漏洞的温床而对比“当前用户自己的”和“通过业务标识查询的”两类接口就能快速判断服务端是否做了归属校验。3. 越权漏洞的发现与利用方案3.1 从代码层面看越权的本质越权漏洞在开发侧的本质很简单服务端在处理请求时没有把“发起请求的人是谁”与“请求中操作的数据属于谁”这两个概念进行对比。用一个伪代码来说明# 存在越权的写法 def get_customer_info(request): customer_id request.body.get(customer_id) data db.query(SELECT * FROM customer WHERE id ?, customer_id) return data # 正确的写法 def get_customer_info(request): customer_id request.body.get(customer_id) current_user get_session_user(request.session) if not is_owner(current_user, customer_id): return permission_denied() data db.query(SELECT * FROM customer WHERE id ?, customer_id) return data第一种写法只校验了“有没有登录”没有校验“有没有权限操作这个数据”。第二种写法才是一个合格接口应有的逻辑。这也是越权漏洞好挖掘的原因——不需要复杂的攻击载荷只需要合法登录一个账号然后尝试读取别人的数据。挖掘成本极低危害却不小所以它也成为渗透测试中几乎必测的环节。3.2 一次实际发现过程在确认靶场系统X的“客户档案查询”接口后我开始尝试经典的越权测试把customer_id从10086改成10087看会不会返回另一个客户的信息。结果没有让我失望。响应成功返回了10087的档案信息包括姓名、手机号、身份证号和累计消费金额。再改成10088、10089全都返回了对应数据。服务端除了校验X-Access-Token的存在性之外完全没有校验该Token对应的用户是否与目标客户有关联。这是一个标准的水平越权漏洞。如果再深入一步如果是垂直越权普通用户调用管理员接口也能成功。但此时我心里很清楚一个普通的越权能拿到别人的客户信息虽然能证明服务端存在鉴权缺陷但在漏洞报告里也就是中危。我希望让这个漏洞的杀伤力再大一些于是开始琢磨这些数据背后还有什么可利用的东西。3.3 影响评估方法动手前先算账这里想插一个重要的经验发现漏洞后不要急着下结论先想想它能干什么、能走多远。影响评估决定了一个漏洞最终的定级也决定了你在报告中的说服力。我给自己列了一张攻击路径梳理表当前能力可以做什么能不能扩大通过客户ID查任意档案泄露客户敏感信息尝试从响应中寻找Token、密钥通过用户ID查任意个人资料泄露账号绑定信息尝试修改他人资料修改ID遍历所有数据批量获取数据尝试找到管理员的业务标识实际测试中我通过遍历customer_id拿到了一大批数据其中有一条记录引起了我的注意它的客户编号格式和其他客户不一样是一个类似“admin_customer_001”的特殊值。直觉告诉我这个客户可能对应的是系统里的管理端账号。4. 从越权到任意用户登录的升级路径4.1 核心思路顺着数据链找薄弱环节很多测试者拿到越权漏洞后就停止了直接甩一个中危报告走人。这是很可惜的。越权漏洞真正可怕的地方不在于它本身能泄露多少数据而在于泄露的数据往往能成为下一阶段攻击的跳板。我把这种攻击链的构建叫作“顺着数据链找薄弱环节”。越权接口返回的响应包里可能藏着手机号、邮箱、内部标识、Token、临时凭证这些信息单独看都不敏感但组合起来就能打通一条完整的攻击路径。在靶场系统X上我通过越权拿到管理端客户的特殊编号后第一时间尝试用这个编号调用登录相关的接口。多数系统的登录接口支持“手机号验证码”或“用户名密码”两种方式而部分系统还保留了一个调试用的内部登录接口不校验密码只校验用户标识或内部凭证。4.2 演示环境中的攻击链路拆解我在靶场系统X中构造出了完整的攻击链路全部操作均在授权测试范围内进行下面我从原理层面按攻击者的视角把链路拆开来看。第一步利用越权获取特殊用户信息。把customer_id遍历范围扩大到特殊编号附近成功拿到了管理端客户对应的内部ID和所属部门编号。第二步分析登录相关接口。回到小程序登录页重新走了一遍登录流程发现登录请求包含两个阶段先向服务端请求发送短信验证码再携带手机号和验证码换取登录态。但在Burp的接口列表中我注意到还存在一个既没出现在前端代码里、也没有在小程序逻辑中被主动调用的后台接口名为“快速登录”。第三步尝试调用快速登录接口。我按照接口参数的约定尝试传入刚拿到的内部ID和手机号。接口彪悍地返回了一个新的登录Token完全没有校验验证码和密码。我在Burp里请求登录态校验接口确认这个Token有效——它确实是一个合法的管理端会话凭证。到这里任意用户登录漏洞就闭环了不需要知道任何人的手机号和密码只需要通过越权接口拿到目标用户的内部ID再调用快速登录接口就能生成该用户的合法Token完成任意用户登录。4.3 任意用户登录的原理还原复盘这个漏洞根因在于开发者在后端留了一个“后门式”的登录接口为了运维方便在系统里内置了一个快速登录功能通过传入内部ID直接签发Token。设计者的本意可能是方便内部人员调试但问题在于这个接口没有做任何来源限制、权限校验甚至没有做调用频次限制。而当越权接口存在时获取任意用户的内部ID变得易如反掌——两个漏洞叠加攻击成本被压缩到几乎为零越权接口解决了“如何拿到目标用户的唯一标识”的问题。快速登录接口解决了“拿到标识后如何变成目标用户会话”的问题。两步组合攻击者从一名普通用户升级为任意用户包括管理员。世界上没有孤立的漏洞只有没被串起来的漏洞。一个中危的越权漏洞加一个隐藏的调试接口就能变成直接控制任意账号的严重漏洞。这也是我在安全测试中反复体会到的一件事单点漏洞的定级不一定高但攻击链的杀伤力远超想象。5. 漏洞修复与安全防御建议5.1 通用修复方案开发视角针对这次测试暴露出的两类漏洞修复方案其实都不复杂但需要开发团队从机制上落实。越权漏洞的修复核心是建立统一的权限校验中间件。在服务端抽象出一个“资源归属校验”的通用层所有涉及业务标识的查询、修改、删除操作都必须经过这个中间件。校验逻辑就一句话当前登录用户的会话标识所对应的资源集合必须包含目标资源。建议不要在Controller层零散地写判断逻辑因为很容易漏掉某些接口。统一中间件或装饰器才是长期可维护的解法。快速登录类的调试接口必须彻底关闭或单独隔离。生产环境不应该存在任何绕过标准认证流程的入口。如果确实需要运维调试能力建议使用独立的堡垒机方案从网络层、应用层双重隔离并实名人审计访问记录而不是在后端代码里埋一个随时能被调用且无审计的隐藏接口。5.2 小程序特有风险小程序端还有一些不同于Web场景的风险点需要专门关注。小程序包的反编译难度低是一个现实威胁。前端代码里不应该放任何敏感信息包括加密密钥、内部接口地址、调试开关。这些信息一旦被提取攻击者就可以直接绕过前端限制调用后端接口。第二个风险是Token的存储方式。部分小程序开发者为图方便把登录后的Token存在全局变量里但小程序的运行环境存在特殊的生命周期问题——页面切换、App切后台、分享链接进来等场景都可能让Token意外暴露。Token应当存储在宿主环境提供的安全存储区域中并且设置合理的过期时间。第三个风险是小程序的“场景值”机制。攻击者可以通过构造特殊的参数或二维码路径引导小程序带额外参数启动从而污染业务逻辑。所有从小程序外部传入的参数都应当按不可信输入处理。5.3 安全测试后的修复验证流程漏洞修复后不能只靠开发说“改好了”我建议测试者再做一轮验证。验证步骤一般包括先验证越权修复情况。重新用测试账号A查询账号B的数据确认接口返回权限不足。同时要验证绕过方式例如把请求方法从POST改成PUT或者在请求头中添加X-Forwarded-For等代理头确认不会绕过校验。再验证快速登录接口是否已彻底关闭。直接请求该接口确认服务端返回接口不存在或已禁用并且非superadmin权限的请求一律被拒绝。如果接口还在内网环境保留需要确认出口网关是否有隔离策略。最后做回归测试。确认正常用户的登录、查询、修改功能的体验没有受到影响保证修复方案没有破坏业务主链路。关于修复验证还有一条容易被忽视的经验测试者修改的数据或生成的Token要在测试结束后自行删除或失效。我一般会主动联系靶场管理员确认测试期间构造的会话已经全部失效避免给后续运维留下“活口”。6. 写在最后的一点体会这次越权到任意用户登录的测试过程让我在“漏洞挖掘思路”之外有了更大的收获。它让我重新理解了安全建设的顺序很多团队会优先加固Web端、梳理数据库权限、购买防护设备却忽略了应用自身业务逻辑的完整性。我在实际测试中发现真正致命的漏洞往往不是靠高深技术挖出来的而是靠对业务的细心梳理和逻辑串联。你能看到多远的攻击链就能把系统的安全水位提升到多高。这也正是安全测试的价值所在——不是为了证明某套系统有多脆弱而是帮开发者在攻击者真正行动之前补上那些不起眼却致命的缺口。最后再分享一个小经验无论你用的是Burp还是其他工具测试笔记一定要随手记。漏洞点位、参数结构、响应特征、时间节点这些细节在写报告或做复盘时都会派上大用场。好记性不如烂笔头在安全测试这条路上这条法则永远不会过时。