企业官网建设流程全解析

做SRC日常挖洞的人应该都有一个体会：能不能挖到漏洞，很多时候不取决于你的字典多全、fuzz多猛，而是取决于你能不能把目标站点的每一次请求看得清清楚楚。抓包环境就是这双眼睛，而并发漏洞呢，又是SRC里那种“看着不难、一挖一个准”的逻辑型漏洞。这篇文章把我自己搭抓包环境和测并发漏洞的完整过程捋一遍，包含工具选型、HTTPS解密、手机端抓包、并发请求的发送方式、结果判定标准，以及一堆踩坑之后的经验总结，希望能给准备入坑SRC或者已经在挖但环境还不太顺手的同学一点参考。

1. 先把目标想清楚：SRC挖洞为什么需要一套顺手的抓包环境

1.1 SRC日常工作的核心链路：从流量到逻辑

SRC（Security Response Center，安全应急响应中心）漏洞挖掘的本质，是去发现业务系统里那些“设计上没想周全”的环节。大部分高危漏洞并不需要多高深的内存破坏知识，而是藏在业务逻辑里，比如订单金额能不能改、验证码能不能绕过、并发请求会不会导致数据不一致。但问题是，逻辑漏洞藏得再浅，你也得先看到请求是怎么发的、参数是怎么传的、返回是怎么判断的。没有抓包环境，等于闭着眼睛找漏洞，纯靠瞎猜。

我自己的日常链路基本是这样的：打开目标站点，正常走一遍业务流程，同时让流量经过抓包工具，观察每个请求的参数结构和响应特征。遇到可疑接口，立刻从抓包工具里复制请求，丢到重发工具里改参数、改次数、改顺序，看服务端有没有异常表现。遇到需要并发测试的场景，就同时发出多份相同的请求，观察有没有重复操作、状态覆盖、额度翻倍之类的现象。整套链路里，抓包环境是最前面的入口，一旦断链，后面全是空谈。

1.2 抓包环境要解决的四件事

第一，完整的HTTP/HTTPS请求和响应记录。不只是URL和状态码，还要包括请求头、Cookie、请求体、响应体、响应头，缺一不可。很多逻辑漏洞的判断依据恰恰藏在某个不起眼的响应头或重定向里。

第二，请求的拦截和修改能力。在请求发出去之前卡住，把参数改了再放行，这是越权、支付篡改类漏洞测试的基本操作。第三，重复发送与批量测试能力。同一个请求改几个参数值，或者直接并发打出去，这靠浏览器手动点是不行的，必须依赖抓包工具或者脚本。第四，会话状态保持。SRC平台和大多数业务系统都需要登录态，抓包环境必须能维持住Cookie和Session，否则切来切去就掉了。

这四件事里，第一件大家都能做到，但第二和第三件往往才是区分“会抓包”和“会挖洞”的分水岭。很多新手拿到Burp或Fiddler只会看看请求，不会利用重发和并发功能，那抓包环境的价值就浪费了大半。

1.3 选工具前先想清楚你的工作流

工具不在多，顺手最重要。我的建议是主线抓包工具选一个，辅助工具配一两个，不要装一堆然后互相干扰。主工具承担HTTPS解密、拦截、重放、并发这些核心功能，辅助工具负责一些主工具不太方便的场景，比如纯TCP层面的调试、脚本化批量请求之类的。选型标准就三条：稳定、能解密HTTPS、支持脚本扩展。稳定性排在第一位，动不动闪退的工具再强大也白搭。至于具体选哪个，下面结合我的搭建过程详细说。

2. 抓包环境搭建的完整过程记录

2.1 工具选型：主抓包工具与辅助工具搭配

主抓包工具我用的是Burp Suite的社区版。之所以选它，主要是三个原因：一是HTTPS解密做得很顺，证书安装好之后几乎不需要额外配置；二是重放（Repeater）和并发测试模块操作直观，改参数、发多包都很方便；三是社区里关于它的教程和脚本最多，遇到问题随便一搜就有答案。对于SRC日常挖掘来说，社区版功能已经完全够用，不需要上专业版。

辅助工具方面，我备了两个。一个是Fiddler，用来解决一些边界场景，比如某台设备上Burp的证书确实装不进去，或者某些客户端不认系统证书，这时候Fiddler的“一键解密全部HTTPS”反而更省事。另一个是命令行HTTP客户端，用来快速发一些简单的请求测试，看接口通不通，配合管道命令做批量操作非常灵活。还有一个Python脚本环境，用来写并发脚本，这个后面讲并发漏洞时再展开。

不推荐的组合是把Burp、Fiddler、Charles同时开着。多个工具同时监听同一个端口会直接冲突，轻则抓不到包，重则把系统网络搞乱。另外不同工具的证书策略不同，同时开着容易出现证书互相覆盖的问题，排查起来非常痛苦。

2.2 浏览器侧配置：让流量自动进入抓包工具

Burp默认监听本机的8080端口，浏览器需要把HTTP和HTTPS协议的流量都指到这个入口，才能被它接住。

在Firefox里的配置比较直接，在网络设置里选择“手动配置”，HTTP和HTTPS都填本机地址加端口号，保存后重启浏览器就生效。Chrome默认不走系统代理，要么用命令行参数启动，设置代理服务器为本地端口；要么直接使用系统代理设置。这里有个细节：只配HTTP代理的话，很多浏览器对HTTPS流量也会走这个入口，但部分客户端完全不认，所以最好把HTTP和HTTPS两个框都填上。

配置完成后，打开任意HTTP网站，Burp里应该能看到请求记录。如果在浏览器里出现“无法连接”的提示，大概率是端口被占用或者代理配置没生效，把工具重启、端口换个新的，再刷新页面通常就能解决。

值得提醒的是，浏览器扩展也可能导致代理失效。比如一些网页翻译插件、脚本管理插件自带代理开关，会覆盖浏览器层级的代理设置，导致流量绕过抓包工具。排查抓不到包时，优先把所有扩展全部禁用再试，往往立竿见影。

2.3 证书安装与信任处理：HTTPS解密的那些坑

HTTP流量可以直接抓，但现代站点基本全是HTTPS，不解决证书问题等于废了一半。Burp启动时会生成一个CA证书，浏览器需要安装并信任这个证书，Burp才能解密HTTPS流量。

具体操作是：浏览器访问Burp的证书下载地址，下载CA证书，导入到系统的“受信任的根证书颁发机构”列表里。导入后重启浏览器，再访问HTTPS网站，Burp里就能看到明文请求了。

实际中我踩过几个坑，逐个说。第一个坑是只装到用户级证书没装到系统级，某些浏览器默认不信任用户级CA，导致页面报错。解决方案是证书导入时选择“受信任的根证书颁发机构”，并且把它导入到系统账户的存储区。第二个坑是证书导入后浏览器没完全重启，缓存里还保留旧的证书信任状态，必须彻底退出浏览器重开。第三个坑是开了系统证书校验的工具或安全软件把Burp的证书拦截了，页面会出现证书错误页，需要在工具的白名单里加入Burp证书。

如果目标站点用了双向认证或证书锁定（Certificate Pinning），Burp默认解不开。这种情况下需要先判断站点是否真的做了锁定，还是仅仅普通HTTPS。很多SRC目标站点实际上只做了单向认证，Burp解不开的原因往往是浏览器没信任CA证书，或者代理配置没生效。真遇到证书锁定，优先检查是否有移动端App的流量可抓，App端往往比Web端更容易绕过锁定。

2.4 手机端抓包环境准备

Web端抓包搞定了，还不能收工。现在很多SRC平台的业务重心在App端，Web端反而功能精简，漏洞挖掘空间也少。手机端抓包的思路是：手机和电脑连接到同一个局域网，手机上的应用流量通过入口指向电脑上的抓包工具端口。

电脑端需要先确认监听地址不只是本机回环地址，而是要监听在局域网地址上，否则手机根本连不上。手机会弹出证书不受信任的提醒，需要把电脑上的CA证书导出后安装到手机上，并且在手机设置里开启对该证书的完全信任。iOS端的证书信任开关藏得比较深，装完证书后还要去设置里点一下“开启完全信任”，不点的话照样解不开HTTPS。

Android端相对灵活，但不同版本差异较大。较新的系统默认不信任用户安装的CA证书，只信任系统内置证书，这个问题常见于Android的高版本系统。实用方案是优先找系统版本较低的测试机，或者在系统设置里搜索“证书信任”相关选项。要是App本身做了证书锁定，还可以尝试抓取其他协议流量，或者用备用的测试设备解决。

手机端抓包实验下来最实用的建议是：准备一台专门用来测漏洞的旧手机，系统版本不用太高，装好CA证书，关掉自动更新，平时就放着备用。真到需要抓App包的时候，拿出来就能用，比自己主力机来回折腾稳定得多。主力机装着各种支付应用和个人账号，也不适合拿来做实验。

2.5 规则配置与日常工作流

环境搭好之后，还有一步收尾：规则配置。Burp默认会拦截所有经过它的流量，如果不加任何过滤，每次点一个页面都会弹出一堆拦截请求，反倒影响效率。我的配置习惯是：只拦截目标域名的请求，其他流量直接放行。

具体做法是设置一个目标范围，把要测的SRC站点的域名加进去，同时把一些第三方资源域名的请求自动放行。这样做的核心好处是：在浏览器的请求只会看到真正需要分析的包，减少误操作把正常请求拦死的概率。

另外，可以把一些静态资源请求过滤掉。图片、JS、CSS这类静态文件基本没有逻辑漏洞可利用，清掉后剩下的就是接口请求，信息密度高很多。规则配置的原则是“宽进严出”——从入口来看，流量尽量完整记录；从拦截来看，只拦需要手改的请求，日常浏览不打断。这样兼顾了完整记录和操作效率。

3. 并发漏洞的核心原理与实战打法

3.1 并发漏洞到底是什么：从正常请求到并发利用

并发漏洞，简单说就是服务端在处理“同时到达的多个请求”时，没有做好资源竞争的处理，导致最终结果不符合业务预期。生活化一点理解：两个人同时用同一个账号购买同一件商品，正常情况下应该只有一个人能买成功，但如果系统没有对库存和订单做好锁处理，两个人可能同时看到库存还有1件，都下单付款，最后超卖。

SRC场景里，并发漏洞最常见的触发方式是：同一个请求在极短时间内发送多份，每份请求都带着相同的参数和登录态，服务端如果把每份请求都当作独立业务来处理，就会出现重复操作。这类漏洞往往出现在以下几种业务场景：账号注册（批量创建）、优惠券领取（一人可领多次）、积分增加（重复增加）、订单状态修改（并发覆盖）、验证码校验（绕过次数限制）。

并发漏洞的通用判断标准是：依次连续发送同样请求100次服务端没有异常，但同一时间并发发送100次，出现了多次有效操作，例如积分增加了不止一次、优惠券领取到了多张、订单状态的异常跳变等。这个判断标准基本就是“串行无异常、并发有异常”。

3.2 并发漏洞的典型分类：并发绕过、竞争条件、逻辑覆盖

根据我实际提交SRC的经验，并发漏洞主要可以分成三类。

第一类是并发绕过。典型场景是“单次校验类”接口。比如短信验证码一个手机号只能发一次，正常顺序请求时服务端会检查“已使用状态”再拒绝，但并发请求同时到达，服务端可能来不及检查状态就把所有请求都处理了，导致验证码被绕过或重复发送。另一类典型是“限制次数类”接口，比如支付密码错误次数限制、登录尝试次数限制，并发请求能让次数校验形同虚设。

第二类是竞争条件（Race Condition）。典型特征是“检查前置、操作滞后”或“操作前置、检查滞后”。典型的例子是“先查询再更新”：用户先查余额，再发起支付请求，但操作执行的中间瞬态窗口极短。通过并发请求反复尝试，可以让两个操作交叉在同一时间片内完成，从而让余额被花费多次。这几年SRC里出现的很多优惠券重复领取漏洞，本质上就是竞争条件。

第三类是逻辑覆盖。典型场景是“同一资源被多个请求同时修改”。比如修改密码与修改手机号两个功能同时提交，服务端没有锁保护，一个请求把另一个请求的校验覆盖掉了，导致最终被修改出异常的账号状态。这类漏洞不好发现，因为正常顺序操作时所有状态都合法，只有并发交错才会出现覆盖。

区分这三类有一个简单方法：看并发请求触发的异常结果是否可稳定复现。能稳定复现，优先考虑竞争条件；偶尔触发但符合业务非线性逻辑，优先考虑并发绕过；在不同顺序下产生不同结果，优先考虑逻辑覆盖。

3.3 实战案例一：同一账号并发修改数据的覆盖问题

这个案例我在某模拟项目X里实际测过。目标是一个用户资料修改接口，支持修改昵称、手机号、邮箱。正常测试时，依次修改这几个字段，服务端都会正常返回成功，没发现异常。

我的并发实验思路是这样的：把修改昵称和修改手机号两个请求从抓包工具里提取出来，在重放工具里分别打开，然后同时对服务端发送。由于两个请求操作的是同一个用户的不同字段，理论上服务端应该逐个处理，各自更新自己的字段。但实际结果出现了覆盖：某个请求的响应里返回了另一个请求的数据，最终账号资料出现了异常状态，表现为手机号变成了其中一次请求设置的值，昵称却保留了旧值。

排查之后确认，问题在于服务端对用户资料更新没有做版本校验或行级锁。AB两个请求从Session里取出同一个用户ID，分别拼出自己的UPDATE语句，A还没来得及提交，B就把整行数据覆盖了。并发请求把“两个请求都成功”变成了“后提交的覆盖先提交的”，暴露了业务上不应出现的中间态。

这类覆盖问题在SRC里的危害判定不一定很高，但它证明了服务端并发控制缺失。实际提交时，如果能演示出账号状态的不可控变化，多数SRC会认可为中危逻辑漏洞。测这类漏洞时，建议把多个修改请求全部放到并发工具里同时发出，并记录服务端返回的先后顺序，因为提交报告时需要说明请求时序。

3.4 实战案例二：验证次数校验的并发绕过

另一个更典型的并发绕过场景是验证码或密码尝试。某个登录接口有“连续错误5次锁定账号”的安全策略，我用抓包工具测试时，先手动故意输错4次密码，第5次也输了错误密码，账号如预期被锁定。但如果把第5次的错误请求连同正确的请求并发发出，会出现什么？

实验过程是这样：先在登录页正常输入错误密码，抓到登录请求包；再准备一个正确密码的请求包，也放在重放工具里。关键步骤是，把5个请求全部放在同一个并发小组里同时发送。结果服务端没有锁定账号，而是错误和正确的请求全部被正常处理，账号成功登录，错误的尝试记录几乎没有生成。

原理是锁定逻辑在账号状态里写入了一个“已锁定”标记，但同一个时间片内并发到达的5个请求都读取到了“未锁定”状态并继续处理，锁定标记被后续请求直接覆盖或丢弃。这个漏洞虽然只存在于特定的“先检查后更新”实现中，但在真实SRC平台上出现过不止一次。

测这类漏洞有个前提：不能真的把目标账号搞废。如果并发绕过了判断逻辑但账号最终被锁，反而会影响后续测试。我的做法是先用自己控制的小号测试，确认漏洞成立后再在原账号上验证一次，避免误伤。另外，接口是否有频控、是否有滑块验证也要提前观察，有的目标站点在前端做了滑动验证但后端没有校验，这种根本没有测的必要。

3.5 实战案例三：额度、积分、余额类资产的并发翻倍

资产类并发漏洞是SRC提交里最容易拿高危的一类，因为影响直接且危害清晰。常见场景包括：新用户注册送积分、签到送积分、邀请奖励、充值赠送、优惠券发放。正常逻辑是每人限领一次，但并发请求可能让每人领到多次。

我在某个模拟项目X里测过一个签到积分接口。正常连续签到一天只能增加一次积分，服务端确实做了“今日是否已签到”的检查。但从抓包工具提取请求后，我用脚本并发发送了50次签到请求，结果发现积分增加了多次。这个接口的实现像是先查签到记录表，查不到就插入一条签到记录并增加积分，查询和插入之间没有做唯一约束，也没有锁保护，并发时多个请求同时发现“没有签到记录”就同时插入成功。

这类漏洞的修复方案一般是给“用户ID+日期”加唯一索引，或者把增加积分放到数据库事务里配合行级锁。作为测试方，我的原则是控制影响范围，并发次数控制在能证明漏洞成立的范围内就行，不要真的刷到离谱的额度，否则容易被平台判定为滥用。证明漏洞成立后，截下图、记录时间戳、保留请求包，清理测试数据再提交报告。

3.6 并发请求的成功率问题与处理技巧

并发测试不是每次都有结果，这里有一个成功率的问题。同一个并发请求，有时能触发异常，有时怎么发都没反应，并不是漏洞不存在，而是服务端的锁覆盖了窗口期。关键在于调整并发请求的节奏和数量。

我测试中发现，并发数量不是越大越好。超过某个阈值后，服务端的负载均衡或安全设备可能直接丢弃部分请求，或者触发接口限流，反而测不出结果。比较有效的做法是从较小的并发数量开始试，比如10个并发先试，没反应再逐步加大到50、100。同时配合请求顺序的微调，让关键请求尽量排在同一个时间片内发出。

另一个技巧是利用“延迟敏感型”接口。有些接口会异步处理业务，比如先把请求放进消息队列再慢慢处理，这类接口并发请求的成功率很低，因为消息队列天然做了排队。遇到这种接口，直接放弃并发测试，考虑其他方向。能马上看到结果反馈的同步接口是并发测试的最佳目标。

还有个小技巧是观察请求是否有明显的“序号、时间戳、随机串”参与。如果请求里带时间戳，而且服务端校验时间戳的范围，那并发请求发出时时间戳差异过大，可能导致部分请求被拒绝。遇到这种情况，可以先用抓包工具抓取一个基准请求，手动把所有并发请求里的时间戳改成同一值再发送。

4. 并发测试工具的实战用法

4.1 图形化工具的并发发送：操作快但可控性一般

Burp的Repeater模块可以手动重放请求，但对于并发测试，它默认是单线程的，发完一个再发下一个，达不到真正并发的效果。Burp里有一个支持并发发送的扩展，可以把一组请求放在同一个标签页里，设置并发线程数，一键发送。这个方式的好处是操作直观，请求包直接从抓包记录里拖过来，参数不用重新构造。

但它的弱点也很明显：不太好控制每个请求之间的精确时间间隔，而且无法做到“多个不同请求同时发出”。如果要测的是多个请求并行覆盖，比如A和B两个不同接口同时发，用这个扩展也可以实现，只是需要一顿配置。图形化工具比较适合快速验证思路，不适合做需要精细控制的复杂测试。

4.2 脚本化并发实现：可控性最强的方案

需要精细控制并发节奏时，我一般直接用Python脚本实现并发请求。构造几百个线程或协程，把同一接口爆发出大量请求，或者在极短时间内发出多个不同的请求。这种方式对请求体、请求头、Cookie、时间戳都能完全控制，适合处理带有动态参数的业务接口。

简单示例（仅示意实现思路，具体接口需要自行适配）：

import requests import threading url = "https://目标站点/sign/action" headers = {"Cookie": "你的登录凭证", "User-Agent": "Mozilla/5.0"} data = {"type": "daily_sign"} def send_once(): try: resp = requests.post(url, headers=headers, data=data, timeout=5) print(resp.status_code, resp.text[:100]) except Exception as exc: print("请求异常:", exc) threads = [] for i in range(30): t = threading.Thread(target=send_once) threads.append(t) for t in threads: t.start() for t in threads: t.join()

这个示例把同一个请求并发发送30次。实际使用时，需要先通过抓包工具拿到真实的URL、请求体、Cookie，以及可能需要的随机参数，再把它们替换进脚本。注意这里用的是普通线程加Sleep，实际高并发场景下可以用协程降低开销，但普通线程足够测试绝大多数SRC目标。

脚本的最大价值在于可控性：你能精确控制并发数、间隔时间、请求体内容，还能把返回结果按状态码分类统计。测试结果也更直观，可以直接判断哪些请求成功了、哪些被拦截了。缺点是需要自己处理会话维持和结果分析，不像图形工具那样所见即所得。

4.3 并发节奏控制：什么场景适合高并发，什么场景要收敛

并发测试不是一味堆数量。接口类型决定了合适的并发量级。验证码绕过、次数限制绕过这类漏洞，并发数量只需要10-20个就能稳定触发，因为服务端几乎不做并发保护。但如果是订单状态覆盖、库存超卖这类竞争条件，往往需要更高的并发量和更精确的时间控制。

我的建议是：第一波先用10个并发试水温，观察响应码和响应体；没有异常再跳到50个；还没有再看返回内容是不是出现了限流提示。如果出现限流的返回内容，说明服务端对高频请求有防护，此时需要降低并发数量并拉大请求间的间隔，或者换一个时间点再测，有时候防护规则是动态的，峰值时段策略更严格。

同时要留意接口的响应时间。如果正常单次请求的响应时间在500毫秒以上，说明服务端做了密集计算或依赖外部服务，并发请求大概率会排队处理而不是同时处理，这种情况下的并发漏洞很难触发。响应时间在50毫秒以内的接口更适合测试，因为服务端处理速度快，时间窗口短，并发请求容易在同一时间片内被处理。

4.4 结果判定：如何确认并发漏洞成立

并发测试跑完之后，最重要的一步是判定漏洞是否成立。我的判定标准非常严格，宁可漏掉一个也不报错一个。

第一步看数量：如果是积分、优惠券、次数这类“应该有唯一性”的资源，出现了数量增加多次，直接确认异常。第二步看状态：如果账号状态、订单状态、资料内容出现了重叠或覆盖导致的不一致，比如昵称变成了A、手机号变成了B，说明存在并发覆盖。第三步看响应：如果某些请求返回了成功，另一些返回了失败，但“成功”的数量大于应有限制，同样值得深挖。

这里有一个容易误报的点：如果请求里带了随机数或时间戳，并发时所有请求都带了相同的参数，服务端可能把后面的请求当成重复请求丢弃，返回一个“重复提交”提示。这种情况下出现多个成功才是漏洞，只有一个成功是正常去重逻辑，不能算并发漏洞。

另外，判定漏洞时一定要考虑“业务是否允许这种操作”。比如某些平台的积分任务本身就是可重复完成的，就不算漏洞；只有明确写了“每人限一次”还出现了重复，才算并发问题。所以测试前先读平台规则、接口文档或者页面上显示的限制说明，能少走很多弯路。

5. 抓包与并发实战中的常见问题排查

5.1 抓不到HTTPS包的问题

这是搭环境时遇到最多的一个问题。优先排查顺序是这样的：确认浏览器代理是否生效，访问一个HTTP网站试试能不能被Burp记录；确认Burp的证书是否已安装并被系统信任，没信任就重新导一次；确认Burp的监听端口是否被其他程序占用，换个端口立刻能判断出来。这个顺序基本能解决九成的问题，剩下的可能是插件干扰或系统代理冲突。

还有一种不太常见但存在的可能：目标网站开启了强制HSTS或者证书锁定。浏览器的地址栏会提示安全连接失败，Burp里也可能只看到CONNECT请求看不到明文。这种情况下可以考虑用旧版本浏览器或者换协议入口测试，实在不行就放弃这个站点的流量分析，专注其他可正常抓包的目标。

5.2 并发请求特征被识别的情况

有些目标平台部署了安全设备，对高频并发请求的User-Agent、Cookie、请求头一致性做检测。如果出现“并发请求全部被拦截”的情况，第一个要检查的是请求头是不是缺少了某些必要字段，比如一些站点要求请求头里必须带特定的自定义字段，否则拒绝。第二个要检查的是Cookie时效，并发请求比串行请求更依赖稳定的Cookie，一旦某个请求的Cookie过期，整批请求都会受影响。

处理办法是：把抓包工具里请求的所有请求头原样复制到脚本里，不要自己构造一个精简版；同时先用单个请求测试Cookie的有效性，确认200返回后再跑并发。如果是时间戳类参数影响，手动把所有并发请求的时间戳字段改成同一个值。需要强调的一点是，如果目标平台的防护明显很强，不要硬闯，换其他接口或换时间窗测试。

5.3 误报与无效漏洞的判断经验

误报是新手最常遇到的问题。看到一次并发请求里出现了两个“成功”，就觉得漏洞成立，实际很可能是服务端做了幂等处理，同一个操作在后端被去重或覆盖了。比如优惠券领取接口并发发送10次，有5次返回成功，但实际只生成了一张券，这种情况是“展示误报”，不代表产生了5张券。

如何确认是不是真误报？追踪最终状态，而不是只看接口返回。领取类接口要看目标账号实际到账的券数量，修改类接口要查修改后的真实数据，积分类接口要看积分变动记录。最终状态发生变化才算漏洞成立。我一般是在目标平台允许的操作范围里做验证，比如用测试账号查看实际数量，或者通过平台查询功能确认结果。如果目标平台没有提供查看入口，那就只能多复现几次，稳定触发才提交。

5.4 环境与测试问题速查表

这张表是我实际过程中遇到最多的几类问题。搭环境和测漏洞说白了都是经验活，遇到问题不要慌，按顺序排查，大多数情况都是配置层面的小问题。真正需要动脑子的是判断漏洞是否成立，这需要多积累对业务逻辑的理解，不是工具能直接替代的。

6. 并发漏洞提交与一些个人体会

前面讲的是怎么测，最后聊一下怎么交。SRC平台审核漏洞报告时，最看重的是漏洞的可复现性和影响面。并发漏洞尤其要写明触发方式，因为审核人员需要按你的步骤复现，复现不了就不会认。我的报告习惯是：标题写清影响和类型，比如“签到接口存在并发绕过可重复领取积分”；复现步骤按时间顺序逐条写，每一步附带请求包截图和响应包截图；影响说明写清楚会造成什么后果，比如积分可被无限刷取、影响平台结算等。

还有一个容易忽略的点：并发漏洞报告如果只写“我发了100次请求成功20次”，审核根本没法判断是不是网络波动造成的。更好的写法是给出串行对照组：依次发送100次全部被拒绝，并发发送50次成功20次。这个对照能直接证明是并发导致的问题，而不是接口本身允许操作。

我在实际操作中体会最深的是，并发漏洞虽然看似简单，但它非常考验对业务逻辑的理解深度。同样是并发发送相同请求，有的接口天然幂等，怎么发都没事；有的接口只要并发一次就出问题。能挖到什么取决于你愿不愿意仔细看每一个接口的返回逻辑和状态变化。很多时候漏洞就藏在一个你顺手就能跨过去的判断里，只有慢下来的人才能看见。

最后再分享一个实用小技巧：把抓包工具的规则配置和并发测试脚本保存成模板。每次拿到新的SRC目标，导入模板、改域名和Cookie，马上就能开测。这套流程从搭环境到测并发，熟练之后半小时就能完成前面所有准备工作，省下的时间全都能花在真正有价值的逻辑分析上。