文章总结： 本文详细解析重放攻击与并发攻击的业务场景与区别，指出服务端校验不足会导致刷票刷赞等风险，并提出幂等性设计、事务锁、请求校验等防护措施，强调安全应依赖服务端而非前端。 综合评分： 84 文章分类： WEB安全,漏洞分析,安全开发,安全意识,实战经验

一文搞懂重放攻击与并发攻击，实现刷票，刷赞，秒券

原创

老王 老王

网络安全白帽营

2026年5月19日 10:19 湖南

在小说阅读器读本章

去阅读

本文讲两类常见的业务攻击：重放攻击和并发攻击。它们经常出现在投票、领券、点赞、抽奖、秒杀、报名等功能里。表面上看，这些只是普通的用户操作；一旦后端校验不严，攻击者就可能绕过次数限制，完成刷票、重复领券、刷赞，甚至影响库存、积分和账户权益。

常见风险场景

很多网站和 App 都会设计“每人只能操作一次”或“每个账号只能领取一次”的规则。例如投票系统通常限制每个用户只能投一票，优惠券系统通常限制每个用户只能领一张，点赞系统也会限制同一账号不能重复点赞。

问题在于，用户界面上的限制不等于后端真正安全。如果系统只在前端按钮、页面状态或简单参数上做限制，而没有在服务端完成严格校验，那么攻击者就可能利用请求本身重复触发业务逻辑。投票数、优惠券数量、点赞数这些看似简单的数字，背后都依赖服务端对用户身份、操作次数、请求唯一性和并发状态的判断。校验不到位，就会出现刷票、重复领券、刷赞这类问题。

以投票功能为例，正常用户点击一次按钮，系统应该只记录一次投票。如果后端没有判断这次投票是否已经发生过，或者判断逻辑不够严谨，同一份请求就可能被重复提交，最终导致刷票。领券和点赞也是同样的道理。用户看起来只点了一次，服务器却可能因为重复请求或并发请求处理不当，把一次操作记成多次，于是出现重复领券或刷赞。

理解这类问题时，可以先把重点放在两个概念上：重放攻击和并发攻击。它们的共同点是都围绕“请求被重复利用”展开，区别在于请求发送的节奏不同。

重放攻击

重放攻击指的是攻击者获取到某一次正常请求后，再把这份请求按原样或稍作修改后重新发送。系统如果没有识别请求是否已经被使用过，就可能把重复请求当成新的合法操作处理。

在业务场景中，重放攻击常见于投票、领取优惠券、点赞、签到、积分兑换等功能。用户的一次正常操作会产生一条请求，后端收到请求后更新业务数据。如果这条请求缺少一次性标识、时间校验、签名校验或状态校验，那么同一条请求被再次提交时，后端可能仍然照常执行。刷票、重复领券、刷赞，本质上都可能由这种请求重放造成。

可以把它理解为“同一张票据被反复使用”。第一次使用时系统允许通过，后面再次使用时，如果系统没有检查这张票据是否已经失效，就会继续放行。重放攻击的核心问题就在这里：服务端没有把“一次性操作”真正做成一次性。

这类问题的防护重点不是隐藏按钮，也不是只在前端禁用重复点击，而是让服务端能够识别重复请求。常见做法包括使用 nonce、时间戳、请求签名、幂等键、操作流水号、服务端状态锁，以及对关键业务字段做唯一性约束。

并发攻击

并发攻击和重放攻击相似，也会围绕同一类业务请求展开。不同的是，并发攻击强调“同时发送”。攻击者不是一条一条地重复提交，而是在极短时间内同时发起多条请求，试图赶在服务端状态更新之前，让多条请求都通过校验。

这种攻击常见于库存扣减、优惠券领取、抽奖次数、账户余额、积分兑换、报名名额等业务中。系统可能先检查“用户是否还有资格”，再执行“扣减或记录”。如果这两个步骤之间没有锁、事务或原子操作，多条并发请求就可能同时通过资格检查，最终造成超领、超卖、重复计数、刷票或重复领券。

举个简单例子：一个用户理论上只能领取一张优惠券。系统在处理请求时，先查用户是否已经领取，再写入领取记录。如果多个请求同时到达，它们可能都在写入之前查到“尚未领取”，于是全部进入后续流程。等这些请求陆续完成写入时，系统已经发出了多张券。

并发攻击的关键不是“请求被重复发送”本身，而是系统在高并发下没有保证业务状态的一致性。它考验的是服务端的事务设计、锁机制、唯一约束和幂等处理能力。

重放攻击与并发攻击的区别

重放攻击通常是一条请求被多次顺序发送，重点在于“旧请求还能不能再次生效”。并发攻击则是多条请求几乎同时到达，重点在于“系统能不能在并发场景下保持状态一致”。

二者造成的结果可能相似，比如刷票、重复领券、刷赞、库存超卖、积分重复扣减或重复发放。但排查和修复思路不同。重放攻击更关注请求唯一性、有效期和签名校验；并发攻击更关注事务、锁、原子操作、数据库唯一索引和接口幂等。

实际系统里，这两类问题也可能同时存在。一个接口既没有限制旧请求重复使用，也没有处理并发竞争，那么攻击面就会更大。

防护思路

要防住这类攻击，核心原则是把安全判断放在服务端，并让关键操作具备幂等性。前端限制只能改善用户体验，不能作为安全边界。

对于投票、点赞、领券这类功能，服务端应明确记录用户是否已经完成过该操作，并通过唯一约束或幂等键防止重复写入。对于库存、余额、积分这类敏感数据，应使用事务、行锁、乐观锁或原子扣减，避免多个请求同时修改同一份数据。对于需要防止请求复用的接口，应加入时间戳、nonce 和签名校验，并设置合理的过期策略。

日志和风控也很重要。短时间内来自同一账号、同一设备、同一 IP 或相似环境的大量重复请求，应被记录、限流或触发二次验证。业务安全不是单靠某一个参数解决的，而是由服务端校验、数据一致性、接口幂等和异常监控共同完成。

重放攻击和并发攻击看起来简单，但它们能暴露出系统最基础的业务校验问题。真正可靠的系统，不会相信“用户只会点一次”，也不会假设“请求会一个一个排队处理”。关键业务接口必须按攻击场景设计，才能在真实环境里扛住刷票、重复领券、刷赞、重复请求和高并发请求。

—————公众号福利———–

如果你也对黑客或者网络攻防感兴趣，想往技术这条路走，我可以把我们自己做的视频课程发给你，以前这些只在内部流传，专业程度可以轻松碾压国内绝大多数培训班和个人讲课，现在全网就这一个版本，网上根本找不到这么系统的内容。

长按图片识别二维码

视频从最基础的操作系统、网络原理、编程语言讲起，再到中级阶段的各种渗透技巧，后面还有CTF实战、区块链安全等进阶内容，整体超过200节课，资源也有200多个G，内容覆盖非常全面，别担心学不完，不管你是刚入门还是想提升技能，这套课都能帮上忙：

只要坚持学一个月左右，就有机会开始挖漏洞拿赏金，再继续学到三四个月，技术水平基本可以应对CTF对抗赛。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：网络安全白帽营 老王 老王《一文搞懂重放攻击与并发攻击，实现刷票，刷赞，秒券》