【Web安全】小白也能懂的并发漏洞：原理、场景与防御

文章目录前言一、漏洞本质二、攻击原理正常的并发处理流程漏洞触发流程三、漏洞场景1.提交问卷一次操作变多次福利2.刷票一个行为被反复计数四、并发突破绕过业务限制1.绕过“数量限制”免费享受付费权益2.短信轰炸验证码“管够”五、检测方式怎么发现并发漏洞1.黑盒测试模拟“同时操作”2.白盒审计看代码有没有“防护”六、防御方案让系统“抗住”并发1.加“锁”让操作“排队”2.限制请求频率不让“同时”发生3.事后校验操作完再“对账”4.日志监控盯着“异常操作”七、总结往期文章【Web安全】一次性搞懂 ReDOS 漏洞原理/检测/防御【Web安全】一次性搞懂 XSS 漏洞原理/检测/防御【Web安全】一次性搞懂 CSRF 漏洞原理/检测/防御【Web安全】一次性搞懂 SSRF 漏洞原理/检测/防御【Web安全】一次性搞懂越权漏洞原理/检测/防御【Web安全】逻辑漏洞之支付漏洞原理、场景与防御前言在Web应用中“并发”是个很常见的词——简单说就是“多个操作同时发生”。比如你和朋友同时给同一篇文章点赞或者春运时大家抢同一趟火车票这些都是并发场景。但并发本身不是漏洞它更像一把“双刃剑”用得好能提高系统效率比如同时处理多个用户请求用不好就可能被攻击者利用变成“并发漏洞”。本文就用大白话讲讲并发漏洞是什么、会造成什么危害以及怎么防范。一、漏洞本质先明确一个核心点并发不是漏洞而是一种“攻击手法”。就像“刀”本身不是武器用刀伤人的行为才是问题——并发只是“多个操作同时进行”的状态而漏洞的本质是系统没处理好“同时发生的多个操作”导致业务规则被绕过出现异常结果。举个生活例子超市规定“每人限购1瓶特价牛奶”正常情况下你买完1瓶系统会记下来但如果你和朋友同时拿着同一瓶牛奶去两个收银台结账而超市系统没及时同步“已购买”的记录就可能让你“买了2瓶”——这就是并发导致的规则绕过也就是并发漏洞的本质。二、攻击原理正常的并发处理流程健康的系统处理并发时会有“排队”或“保护机制”多个请求同时到达服务器系统按顺序处理或给数据加“锁”比如先处理A的请求B的请求要等A处理完再开始确保每个操作的结果正确比如A买完特价牛奶B再买时系统会提示“已售罄”。漏洞触发流程当系统没做好并发控制时漏洞就会出现攻击者同时发送多个相同的请求比如同时提交10次问卷系统没来得及记录“已经处理过一次”把这10次请求当成“第一次”分别处理最终出现异常结果比如抽了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 小时监控摄像头”。审计内容包含“六要素”操作时间操作人 ID绑定员工 / 用户唯一标识操作行为如 “提交订单”“发送验证码”操作对象明确操作所针对的具体目标如 “某份合同编号”“某台设备的 IP 地址”“某条用户数据的 ID” 等操作结果记录操作的执行状态是成功、失败还是异常终止操作终端如终端 IP 地址、设备型号、操作系统版本七、总结并发漏洞的本质不是“并发”本身有问题而是系统没处理好“同时发生的多个操作”导致业务规则被绕过。对小白来说记住两点就行并发漏洞常表现为“一次操作变多次”“绕过数量限制”防御的核心是“让系统认出重复操作”——加锁、限频率、事后查账都能有效防范。本文是「Web安全基础」系列的第 7 篇点击专栏导航查看全部系列内容。