往期文章

【Web安全】一次性搞懂 ReDOS 漏洞原理/检测/防御

【Web安全】一次性搞懂 XSS 漏洞原理/检测/防御

【Web安全】一次性搞懂 CSRF 漏洞原理/检测/防御

【Web安全】一次性搞懂 SSRF 漏洞原理/检测/防御

【Web安全】一次性搞懂越权漏洞原理/检测/防御

【Web安全】逻辑漏洞之支付漏洞：原理、场景与防御

前言

在Web应用中，“并发”是个很常见的词——简单说就是“多个操作同时发生”。比如你和朋友同时给同一篇文章点赞，或者春运时大家抢同一趟火车票，这些都是并发场景。

但并发本身不是漏洞，它更像一把“双刃剑”：用得好能提高系统效率（比如同时处理多个用户请求）；用不好，就可能被攻击者利用，变成“并发漏洞”。本文就用大白话讲讲并发漏洞是什么、会造成什么危害，以及怎么防范。

一、漏洞本质

先明确一个核心点：并发不是漏洞，而是一种“攻击手法”。

就像“刀”本身不是武器，用刀伤人的行为才是问题——并发只是“多个操作同时进行”的状态，而漏洞的本质是：系统没处理好“同时发生的多个操作”，导致业务规则被绕过，出现异常结果。

举个生活例子：超市规定“每人限购1瓶特价牛奶”，正常情况下你买完1瓶，系统会记下来；但如果你和朋友同时拿着同一瓶牛奶去两个收银台结账，而超市系统没及时同步“已购买”的记录，就可能让你“买了2瓶”——这就是并发导致的规则绕过，也就是并发漏洞的本质。

二、攻击原理

正常的并发处理流程

健康的系统处理并发时，会有“排队”或“保护机制”：

1. 多个请求同时到达服务器；
2. 系统按顺序处理，或给数据加“锁”（比如先处理A的请求，B的请求要等A处理完再开始）；
3. 确保每个操作的结果正确（比如A买完特价牛奶，B再买时系统会提示“已售罄”）。

漏洞触发流程

当系统没做好并发控制时，漏洞就会出现：

1. 攻击者同时发送多个相同的请求（比如同时提交10次问卷）；
2. 系统没来得及记录“已经处理过一次”，把这10次请求当成“第一次”分别处理；
3. 最终出现异常结果（比如抽了10次奖，而正常只能抽1次）。

简单说，攻击链路就是：
攻击者→同时发送多个相同请求→系统没拦住→绕过规则重复操作

三、漏洞场景

并发漏洞的危害，得结合具体业务来看。下面是几个小白也能懂的场景：

1.提交问卷：一次操作变多次福利

业务背景：某平台规定“提交一次问卷，可抽一次奖或领一次红包”，目的是鼓励用户填问卷，但限制每人只能参与1次。

漏洞场景：
攻击者用工具同时发送10次“提交问卷”的请求。由于系统没处理好并发——第1次请求还没记录“已提交”，第2到10次请求就已经被处理了。最终，攻击者抽了10次奖，领了10个红包，而正常用户只能领1次。

大白话总结：系统“反应慢”，没发现这些请求是“同一个人同时发的”，错把多次操作当成了一次。

2.刷票：一个行为被反复计数

业务背景：某投票活动规定“每人对同一选手只能投1票”，或“每条内容只能点赞1次”，防止刷票作弊。

漏洞场景：
攻击者同时发送100次“投票”或“点赞”请求。系统因为并发处理不及时，每次请求都认为是“第一次操作”，最终给选手加了100票，或者内容多了100个赞。

为什么会这样？
就像你同时给朋友发10条“帮我点赞”的消息，朋友手快，没注意是重复的，每条都点了一次——系统此刻就像这个“手快的朋友”，没检查重复。

四、并发突破：绕过业务限制

除了重复操作，并发还能绕过一些“数量限制”，常见于需要付费解锁的场景：

1.绕过“数量限制”：免费享受付费权益

业务背景：某团队协作工具规定“免费版最多添加5名团队成员”，想加第6人需要开通付费的“企业版”。

漏洞场景：
攻击者同时发送2次“添加成员”的请求（此时团队已有5人）。正常情况下，系统应该提示“已达上限”，但由于并发处理问题：

• 第1次请求检查时，发现“当前5人，可加1人”，开始添加；
• 第2次请求检查时，系统还没更新“已添加到6人”，也认为“可加1人”，继续添加；
  最终团队成员变成了7人，攻击者没花钱就绕过了限制。

2.短信轰炸：验证码“管够”

业务背景：登录或注册时，系统会发送短信验证码，为了防止骚扰，通常限制“1分钟最多发3条”。

漏洞场景：
攻击者同时发送10条“获取验证码”的请求。系统没来得及记录“已发送次数”，就把10条请求都当成“第一次发送”，最终1分钟内发了10条验证码——不仅骚扰用户，还可能消耗平台的短信费用。

五、检测方式：怎么发现并发漏洞？

哪怕是小白，也能通过简单方法检测：

1.黑盒测试：模拟“同时操作”

• 工具：用简单的脚本（比如Python的多线程脚本），或者通过 BurpSuite 的 Intruder 模块。
• 操作：对目标功能（如提交问卷、投票）同时发送5-10次相同的请求。
• 判断：如果结果超过正常限制（比如投了10票、领了5个红包），说明可能有并发漏洞。

2.白盒审计：看代码有没有“防护”

如果懂一点代码，可以检查：

• 关键操作（如添加成员、发验证码）是否有“锁”机制；

• 是否限制了单位时间内的请求次数（比如“1分钟最多5次”）。

  如果都没有，大概率存在并发漏洞。

六、防御方案：让系统“抗住”并发

防范并发漏洞的核心是：让系统“认出”同时发生的重复操作，按规则处理。

1.加“锁”：让操作“排队”

就像公共厕所的门锁——有人用的时候锁上，其他人得等。系统里的“锁”也是这个道理：

• 处理请求前，先给数据加锁（比如“团队成员数”“问卷提交状态”）；

• 一个请求处理完，解锁后再处理下一个；

  例子：添加团队成员时，先锁上“当前人数”，处理完再解锁，后面的请求就会看到“已达上限”。

2.限制请求频率：不让“同时”发生

• 规定“单位时间内最多处理N次请求”，比如“1分钟内最多3次验证码请求”“5秒内最多1次问卷提交”。
• 实现方式很简单：记录每个用户的操作时间，超过次数就拒绝。

3.事后校验：操作完再“对账”

比如投票后，系统定期检查“同一用户的投票次数”，如果超过1次就自动减去多余的票数——相当于“事后算账”，弥补并发时的漏洞。

4.日志监控：盯着“异常操作”

在华为的业务体系中，审计日志是系统的 “标配安全组件”，其设计理念就像给核心业务装上 “24 小时监控摄像头”。

审计内容包含“六要素”：

1. 操作时间
2. 操作人 ID（绑定员工 / 用户唯一标识）
3. 操作行为（如 “提交订单”“发送验证码”）
4. 操作对象（明确操作所针对的具体目标，如 “某份合同编号”“某台设备的 IP 地址”“某条用户数据的 ID” 等）
5. 操作结果（记录操作的执行状态，是成功、失败还是异常终止）
6. 操作终端（如终端 IP 地址、设备型号、操作系统版本）

七、总结

并发漏洞的本质，不是“并发”本身有问题，而是系统没处理好“同时发生的多个操作”，导致业务规则被绕过。

对小白来说，记住两点就行：

1. 并发漏洞常表现为“一次操作变多次”“绕过数量限制”；
2. 防御的核心是“让系统认出重复操作”——加锁、限频率、事后查账，都能有效防范。

本文是「Web安全基础」系列的第 7 篇，点击专栏导航查看全部系列内容。