做SRC这几年我最大的感受是逻辑漏洞才是决定你拿低危还是拿后台的分水岭。信息收集人人都在做扫描器也满地都是但很多人在收集完子域名、扫完端口之后就卡住了不知道下一步该干什么。而真正的实战高手往往是在信息收集阶段就把业务线上的逻辑弱点想清楚了然后在测试阶段用少量请求精准命中要害。今天这篇记录就是一次典型的从信息收集开始一路利用逻辑漏洞组合拳拿到后台管理权限的完整过程我会把每一步的思路、判断依据和踩过的坑都写清楚希望对正在入门SRC漏洞挖掘、或者想提升渗透测试实战思路的朋友有帮助。这篇文章适合三类人看刚开始接触SRC、不知道从哪下手的萌新能扫出漏洞但老是拿不到高危的进阶选手以及做企业安全防护、想搞清楚攻击者怎么“用逻辑打败技术”的防守方。无论你是哪一类我相信里面提到的思路都比单纯的漏洞列表更有价值因为思路才是可以复用的漏洞清单第二天就过期了。1. 信息收集看似都在做实则90%的人没做透1.1 资产测绘的层次感不是把域名扔进字典就完事很多教程都在教子域名爆破、IP反查、证书透明度查询这当然没错但SRC实战里的信息收集真正的核心不是“找到更多域名”而是建立一张业务地图。我见过太多人收集了几百个子域名然后打开扫描器一顿乱扫最后交上去的全是低危信息泄露而正确打开方式是先想清楚目标企业到底有哪些主要业务线再针对每一条业务线去定向找资产。举个例子假设目标是一家电商公司常见的业务线包括Web商城、移动端App接口、小程序、商家后台、供应链管理系统、客服系统、运营后台。每一个业务系统都有独立的登录体系、独立的权限模型、独立的功能逻辑。你在主站上可能花了三天都找不到问题但商家后台的某个订单导出功能也许就是一个越权漏洞的重灾区。具体操作上我建议分三步走从主域名发散用子域名收集工具拿到全量子域名列表然后逐个访问确认每个系统的业务类型这个环节不要扫只是看看清楚每个系统是干什么的。从证书和JS文件找线索很多后台系统不会直接暴露在子域名列表里但会在主站的JS文件中留下API路径、内网地址、第三方服务地址。打开浏览器开发者工具过滤JS文件搜索api、admin、backend、internal这些关键词经常能有意外收获。从移动端反推如果目标有App直接抓包看接口域名移动端的接口往往比Web端少一层防护而且经常存在版本不一致导致的逻辑差异。提示信息收集阶段别急着上扫描器。先拿着域名列表一个个手动点过去把每个系统的首页截图保存标注清楚是什么业务这一步花两小时后面能省两天。1.2 从功能点反推逻辑漏洞收集的是攻击面不是域名列表信息收集的真正产出不应该是“我找到了50个子域名”这个数字而是一张功能清单。比如你发现了一个“订单查询”页面就要立刻在大脑里建立假设这个查询有没有水平越权订单号是不是可枚举的查询参数里有没有隐藏的用户ID我把功能点分成几类每一类对应着不同的逻辑漏洞挖掘侧重登录注册类验证码是否可绕过、用户名枚举、密码重置逻辑、登录后的会话固定攻击。业务流转类订单状态是否可以任意修改、支付成功后是否可以重复回调、审批流程是否可以越级操作。文件交互类上传的文件是否校验类型、下载路径是否存在目录穿越、导入导出是否有权限校验。个人中心类查看/修改个人资料时的IDOR、手机号绑定逻辑、收货地址的越权读写。这些功能点在信息收集阶段就应该被全部标记出来然后你带着这张清单进入测试阶段就会非常有目的性。1.3 关于信息收集的合规边界这里必须多说一句我强调的收集目标严格限定在被授权测试的SRC资产范围之内。SRC平台通常会明确标注域名范围也有robots协议、隐私政策等边界。任何超出授权范围的探测本质上都不是渗透测试而是违法行为。这是一个底线问题也是每个从业者都必须时刻提醒自己的事情。真正的技术能力是在合规的前提下用最小代价获取最大战果而不是无差别扫描全网。另外国内SRC对授权范围非常敏感有些域名字面上看是同一家公司但可能属于不同的法人实体。信息收集的时候我会直接对照SRC平台公布的资产清单只在这个清单内活动。漏掉几个边缘资产不可惜踩了合规红线才是真完蛋。2. 逻辑漏洞的分类与识别从“能出洞”到“一眼看穿”2.1 越权漏洞SRC中出现频率最高、也最容易被误解的一类越权漏洞之所以在SRC里占比极高是因为现代Web应用的权限判断往往分散在每一个接口里只要有一个接口忘了校验漏洞就产生了。越权分为水平越权和垂直越权实战中两者的利用难度和危害等级是完全不同的。水平越权就是你登录A用户的账号通过修改ID、订单号、手机号等参数能操作B用户的数据。这种漏洞在个人中心、订单查询、消息通知这类模块里极为常见。垂直越权就是普通用户调用了管理员的接口。比如你发现一个/api/admin/exportUserData这种接口普通用户的Cookie也能正常返回数据那恭喜你这是一个标准的垂直越权通常可以直接定级高危。判断越权漏洞有一个非常关键的技巧不要只改参数就发请求要先搞清楚这个接口的鉴权模型。比如说有的接口虽然也返回了其他用户的数据但这是因为前端根据登录状态动态生成了请求参数服务端本身是有校验的这种就是误报。真正的越权是服务端缺失校验导致你手动改了参数之后数据照样返回。我建议测试时把原始响应和修改参数后的响应同时截图保留这是后续写报告的重要依据。2.2 密码重置逻辑老生常谈但永远有新坑密码重置几乎是逻辑漏洞的“兵家必争之地”。这里的核心思路不是能不能重置密码而是重置流程中能不能被插入恶意操作。常见的问题点有这么几个验证码绑定手机号缺陷有些系统发送验证码时后台只校验了“验证码是否正确”却没有校验“验证码是否发送给当前请求的手机号”。你用自己的手机号收验证码然后在提交重置密码的请求里把手机号改成目标的手机号验证码照样可以通过。响应内容泄露验证码部分开发为了方便调试把验证码直接放在HTTP响应的JSON字段里返回给前端虽然前端不展示但你抓包就能看到。修改密码后旧会话未失效重置密码成功后旧token仍然有效攻击者可以继续用旧token操作账号这种虽然不直接导致初始入侵但会放大其他漏洞的危害。密码重置与身份凭证分离重置密码成功后系统没有强制重新登录用户身份凭证仍以某种形式保持在请求链中导致可以绕过新密码直接保持登录态。测试密码重置功能时我的建议是完整走一遍正常流程再逐节点尝试插入异常操作而不是直接上来就改包。你要先理解正常流程里每一步的校验关系才能准确地插入攻击步骤。2.3 业务顺序绕过流程设计缺陷远比代码SQL注入隐蔽业务顺序绕过是我个人觉得最“有意思”的一类逻辑漏洞。它不涉及具体的注入、上传或者命令执行纯粹是业务流程设计上的缺陷。最常见的场景就是“先操作后校验”。比如一个典型的兑换码兑换流程正确顺序应该是验证兑换码是否有效抵扣用户账户金额发放兑换权益某次测试中我发现在请求的第4步“确认兑换”时删除掉请求里关于“抵扣金额”的交互参数系统会直接跳过金额校验进入发放权益流程。这种问题用自动化扫描器是完全扫不出来的只能靠人手工分析请求与请求之间的依赖关系才能发现。另一个思路是并发逻辑。有些系统在领取活动奖励时后端只判断了“当前用户是否已领取”但判断和置标记之间有一个时间差。你用多个线程同时发出领取请求就可以绕过这个判断逻辑实现多次领取。这类问题通常被称为“并发绕过”在业务逻辑测试中非常经典。2.4 验证码与频率限制赢在细节的攻防博弈很多逻辑漏洞之所以能得手前提是绕过了验证码和频率限制。我在实战中总结了一些高频可用的绕过思路供参考验证码不失效同一个验证码可以重复使用在爆破密码时每次都用同一个绕过了数量限制。验证码返回字段可见如前面所说验证码在JSON响应中返回直接读包即可。请求体中删除验证码字段有的后端在接收参数时如果发现没有验证码字段就直接跳过验证逻辑走“无验证码”分支。空值绕过把验证码字段的值设为空字符串服务端判空逻辑写反了导致空值通过了校验。X-Forwarded-For头伪造频率限制是基于IP的伪造XFF头即可绕过这种方式虽然老但仍然大量有效。这些细节看起来不起眼但在真实SRC链路中往往就是你能否继续往下打的关键节点。一个短信验证码能不能绕过决定了你能不能进入密码重置流程一个图片验证码的校验是否严格决定了你能不能对登录接口做爆破。3. 链路设计从几个“低危”到后台拿权的组合拳3.1 别急着提交先想想漏洞之间能不能串起来很多新人拿到一个越权漏洞就兴冲冲提交了定级不高还觉得SRC平台不认。实际上单个逻辑漏洞可能只是中低危但如果能串成一条链路危害就是指数级上升。这次案例里我最初发现的只是三个看起来平平无奇的逻辑问题一个手机号绑定逻辑缺陷、一个后台接口权限缺失、一个验证码返回的响应信息泄露。单独看这三个每一个最高也就中危但当我继续往下深挖时发现它们可以被串联通过手机号绑定逻辑缺陷将一个目标管理员账号的手机号替换成我的通过验证码响应泄露获取到重置验证码成功重置管理员密码后配合那个后台接口权限缺失直接以管理员身份调用敏感功能。这样一条链路走下来危害等级直接从中低危拉满到严重。SRC平台最终给的评级和奖金也完全取决于最后这一步的组合。3.2 后台拿权的关键节点登录态、会话、接口权限从攻击者的角度来复盘这次后台拿权真正拿到的“权”是什么呢是管理员级别的会话权限。这里其实有一个值得强调的技术判断拿到一个有限的接口权限和拿到一个完整的后台会话完全是两码事。在实际测试中我并不会一上来就奔着“登录后台”去因为高权限后台的入口往往防护更严。我的思路通常是先在外围业务系统找逻辑缺陷获取一个低权限的有效会话再在当前会话的基础上寻找权限提升的机会。比如通过越权接口读取管理员列表、通过信息泄露拿到管理员的身份标识再通过密码重置类漏洞实现身份接管最终获得后台权限。如果你能拿到后台权限接下来能做的事情就非常多了后台的功能点可以直接操作核心业务数据、批量导出用户信息、修改业务配置甚至通过后台的文件上传功能进一步getshell。但需要提醒的是在SRC实战中测试到后台拿权这一步就已经可以收手提交了不建议继续尝试更深的破坏性操作。3.3 系统设计层面的反思为什么逻辑漏洞难防站在防御视角逻辑漏洞为什么难防本质上是因为传统的安全防护手段WAF、RASP、代码扫描主要精力都放在注入、XSS、文件上传这类“通用漏洞”上而逻辑漏洞是跟业务代码强相关的每一套业务系统的逻辑都不一样没法用统一规则覆盖。这就导致了一个局面攻击者只要花时间理解业务逻辑就能找到防御体系的盲区。我在日常帮企业做代码审计时也经常发现开发人员对于越权、流程绕过这类问题的安全意识明显弱于对SQL注入、XSS的意识。有些开发甚至完全不知道RequestMapping接口默认就是允许任意用户调用的只要方法上没有加权限注解谁都能访问。所以从防守方的角度我给出的建议是接口权限默认拒绝、业务操作前统一鉴权、敏感操作的每一步都做会话校验这三条能做到逻辑漏洞的风险就能下降一半以上。4. 实战心法从信息收集到报告提交的经验总结4.1 测试过程中的几个关键习惯做SRC时间长了你会发现真正的高手和新人之间差的不是工具用得多溜而是习惯。我这里分享几个我在实战中慢慢养成、也确实帮我少走了很多弯路的习惯第一全程记录每一个请求和响应。我平时测试时会开两个浏览器一个专门用来操作业务功能一个用来查看修改后的请求。涉及修改参数的请求一定会把原始请求和修改后的请求、原始响应和修改后的响应都截全这样写报告时才有足够证据。第二思路卡住了就回到信息收集的清单上重新看。这是我最常用也最有效的方法。测试到一半发现没有进展不要硬想回去打开信息收集阶段做的功能清单看看哪些模块还没测哪些接口还没认真看你会发现漏洞往往就藏在你忽略的那个角落。第三学会控制测试请求的速率和频率。SRC平台的业务系统都是真实生产环境每秒发几百个请求的这种做法轻则触发风控封你IP重则影响业务正常使用这是很招人烦的。我平时爆破或者测试时会强制加延时请求间隔至少1到2秒既不会影响业务也能模拟真实用户的行为降低被发现的概率。4.2 报告怎么写才能拿高分报告是漏洞挖掘的最后一步但也常常是被低估的一步。同样一个漏洞有的人提交就通过有的人提交就被忽略差别往往在报告质量上。我写SRC报告的核心原则是易复现、证据链完整、危害清晰。具体来说有三点复现步骤写仔细每一步都要写清楚从哪个页面进入、点了什么按钮、修改了哪个请求里的哪个参数必须让审核人员照着操作就能复现。千万不要写“在XX接口修改ID即可越权”这种偷懒的描述。截图贴关键证据越权类漏洞要贴出两个账号的数据对比截图逻辑绕过类要贴出正常流程和绕过流程的请求顺序图注入类要贴出包含执行结果的响应包。图片是审核人员判断漏洞真实性的第一手材料。风险评级要合理新人容易把漏洞定级定高反而导致审核反复沟通甚至直接忽略。我自己的评级心得是只要涉及核心业务数据或资金相关的越权大胆定高危但如果只是边缘业务的信息泄露定个中危甚至低危反而更容易快速通过拿到分再说。4.3 我踩过的坑和总结出来的避坑清单最后分享几个我实实在在踩过的坑这些经验虽然不是“技术”但走弯路往往比技术瓶颈更浪费时间不要一上来就开扫描器全量扫日志里全是扫描器指纹还没开始测试就已经惊动了防守方。不要在SRC平台上测试上传WebShell这是严重违规行为平台可以直接取消你后续所有漏洞提交资格。测试上传点只需要证明“可上传任意文件类型”这个事实然后立刻删除即可。注意测试账号的隔离自己注册两个小号互相测不要影响正常业务用户。密码重置类漏洞测试如果涉及修改他人密码一定测通之后立刻改回来并做好记录这是SRC的基本礼仪也是底线。邮件通知类功能别瞎发企业内部员工的邮箱收到钓鱼邮件式的测试内容大概率会被投诉影响的是整个白帽群体的声誉。4.4 从一次渗透测试看攻击者的决策链路最后想聊一个稍微抽象一点的话题攻击者在实战中的决策链路到底是什么样的这可能是这篇文章里最核心的“思路”部分。我自己的决策逻辑可以简化为一条线信息收集发现入口 - 逐功能点排查逻辑 - 找到单点缺陷 - 评估能否延伸 - 组合利用提升权限。这其中的关键转折点是第二步到第三步之间的判断什么才算是一个值得深入测试的功能点。我通常会看两个指标一是这个功能点是否涉及敏感操作金钱、用户数据、权限变更二是这个功能点的请求参数是否复杂参数越多意味着服务端校验逻辑越可能有疏漏。如果一个接口又涉及敏感操作、参数又多那它几乎就是我优先测试的首选目标。例如这次案例里我之所以能快速锁定那个后台接口就是因为信息收集阶段发现这个后台系统对外开放了一个“订单批量导出”接口它既有权限敏感点又需要传递多个JSON参数。复杂的参数代表了复杂的逻辑复杂的逻辑背后往往藏着可以被绕过的判断分支。这个接口最终也确实成了整条攻击链的最后一环。这套决策思路不光是渗透测试适用做代码审计、做安全巡检、做架构评审的时候同样适用。安全思维的本质不是背下多少条漏洞规则而是能够站在业务逻辑的缝隙里思考问题。这个能力只有靠一次次实战、一次次复盘才能慢慢建立起来。做SRC这么久我越来越觉得逻辑漏洞挖掘像是一场拼图游戏信息收集是拼图的边框功能点分析是拼图的碎片分类而漏洞组合利用是把碎片一点点拼成完整的画面。拿下后台权限的那一刻成就感固然很强但更让我受益的是整个过程里一次次思维博弈带来的认知提升。这篇文章里的思路、习惯和踩坑清单都是我一步步试出来的希望能给你带来一些启发。当然所有的测试手法一定要在授权范围内使用守护好安全从业者的底线这条路才能走得更远。