1. 信息收集阶段最先动手的地方往往决定后面能不能成事我在接一个SRC项目时第一步向来不是拿扫描器对着域名一顿乱扫。外面很多渗透测试教程会把信息收集讲成一套工具链但到了逻辑漏洞这块工具能帮你的非常有限。真正决定你能不能从普通用户一路摸到后台拿权的往往是你对业务的理解和走一步看一步的思路。1.1 资产收集不只是域名爆破最基础的信息收集当然是资产测绘根域名、子域名、独立IP、旁站、C段这些都要做。但做的时候要带脑子而不是机械地跑一遍字典就完事。举个很常见的场景一家做企业SaaS的公司它的核心资产往往不是官网而是那几个登录进去才能真正干活的子系统——管理后台、开放API、数据导出、客服工单甚至是一个不起眼的内部运维平台。这些系统才是渗透测试中真正值得投入时间的富矿。我一般会把收集结果整理成一张表按价值排优先级资产类型例子价值判断官网/营销站www.example.com低通常无登录攻击面小主业务系统app.example.com高有完整业务逻辑和用户体系管理后台admin.example.com极高目标明确拿到就是后台拿权开放APIapi.example.com高接口通常比Web页面更容易出逻辑问题测试/预发环境test.example.com视情况常有配置遗漏和调试接口这张表里的每一行都是后面测试的入口。我个人的习惯是优先打管理后台和开放API因为它们要么权限非常集中要么因为不是主推产品而疏于维护。很多SRC的高危漏洞最后都出在这两类资产上。1.2 从业务功能里找价值集中点资产收集完下一步是看功能。毫不夸张地说我对一个业务系统的第一眼取决于它有没有注册入口、有没有支付流程、有没有角色权限、有没有文件上传。这四个功能点全部命中基本上可以确定这是SRC上容易出货的系统。注册入口意味着你能拿到一个合法身份所有后续的越权测试都建立在这个身份上支付流程意味着有钱和数量参数可以篡改角色权限意味着存在垂直越权的可能性文件上传则通常和拿到服务器权限挂钩。这四个功能点刚好对应了逻辑漏洞的大部分常见场景。1.3 把信息收集的终点变成一张业务逻辑图我习惯在信息收集收尾时画一张简单的业务逻辑图——不需要多精美几行文字就行用户→注册→登录→浏览→下单→支付→查看订单→申请售后管理员→登录→用户管理→订单管理→配置管理。画完这张图你其实已经隐隐约约看到了哪些环节容易出现以为做了校验实际却没做全的问题。这一步做完才进入真正的测试环节。信息收集恰恰是很多人忽略的地方——他们急着拿工具跑结果跑出来的都是别人已经修过的漏洞。逻辑漏洞的测试从来不是靠工具的它靠的是对业务的理解。2. 逻辑漏洞的博弈感为什么它比SQL注入更能体现测试水平2.1 自动化工具的盲区正好是逻辑漏洞的藏身之处你拿常规漏扫工具扫一个站能扫出来SQL注入、XSS、文件包含这些常规问题但这些往往也是厂商自测时最容易发现的问题。逻辑漏洞不一样工具扫不出来因为它不属于某个固定的漏洞类型而是程序员的预期和现实之间的差距。举一个最典型的例子一个电商系统的下单接口前端页面做了库存校验当库存不足时下单按钮会置灰。但攻击者直接抓包绕过前端把购买数量改成1绕过了库存限制。问题在于库存校验做在前端还是后端很多系统会把这类业务校验放在前端后端只接参数然后生成订单。这种情况下即使库存只剩50件你也能下100件的单。这就是逻辑漏洞的博弈感攻击者站在开发者视角看问题找到开发者和测试者之间信息的缝隙。开发者认为前端已经校验过了后端不用再校验一遍但攻击者知道所有前端校验都是可以绕过的前提。2.2 高频出现的逻辑漏洞类型按我这两年跑SRC的经验逻辑漏洞大致能分这么几类越权类水平越权改一个ID就能看到别人的数据和垂直越权普通用户调用管理员接口。这是逻辑漏洞里出现频率最高的也是通往后台拿权最直接的路径。验证码类验证码不失效、短信验证码不校验服务端session、对同一个手机号不限制发送次数导致短信轰炸。支付类修改金额、修改数量、价格篡改、优惠券重用、支付状态轮询绕过。条件竞争类同时并发请求导致积分、余额、库存被重复计账。状态机绕过类跳过某个必填步骤比如跳过支付直接进入发货流程。每一类背后都有一个共同的根源服务端没有对关键业务环节做完整的状态校验或者权限校验。逻辑漏洞之所以不好修是因为修复往往要动业务核心代码甚至要重构接口设计而不像SQL注入那样加个参数化查询就行。2.3 判断标准能不能证明、能不能复现、有没有实际影响很多新手在SRC上提交漏洞被驳回最大原因不是漏洞不存在而是无法证明影响。判断逻辑漏洞能不能报我个人的标准就三条第一能不能用两个普通账号稳定复现。第二越权或篡改有没有实际的数据影响比如订单、余额、个人信息。第三影响面有多大是影响单个用户还是全平台。我见过不少人在测试一个系统时发现某个接口没有鉴权就直接报了未授权访问结果平台回复该接口本身设计为公开接口。这其实不是漏洞是误报。在提交之前把业务语义搞清楚比多报一个漏洞有用多了。换句话说提交报告之前先站在厂商的角度问自己一遍这个行为是设计如此还是确实是校验缺失3. 实战复盘从注册到普通用户再从一个接口翻到后台为了把前面的方法论落到具体例子里我讲一个去掉敏感信息的SRC项目记录。目标是某个企业的客户管理系统资产清单里有一个主业务站点和一个运营后台。主站支持注册后台没有对外注册入口。这个配置非常典型也是后面一切故事的起点。3.1 从合法身份入手先在主站注册了A和B两个普通账号这是越权测试的基本配置。测试订单、用户信息、权限这类接口都得有至少两个身份才能做对照。这一步没啥技术含量但非常重要——没有对照组的越权测试基本等于盲人摸象。登录之后我习惯先看浏览器的开发者工具里加载了哪些JS文件再配合Burp Suite抓包看请求。为什么看JS现在很多前后端分离的项目接口清单和参数结构全写在JS里甚至有些注释里会残留测试用的接口地址。我在这类文件里翻到过不少隐藏的内部接口这次也不例外。3.2 水平越权把别人的订单看作自己的测试订单查看功能的时候我抓到这样一个请求GET /api/order/detail?orderId10086响应返回当前账号的订单详情。我直接在Burp里把orderId改成10087响应里出现了另一个账号的订单数据。再看字段里面包含收货人姓名、手机号、详细地址。这一下就是标准水平越权漏洞而且批量遍历orderId可以拿到全量订单信息属于信息泄露。但我没有着急把它提交我想要的权限比这个更高。水平越权虽然能过审但定级通常在高危边缘而且在不涉及金融数据的系统上平台经常只给中危。它更大的价值在于证明这个系统的鉴权设计有重大问题可以作为后续垂直越权漏洞的前置铺垫。3.3 翻JS文件找到管理员用的内部接口继续翻JS文件我在一个叫admin.bundle.js的压缩文件里看到了几个管理端接口的调用路径类似/api/admin/user/list /api/admin/user/role/update这里有个关键判断这些接口写在主站域名的JS里说明管理后台和用户端共用了一套后端API网关。那么问题来了这些接口的鉴权是怎么实现的我带着普通用户的token直接请求了/api/admin/user/list返回401 Unauthorized。这说明有登录态校验但401只验证了你登录了没有并没有验证你是不是管理员。带着这个怀疑我把注意力转移到了/api/admin/user/role/update这个接口上。从名字看这是一个更新用户角色的接口。这类接口的常见写法是接收两个参数目标用户ID和要设置的角色ID。如果它只校验登录态、不校验调用者角色那就意味着任意登录用户都能把自己或别人改成管理员。3.4 从角色字段修改到后台登录我先从自己的用户信息接口里拿到当前账号的roleId返回的是1。JS文件里有一段常量配置注释里写着角色枚举1为普通用户2为管理员。我构造了这样一个请求POST /api/admin/user/role/update userId自己的用户ID roleId2正常来说这个接口应该拒绝普通用户调用。但响应回来了200 OK。我退出账号重新登录发现账号角色已经变成了管理员菜单栏里多出了用户管理、订单管理、数据导出这些原本看不到的功能。点进用户管理能看到所有注册用户的信息列表包括管理员账号的登录名和手机号。到这里普通用户变成了后台管理员后台拿权完成。到这里我没有继续往下探测。SRC测试的核心边界是证明漏洞存在、讲清楚影响而不是真的把整个后台翻一遍更不是去下载全量数据。截图记录好漏洞点和影响之后我直接退出开始准备报告。4. 拿到后台权限之后证明影响与守住边界同等重要4.1 拿权不是终点证明才是得到管理员权限之后第一件事不是兴奋而是冷静下来做证明。你需要给厂商一个能复现的路径让他们相信这不是误报。截图或录屏是必须的我通常按这个顺序保留证据当前账号修改角色前的个人信息截图要能看到角色字段是普通用户。调用的关键请求的Burp截图包括URL、请求体、响应状态码。修改后的响应和重新登录后的菜单截图证明权限提升成功。证据链要完整每一张截图都要能对上复现步骤中的一句话。很多人在报告里只贴最后一张我是管理员的截图平台工程师根本无法判断你是怎么变成管理员的这种报告很容易被打回要求补充。4.2 影响要落到业务语言上影响部分要落到业务语言而不是技术语言。比如写任意登录用户可通过构造请求提升为管理员进而查看全量用户手机号、地址信息和订单数据这句话比存在一个逻辑漏洞有用得多。厂商评估漏洞等级时看的是这个影响而不是你用了什么炫酷的技巧打进去的。这里我习惯做一个小对比漏洞发现前普通用户能做什么漏洞利用后管理员能做什么。把差异写清楚平台才好定级。比如在这次案例里普通用户只能看自己的订单管理员能看到所有人的订单和用户资料影响面从一个人变成了整个平台定级自然就上去了。4.3 边界控制哪些事绝对不能做SRC平台的测试和真实的授权众测有很大区别前者是有限授权后者才是全面对抗。拿到管理员权限后以下这些事绝对不能做不要下载或导出全量用户数据哪怕只是为了测试。证明风险存在即可验证时用小范围数据就够了比如只读取一条测试账号的数据。不要对授权范围外的系统继续渗透。哪怕你发现隔壁系统也有漏洞只要不在任务范围里都不能碰。不要尝试读取管理员密码或重置管理员账号更不要修改任何生产数据。你测试用的普通账号是你自己注册的可以随便改但别人的数据一根手指头都不能动。守住边界你的报告才会被认可一旦越界轻则漏洞作废重则面临封号甚至更严重的后果。这在我接触过的圈子里有不止一次惨痛教训。5. 报告环节的第二场博弈让漏洞定级配得上它的影响5.1 平台是怎么给逻辑漏洞定级的各大厂商SRC平台和公益SRC平台的定级逻辑大同小异一般分严重、高危、中危、低危四个等级。对逻辑漏洞来说定级主要看影响面能直接进后台拿权的垂直越权通常是高危起步涉及大量用户敏感信息泄露的水平越权一般也是高危只影响单个用户且数据价值不高的往往是中低危。这里有个微妙的地方同一个漏洞在不同平台、不同业务场景下的定级可能不一样。一个涉及金融数据系统的水平越权和一个只涉及公开信息系统的水平越权定级会差很多。所以选对漏洞提交的平台也很重要有些专项SRC对敏感系统有更高的奖励评级。5.2 我固定使用的报告结构写报告这件事我踩过不少坑后来沉淀出一个固定结构每次照着填报告模块内容要点漏洞标题明确到功能点例如用户订单接口未校验归属权限任意用户可遍历订单号泄露他人信息漏洞类型逻辑漏洞-水平越权/垂直越权影响等级按自己的评估填写附上理由复现步骤每一步配一张截图按时间顺序写影响分析落到业务语言说明影响对象和范围修复建议给出可执行的修复方向标题尤其重要。很多平台的审核员一天要看几十份报告标题写得含含糊糊的很容易被压到低优先级。标题里把哪个接口、什么问题、什么影响一次说清楚审核员一眼就能判断该找谁去验证。5.3 常见驳回原因和避免方式根据个人经验逻辑漏洞的报告被驳回常见原因无非这几种影响证明不足。只有一个状态码200没有展示实际影响到的数据。复现步骤不清晰。漏掉了某个前置条件审核员按步骤复现不出来。业务语义没搞清。把设计如此当成漏洞来报比如注册接口支持弱密码平台可能认为这是产品设计而非漏洞。自己都没完全搞清楚原理。报告里说不清楚为什么能越权审核员也无法确认是不是误报。还有一个容易踩的坑当你在同一个系统里发现多个同类型逻辑漏洞时不要一个一个提交。平台通常会把同根因的漏洞合并处理提交太多反而显得像是在凑数量。选影响最大的那个提交然后在报告末尾注明同类接口可能还有多处建议统一排查这样反而能体现专业度。6. 攻击复盘的反面如果这套系统由我来修6.1 从这次测试链路反推修复清单每次测试结束我都会站在开发和安全团队的角度重新过一遍漏洞链路这算是逼自己从攻击者思维切回防御者思维。对应这次案例修复点其实非常明确/api/order/detail接口必须校验订单归属服务端要从token里取当前用户ID再判断该订单是否属于当前用户而不是只信任前端传的orderId。/api/admin/user/role/update接口必须校验调用者的角色只有管理员才能调用而且要区分登录态校验和权限校验这是两个层面的事。管理端接口和普通用户接口不能共用同一套无差别的登录态校验逻辑至少要在网关层做角色路由隔离。前端的admin.bundle.js不应该暴露内部接口的调用路径建议把管理端静态资源和用户端静态资源分开部署。6.2 通用防护思路把这次测试再抽象一层能看到几个通用的防护原则统一鉴权组件。所有涉及数据查询和权限修改的接口必须走同一个鉴权组件而不是每个接口自己写一段token解析逻辑。组件内部要同时校验身份和角色。服务端校验一切业务参数。前端传上来的金额、数量、角色ID、步骤编号全部要当作不可信数据对待该用服务端数据替代的就用服务端数据替代。关键业务步骤加状态机。比如订单从待支付到已支付再到待发货每一步只能从前置状态流转过来不能跳跃。敏感操作加审计日志。谁在什么时间改了什么权限、查了什么数据全部记录。这既是安全要求也是出了事后追溯的救命稻草。6.3 给刚入门的人几句实在话如果你刚开始接触渗透测试和SRC漏洞挖掘我的建议是先从公益SRC平台的真实项目练手不要一上来就想着打大型厂商。公益项目目标多、范围清晰、对新人友好哪怕挖到的是中低危漏洞也能积累提交记录和报告经验。测试的时候多整理自己的逻辑漏洞测试清单把每一种场景的请求特征记下来。比如越权测试核心动作就是替换身份标识——把请求里的订单号、用户ID、角色ID换掉观察响应是否变化。这个动作看起来简单但能坚持在每个功能点上都做一遍的人并不多。最后电子取证式地保留好每一份证据。记录漏洞的技术细节是次要的锻炼自己的思路才是主要的。跑SRC这行很多人一开始靠的是运气但能持续出货的靠的是对业务的理解和对边界的敬畏。这句话是我在复盘里最常提醒自己的也送给看到这里的你。