1. 项目概述一次典型的并发逻辑漏洞挖掘实录在安全测试领域除了那些广为人知的SQL注入、XSS跨站脚本还有一类漏洞因其隐蔽性和对业务逻辑的深度依赖常常被初级渗透测试人员忽略那就是并发逻辑漏洞。这类漏洞不直接攻击代码缺陷而是利用系统在处理并发请求时对共享资源如余额、库存、积分的竞争条件判断失误从而实现“无中生有”或“超额获取”。我最近在一次针对某大型互联网平台以下简称TX平台的SRC安全应急响应中心漏洞挖掘中就成功发现并利用了一个并发漏洞实现了“刷钻”即非法获取虚拟货币或增值服务的效果。漏洞已提交并获官方确认修复整个过程堪称一次教科书式的逻辑漏洞实战。简单来说这个漏洞的核心在于平台在用户进行“钻石”兑换或消费的关键业务流程中未能对并发请求进行有效的原子性操作和状态一致性校验。攻击者通过同时发送多个相同的业务请求使得后端系统在极短的时间窗口内基于同一个“初始状态”进行了多次业务处理最终导致用户可以消耗一次成本获得多次收益。这听起来有点像“双花”问题在Web业务中的体现。对于刚入行SRC挖洞的朋友理解并掌握这类漏洞的挖掘思路远比盲目扫描常见Web漏洞更有价值因为它考验的是你对业务的理解深度和攻击面的想象力。2. 漏洞原理与并发攻击模型深度解析要理解这个漏洞我们得先抛开代码从业务逻辑的层面看问题。我们假设一个简化场景用户账户里有10颗“钻石”一个“大礼包”售价也是10颗钻石。正常的购买流程应该是前端发起购买请求携带商品ID。后端接收到请求查询用户当前钻石余额假设为10。后端进行条件判断if (余额 商品价格) { 执行扣款和发货 }。扣款操作UPDATE user SET diamond diamond - 10 WHERE uidxxx。发货操作向用户账户添加礼包。问题就出在第2步到第4步之间。在传统的、没有做并发控制的实现中这两个操作查询和更新并非一个不可分割的“原子操作”。如果两个完全相同的购买请求在极短的时间间隔内比如几毫秒几乎同时到达服务器可能会发生以下情况请求A查询余额得到10。请求B几乎同时查询余额得到的也是10因为请求A尚未完成扣款更新。请求A判断通过执行扣款余额变为0并发货。请求B判断也通过因为它查询时余额还是10执行扣款余额变为 -10并再次发货。最终结果用户只拥有10颗钻石却成功买到了两个价值10钻石的礼包账户钻石变为-10如果数据库字段无符号约束则可能导致报错或购买失败但逻辑漏洞已触发。这就是最经典的“竞争条件”漏洞。在实际的TX平台案例中情况更为复杂和隐蔽。它并非简单的购买而是涉及一个“抽奖”或“兑换”环节其中消耗的“钻石”与获得的“奖励”之间存在一种非即时、可并发的映射关系。后端系统在处理请求时可能使用了先预扣款锁定资源、后根据业务结果进行实际结算的模式但在“预扣”到“结算”这个状态转换的间隙没有对用户本次会话或该笔交易进行有效的“锁”保护导致多个并发请求都成功通过了预扣款校验进入了奖励发放流程。注意这里千万不能把“并发”简单理解为用工具狂发请求。真正的并发攻击是让多个请求在同一时刻“穿透”系统的校验点。这通常需要借助编程手段如多线程、异步IO来构造几乎同时发出的请求包而不是简单地用Burp Suite的Intruder模块进行快速重放那通常会有微小的时间差容易被简单的队列机制化解。2.1 为什么现代系统仍存在这类漏洞你可能会有疑问数据库事务不是可以解决吗是的但事务主要保证数据库操作的ACID特性它并不能自动解决应用层的逻辑判断问题。如果“查询余额”和“更新余额”不在同一个事务内或者事务隔离级别设置不当如读未提交、不可重复读并发问题依然会出现。更常见的原因是开发意识不足很多开发人员认为前端做了限制如按钮置灰、网络请求有先后就不会有并发问题忽略了恶意攻击者可以直接构造并发请求包。架构复杂在微服务或分布式架构下业务逻辑可能跨多个服务扣款服务和发货服务可能是独立的它们之间的状态同步存在延迟给并发攻击留下了时间窗口。性能考量严格的锁如分布式锁会极大降低系统吞吐量。为了性能一些非核心或被认为风险不高的业务环节可能会省略并发控制。业务流程的非常规路径漏洞往往出现在一些非主流的、复杂的业务交互链路上这些路径的测试覆盖可能不足。3. 实战挖掘过程从信息收集到漏洞验证下面我详细复盘一下这次TX平台刷钻漏洞的挖掘过程。请注意所有涉及的具体域名、接口、参数均已做脱敏处理重点在于分享方法论和思路。3.1 目标分析与业务梳理我的切入点并不是盲目的扫描而是选择了平台的“会员权益中心”或“游戏道具兑换中心”这类高价值业务板块。因为这些地方直接涉及虚拟资产钻石、点券、会员时长的流转是逻辑漏洞的高发区。我首先以正常用户身份完整地体验了一遍“钻石兑换高级礼包”的流程浏览可兑换商品列表。选择一款价值188钻石的礼包点击“立即兑换”。弹出确认框显示“将扣除188钻石”点击确认。页面转圈随后提示“兑换成功”钻石余额减少礼包到账。我用Burp Suite抓取了整个过程的HTTP/HTTPS请求。关键请求通常是一个POST请求可能指向类似/api/v1/exchange/confirm的接口参数中会包含product_id、nonce随机数防重放、timestamp和客户端生成的签名。3.2 寻找并发可能性分析请求后我重点关注以下几点幂等性设计请求参数中是否有唯一令牌如order_token、request_id服务器是否依赖此令牌来防止重复提交在这个案例中我发现了一个client_trace_id字段但初步测试发现重复提交相同client_trace_id的请求会被提示“重复请求”。这说明有基础防重放。状态校验时机漏洞的关键在于“扣款”和“发货”是否在同一原子操作中或者中间是否有可被利用的间隙。我通过拦截请求尝试在服务器返回“兑换成功”但页面还未跳转的瞬间快速重放请求发现有时会返回“钻石不足”有时却成功了。这种不确定性提示了并发竞争的可能。业务链路的拆分通过仔细分析我发现这个兑换流程实际上调用了两个后端接口/api/precheck预检查扣减库存/预扣钻石和/api/fulfill实际履约发放礼包。两个接口调用间隔约200-300毫秒。这就是一个非常典型的并发攻击面。3.3 构造并发攻击脚本单纯的浏览器操作或Burp重放无法实现真正的毫秒级并发。这里就需要编写攻击脚本。我选择了Python结合asyncio和aiohttp库因为它们是构建高并发HTTP客户端的利器。核心攻击思路先正常发起一次兑换请求获取到合法的请求参数特别是签名和必要的令牌。编写异步函数在几乎完全相同的时间点同时向/api/fulfill接口即实际发货的接口发起N个完全相同的POST请求。关键点在于要让这些请求绕过或复用/api/precheck产生的“一次有效”的令牌。我通过分析发现/api/fulfill接口依赖的令牌在预检查成功后生成并有一段短暂的有效期且校验机制在并发下存在缺陷。以下是简化版的概念性代码展示了如何组织并发请求import asyncio import aiohttp async def send_fulfill_request(session, url, headers, data): 发送单个履约请求 try: async with session.post(url, headersheaders, jsondata) as resp: text await resp.text() print(fStatus: {resp.status}, Response: {text}) return text except Exception as e: print(fRequest failed: {e}) return None async def concurrent_attack(): url https://target.com/api/fulfill # 目标履约接口 # 以下headers和data需要通过一次正常的业务流程抓取获得并确保其有效性 headers { Authorization: Bearer xxx, Content-Type: application/json, User-Agent: Mozilla/5.0... } data { exchange_token: xxxxxx, # 从预检查接口获得的关键令牌 product_id: 888, timestamp: 1678888888, sign: xxxxxx } # 创建aiohttp会话 async with aiohttp.ClientSession() as session: # 创建10个完全相同的并发任务 tasks [send_fulfill_request(session, url, headers, data) for _ in range(10)] # 使用gather真正并发地执行所有任务 results await asyncio.gather(*tasks, return_exceptionsTrue) # 分析结果 success_count sum(1 for r in results if r and success in r) print(fTotal requests: 10, Successfully fulfilled: {success_count}) # 运行攻击 asyncio.run(concurrent_attack())实操心得令牌与签名很多时候请求参数带有服务器验证的签名。直接并发重放可能因为签名过期或重复而失败。你需要分析签名算法有时是简单的MD5(参数secret)确保并发请求使用的参数和签名在有效期内完全一致。在这个案例中exchange_token和对应的签名是基于一个时间窗口生成的只要并发请求在这个窗口内发出就能通过校验。连接池与性能aiohttp.ClientSession默认会使用连接池但面对目标服务器的压力可能需要调整TCP连接限制和超时时间避免因本地端口耗尽或服务器拒绝连接导致攻击失败。道德与法律边界务必、务必、务必在获得授权的测试环境或SRC允许的范围内进行。我的所有测试均在个人测试账户进行且兑换的“钻石”为测试货币发现的漏洞立即上报未进行任何非法的资产转移或牟利。3.4 漏洞验证与结果运行脚本后我观察到控制台输出了10个请求的响应。预期中只有第一个应该成功其余应返回“令牌已使用”或“交易已完成”之类的错误。但实际结果是10个请求中有3个返回了“兑换成功”。同时查询我的账户余额和礼包数量确认我只被扣除了188钻石一次兑换的成本但收到了3份礼包。漏洞验证成功为了确认这不是偶然我多次重复测试使用新的测试账户和兑换令牌成功率稳定在20%-40%之间。这充分证明了在高并发场景下后端系统的履约环节存在严重的状态判断竞态条件。4. 漏洞根因分析与修复建议在提交漏洞报告时仅仅说“这里有个并发漏洞”是不够的需要向开发团队清晰地阐明根因和提供修复方案这能体现你的专业度也更容易被采纳。根因分析非原子化业务操作/api/precheck和/api/fulfill构成了一个分布式事务但两者之间缺乏强一致性保证。precheck生成的exchange_token虽然标记了一笔交易但在fulfill接口处理时检查“该token是否已使用”和“标记该token为已使用”这两个操作不是原子的。在并发请求下多个请求可能同时通过“是否已使用”的检查然后都去执行发货逻辑。数据库更新条件缺失fulfill接口在更新订单状态或用户资产时可能使用了简单的UPDATE ... SET statusdone WHERE tokenxxx而没有加上AND statuspending这样的条件判断。在并发下多个更新操作都会执行成功。缺乏分布式锁在整个兑换事务的关键路径上没有对用户ID或订单token加分布式锁如基于Redis的锁导致临界区资源被多个线程同时访问。修复建议幂等性设计强化为exchange_token在数据库中建立唯一索引插入履约记录时直接使用INSERT ... ON DUPLICATE KEY UPDATE或类似机制利用数据库的唯一性约束来保证同一令牌只能被成功使用一次。这是最有效、最简单的方法。原子化状态校验将“检查并标记token使用状态”的操作放在一个数据库事务中并使用SELECT ... FOR UPDATE悲观锁或乐观锁版本号来确保一致性。-- 悲观锁示例 BEGIN TRANSACTION; SELECT * FROM exchange_tokens WHERE token xxx AND status pending FOR UPDATE; -- 如果查到记录则更新状态并发货 UPDATE exchange_tokens SET status used WHERE token xxx; -- 执行发货逻辑... COMMIT;引入分布式锁在fulfill接口入口针对user_id product_id的组合或exchange_token本身获取一个短暂的分布式锁如Redisson的RLock持有锁期间完成所有操作从机制上杜绝并发执行。合并或重构接口考虑将预检查和履约合并为一个原子性更强的接口减少中间状态暴露的时间窗口。前端辅助虽然不能依赖前端做安全但可以增加更严格的交互限制如点击后按钮立即禁用并显示不可取消的加载状态增加攻击者构造并发请求的难度。5. 并发漏洞挖掘的通用方法论与工具链这次实战并非个例。掌握一套方法论你可以在很多业务系统中发现类似问题。挖掘模式目标定位聚焦涉及资产变动支付、兑换、抽奖、领券、抢购的业务点。流程拆解用Burp Suite或浏览器开发者工具仔细记录业务关键链路上的每一个请求画出时序图。重点寻找“检查-操作”分离的点。参数分析识别每个请求中的防重放参数token, nonce, timestamp, signature。思考这些参数是如何生成、校验和失效的。并发测试对于可疑的接口尤其是“确认”、“提交”、“完成”等最终操作接口编写并发测试脚本。不要只用Burp Intruder的“Battering ram”或“Pitchfork”模式它们本质上是快速串行。结果验证多维度验证结果。不仅看接口返回还要查数据库如果允许、查用户前端状态、查流水记录。确保漏洞真实存在且可稳定复现。工具链推荐抓包与分析Burp Suite Professional (Repeater, Intruder, Sequencer)、Charles、Fiddler。并发脚本编写Python (aiohttp, requests threading) Go (goroutine) 甚至可以用JMeter或Gatling进行高并发压测模拟但需精细配置思考时间和参数化。辅助分析浏览器的开发者工具Network面板、PostmanCollection Runner可进行有限并发。注意事项与避坑指南遵守规则始终在授权范围内测试。未经授权对生产环境进行并发测试可能被视为DoS攻击导致法律风险和个人账号封禁。测试账户务必使用自己的测试账户并确保有足够的“测试资金”或不会对他人造成影响。控制频率与力度并发数不要一下子开得太大如成千上万先从5-10个开始避免触发系统的风控警报或直接打挂服务。关注响应仔细分析每一个并发请求的响应。有时服务器会返回“排队中”、“处理中”这可能是系统有队列处理需要调整攻击策略如同时发起多个“创建订单”的请求而不是“支付订单”。逻辑链延伸并发漏洞可能与其他漏洞结合。例如如果并发请求能绕过额度限制再结合一个无限提现的接口危害就会指数级放大。6. 写给SRC新手的进阶思考对于想投身SRC漏洞挖掘的新手我想分享几点比技术更重要的思考从用户视角到攻击者视角不要只顺着产品的正常流程走。多问“如果……会怎样”。“如果我点击两次提交按钮会怎样”“如果我在收到成功响应前关闭网络再重连会怎样”“如果两个浏览器标签页同时操作会怎样”这种思维切换是发现逻辑漏洞的关键。理解业务重于堆砌工具自动化扫描器扫不出逻辑漏洞。你需要真正理解这个业务是如何赚钱、如何防止作弊、资源是如何流转的。阅读产品的用户协议、帮助文档有时能发现开发者对业务规则的描述这些描述和实际实现可能存在偏差就是漏洞点。漏洞的“价值”判断在SRC中漏洞的评级不仅取决于技术原理更取决于实际影响。一个能导致任意用户资金损失的并发漏洞肯定是高危而一个只能让自己重复领取低价值优惠券的漏洞可能只是中危或低危。在报告时要清晰地阐述漏洞的可利用场景和潜在危害最好能给出粗略的损失估算例如“利用此漏洞攻击者可在1分钟内无限刷取价值XX元的虚拟道具”。报告的艺术一份优秀的漏洞报告需要清晰的标题、详尽的复现步骤按123列出、必要的截图和视频证明、对漏洞原理的简明分析、以及建设性的修复建议。避免使用挑衅或夸张的语言用事实和技术说话。并发逻辑漏洞的挖掘是一场与开发者思维模式的博弈。它不需要你掌握多么高深的0day利用技术但需要你具备缜密的逻辑思维、对业务细节的执着探究以及将抽象攻击模型转化为具体测试用例的能力。这次TX刷钻漏洞的挖掘再次印证了在业务逻辑的深水区依然藏着大量有价值的安全问题。希望这篇详细的复盘能为你打开一扇新的挖洞之门。记住最坚固的堡垒往往从内部被攻破而业务逻辑的缝隙就是那个“内部”。