AI辅助漏洞挖掘实战：从HTTP流量分析到越权漏洞检测

做软件测试的同行应该都有过这种体验：抓包工具里躺着几百上千条请求，真正需要人工去翻、去推测、去手工改参数的也就那么几十条，但就是这几十条，往往会吃掉整个下午。漏洞挖掘这个行当，门槛其实不在“会不会用工具”，而在“能不能从流量里嗅出业务逻辑的异常”。这种能力很吃经验，新人很难速成。但最近我把大模型接进日常工作流之后，发现这个局面正在被改变——AI不是替你发现漏洞，而是替你完成“信息筛选、异常判断、Payload生成”这三件最耗时的事。

这篇文章我想完整分享一下我目前在使用的一套AI辅助漏洞挖掘方法：从工具链搭建、提示词设计，到实测一个越权漏洞的完整过程，再到误报处理和合规边界。不吹不黑，哪些地方AI真的能省时间，哪些地方它纯属添乱，我都会摊开讲。适合软件测试工程师、安全测试新人，还有正在研究大模型落地业务的技术人。

1. 为什么AI在漏洞挖掘中不是噱头：三个绕不开的瓶颈

很多团队对“AI挖洞”的第一反应是：这不就是拿GPT生成几个Payload吗？其实不是。要理解AI在漏洞挖掘里的真实价值，得先承认传统工作流里三个长期存在、但大家已经麻木的问题。

1.1 人力瓶颈：安全测试的时间都花在哪里了

我见过不少刚入行的测试同学，拿到一个测试环境后第一件事是开Burp Suite挂爬虫，把所有能点的按钮都点一遍，然后把流量导出来，开始一条条人工翻。

这个过程有多耗时？举个例子：一个中等复杂度的订单系统，注册、登录、下单、支付、退款、售后，再加上后台管理接口，全流程过一遍，产生的HTTP请求量通常在一千到两千条之间。传统扫描器能自动标记出高危特征的就那么几十条，剩下的全靠人眼去识别“这个接口把用户ID直接放在URL里了”“那个接口的响应里多了个不该出现的字段”。一个资深安全测试一天能认真分析的有效流量，保守说也就两百条左右，超过这个量，注意力就开始下降，漏掉的问题会指数级增加。

这个瓶颈的本质是：漏洞挖掘的信息处理密度极高，而人的短期注意力带宽极其有限。AI的介入，首先解决的就是这个“注意力分配”问题。

1.2 规则瓶颈：传统扫描器为什么看不懂业务

可能有人会说，那用AWVS、AppScan这种商业扫描器不就行了？这里就要说清楚传统工具的边界。

传统扫描器的核心是模式匹配和签名库：URL里出现 id=1' 就尝试报SQL注入，参数里出现 <script> 就报警XSS。这套逻辑对付“无脑注入”型漏洞确实高效，但一旦漏洞需要理解业务语义，它就完全失能了。

什么叫理解业务语义？拿最典型的越权漏洞举例：一个查看订单详情的接口 /api/order/detail?orderId=10086，当前登录用户A能正常看到自己的订单。如果我把orderId改成10087，发现也能看到别人的订单信息，这就是一个水平越权漏洞。但传统扫描器根本不知道“orderId应该属于当前用户”这个业务规则，它只会机械地测参数值，测出响应码相同就认为没异常。

这类逻辑漏洞恰恰是目前SRC平台和众测项目里占比最高、危害最大的漏洞类型。而这类漏洞的发现，极度依赖“把请求放进业务场景里去理解”的能力。

1.3 AI切入点：大模型恰好补上了语义推理这块短板

大语言模型跟传统扫描器最大的区别，在于它具备上下文理解和语义推理能力。给它一段HTTP请求，它能判断出“这个接口返回了用户手机号”“这个参数看起来是订单归属者的标识”“如果把这个参数替换成另一个值，可能会造成越权”。这已经接近一个初级安全测试人员在做的事情了。

我打一个比方：传统扫描器像一个金属探测器，扫到金属就滴滴响，但分不清是钉子还是金戒指；合格的AI辅助工具像一个有经验的安全顾问，它会看这个人脸色、动作、行踪，先圈出可疑对象，再有针对性地做检查。后者不是对前者的替代，而是把“人肉分析”的环节前置到机器上。

当然，AI也不是万能的。它的“经验”来自训练数据，不是真实业务系统，所以它给出的结论必须经过人工复核。这一点我在后面专门用一整章来讲。先继续把工具链搭起来。

2. 搭好武器架：AI漏洞挖掘工作台的选型与配置

在开始接入AI之前，要先把整个工作流梳理清楚。AI在漏洞挖掘中承担的角色可以分成三块：流量理解与异常识别、测试思路生成、Payload构造。这三块对工具的诉求不一样，所以选型时要分开考虑。

2.1 三种主流接入方式对比

目前把AI接入漏洞挖掘工作流，主流做法大概有三种：Burp Suite插件、独立代理脚本、CLI问答式工具。我三个都试过，各自适用场景完全不同。

我个人更推荐第二种作为主力：自己用代码写一个代理脚本，一方面是完全可控，另一方面是方便在批量的历史流量上跑分析。Burp插件适合在线分析单条请求，但你无法对一千条历史请求做批量语义分析。

2.2 自建一个轻量流量分析脚本

我现在的做法比较朴素：抓包工具负责采集流量导出成JSON或文本格式，然后由一个Python脚本把请求内容交给大模型API，让模型逐个分析。整体流程非常简单，核心代码也就几十行。

python复制import json
import os
import time
from openai import OpenAI

client = OpenAI(
    api_key=os.getenv("LLM_API_KEY"),
    base_url=os.getenv("LLM_BASE_URL"),  # 支持使用兼容OpenAI协议的本地模型服务
)

def analyze_request(request_text: str, system_prompt: str) -> str:
    response = client.chat.completions.create(
        model=os.getenv("LLM_MODEL", "gpt-4o-mini"),
        temperature=0.1,
        max_tokens=1500,
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": request_text},
        ],
        timeout=60,
    )
    return response.choices[0].message.content

def process_traffic(traffic_file: str):
    with open(traffic_file, "r", encoding="utf-8") as f:
        requests = json.load(f)

    results = []
    for i, req in enumerate(requests):
        try:
            # 每次调用之间留一点间隔，避免触发API限流
            result = analyze_request(json.dumps(req, ensure_ascii=False), SYSTEM_PROMPT)
            results.append({"index": i, "url": req.get("url"), "ai_result": result})
            print(f"[{i+1}/{len(requests)}] 完成: {req.get('url')}")
        except Exception as e:
            print(f"[{i+1}/{len(requests)}] 失败: {e}")
        time.sleep(0.5)

    with open("ai_analysis_results.json", "w", encoding="utf-8") as f:
        json.dump(results, f, ensure_ascii=False, indent=2)

这段代码之所以设计成“每批次循环调用”，是为了处理大量流量时的稳定性。你可能会问，为什么不一次性把一千条请求全部塞给模型？因为上下文窗口是有限的，而且请求量太大时模型很容易抓不住重点。更好的做法是先做一层提取，把每条请求的关键信息压缩成“请求行+关键参数+响应摘要”再喂给模型。

2.3 模型选型：云端API还是本地模型

模型的选择直接决定了分析质量和成本。我实测过几类模型，简单说下感受。

云端大模型API（如GPT-4o系列、Claude系列）的语义理解能力是第一梯队，分析复杂的业务逻辑、生成合理的测试思路，效果明显更好。缺点是要把流量数据发送到第三方服务，虽然一般可以签订数据协议，但部分企业客户对数据出境有合规要求，这就要谨慎了。

本地部署的开源模型（如Qwen系列、Llama系列）最大的优势是数据不出内网，适合企业环境。缺点是对硬件有要求，性能弱的机器跑大尺寸模型会慢到难以接受。我个人的经验：拿Qwen2.5-14B这类级别的模型做基础流量分析是够用的，但想让它产出一个巧妙的条件竞争测试思路，还是吃力。

性价比上来讲，我的建议是：个人学习、SRC挖洞场景直接用云端API，按量付费，一天分析几百条流量成本也就几块钱；企业内部场景优先考虑本地部署，哪怕效果略逊，合规性才是底线。

2.4 配置参数里的三个常见坑

工具搭好之后，真正跑起来时你会发现，坑全在细节里。我的经验里有三个特别值得提醒的点。

第一个是temperature参数。很多初学者直接用默认值0.7甚至1.0，结果模型发挥很不稳定，同样的请求这次说有越权风险、下次说没问题。漏洞分析需要的是稳定、可复现的判断，temperature应该调到0.1甚至0。实测下来，0.1是一个不错的平衡点，既降低了随机性，又不至于让模型过于死板。

第二个是max_tokens设太小。有一次我分析一个复杂的支付流程接口，模型分析到一半被截断了，结论没输出完整。后来把max_tokens调到1500以上，这种问题才消失。

第三个是API调用超时和重试。大模型接口偶尔会响应慢，如果你不做超时控制和重试机制，批量处理一千条请求时，大概率会卡在某一条上导致整个脚本挂掉。我习惯用这个配置：超时60秒，失败自动重试3次，重试间隔按指数退避，从1秒开始翻倍。

3. 让AI读懂HTTP报文：上下文构造与提示词模板

工具链搭好了，接下来最重要的一步是把HTTP请求包装成模型能理解的信息。这一步做不好，前面的工作全部白费——模型不是神，它只能根据你给的信息做判断。

3.1 每条请求要提供哪些上下文

很多人在这一步犯的错误是：直接把原始抓包导出的文本一股脑丢给模型。这样做的问题是信息太杂。真实的HTTP流量里充满了各种无意义的内容：随机生成的Token、埋点信息、静态资源请求、大量重复的CSS/JS请求。模型处理这些噪声会消耗上下文窗口，挤占了对关键信息的分析深度。

我通常在发给模型之前，先对每条请求做一层轻量清洗，保留以下字段：

• 请求方法、URL路径和查询参数
• 经过脱敏处理的请求头（主要保留认证方式、Content-Type）
• 请求体，但会去掉明显无意义的动态token
• 响应状态码和关键响应字段（如返回了哪些用户信息、金额字段）
• 当前请求所在的业务场景标签，比如“订单查询”“注册”“支付回调”

这最后一个字段特别重要。同样是 POST /api/user/info，在“用户修改个人资料”和“管理员查看用户列表”两种场景下，威胁模型完全不同。所以我在抓包时习惯手工给请求打一个场景标签，或者在脚本里通过URL规则自动打标签。

3.2 一套可以直接抄走的System Prompt模板

清洗完上下文之后，System Prompt的设计是决定性的一步。我踩了不少坑之后，现在固定用下面这套模板，效果比较稳定：

text复制你是一名拥有十年经验的Web应用安全测试专家，擅长业务逻辑漏洞挖掘。
我会给你一段HTTP请求的清洗文本，包含请求方法、URL、参数、响应摘要和业务场景描述。

请你从安全测试角度进行分析，只做以下三件事：
1. 异常点识别：指出请求中最值得关注的参数、接口逻辑或异常响应，重点考察越权、IDOR、逻辑绕过、条件竞争、敏感信息泄露等风险。
2. 利用思路：基于当前请求给出1到2条可落地的测试思路，必须是可执行的具体步骤，不要泛泛而谈。
3. Payload建议：针对你给出的测试思路，生成一个可直接提交的HTTP请求修改示例，用JSON格式输出。

输出格式要求：
{"risk_points": ["..."], "test_ideas": ["..."], "payload_suggestions": [{"method": "POST", "url": "...", "body": "..."}]}

注意：
- 只针对当前请求和场景做分析，不要臆造不存在的接口或参数。
- 如果认为该请求没有明显风险，直接在risk_points数组里返回["暂无发现"]。
- 严禁输出任何破坏性利用方式的代码，你提供的是防御性测试建议。

这套提示词有几个设计细节值得说明。第一，明确限定模型“不要臆造不存在的接口或参数”，能显著降低后面要讲的幻觉问题。第二，要求输出JSON格式，方便脚本自动解析，直接进入下一环节。第三，最后那句“防御性测试建议”并非空话，它能在一定程度上约束模型生成合理的测试逻辑，而不是输出一堆破坏性代码。

3.3 让模型输出结构化JSON，而不是长篇大论

有一段时间我让模型自由发挥写分析意见，结果输出一大堆又长又空的套话，根本没法自动化处理。后来把所有输出强制为JSON格式，情况立刻好转。这里有个小技巧：在System Prompt里给出一个具体的JSON示例，比单纯说“用JSON输出”效果要好得多。

模型对“格式示例”的遵循能力远高于对“格式指令”的遵循能力。我在提示词里直接放了一个完整的输出样例，实测模型返回合法JSON的成功率从70%左右提升到了95%以上。

解析结果时，记得用 json.loads() 包一层容错逻辑，因为模型偶尔还是会输出带注释或Markdown代码块包裹的JSON。我在脚本里会先做一次清理：去掉首尾的反引号、json 标记，再尝试解析。

3.4 温度、上下文窗口与并发策略的实操调优

前面提过temperature要调低，这里再补充一下其他参数的经验值。上下文窗口这一块，我把单条请求清洗后的文本控制在1000字以内，一般不会超过上下文窗口的15%到20%，给模型的推理留足空间。

批量任务处理时，并发不要开太大。很多API接口有每分钟请求数限制，我通常控制在5到10个并发，并加了简单的token桶限流。实测下来，10个并发配合0.5秒的间隔，既不会触发限流，处理速度也能接受。

4. 实战记录：一次订单越权漏洞的AI辅助挖掘全过程

工具和提示词都搞定了，接下来看一个真实场景的完整流程。我拿自己搭的一个测试环境举例，这个环境复刻了电商系统常见的订单功能，漏洞是典型的水平越权。整个过程是结构化、可复现的。

4.1 场景设定与授权范围

这是一个授权范围内的测试环境，数据库里预置了两个用户：用户A（ID=1001）和用户B（ID=1002）。两个用户各自有订单。测试目标是找出当前登录用户A能否访问到用户B的订单数据。

按照传统做法，我会登录A账号，抓取查看订单列表和订单详情的请求，然后手工修改订单ID、遍历订单号，再观察响应内容。这套流程写出来很简单，但实际做起来，光是定位到“订单详情接口并理解它的参数结构”就要花不少时间。

4.2 抓包后的原始请求与清洗

抓包工具采集到一条订单详情接口的请求，大致长这样：

http复制GET /api/v1/order/detail?orderId=20250112001 HTTP/1.1
Host: shop-test.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: application/json

对应的响应体摘要是：订单号、商品名称、收货人姓名、收货地址、手机号前三位后四位、订单金额、订单状态。

经过清洗后喂给AI的文本是这样的：

json复制{
  "method": "GET",
  "url": "/api/v1/order/detail",
  "params": {"orderId": "20250112001"},
  "auth": "Bearer Token (脱敏)",
  "response_summary": "返回订单详情，包含orderId、商品名、收货人(address)、手机号(脱敏)、orderAmount、status",
  "biz_scene": "订单查询-用户查看自己订单详情"
}

注意清洗后的文本里已经没了Authorization的实际值，只剩一个标记。这样做是基本的敏感信息保护习惯，同时不影响AI判断接口是否依赖认证。

4.3 AI的分析结论与人工验证

模型返回的结果是：

json复制{
  "risk_points": [
    "接口通过orderId直接查询订单详情，未在URL或参数中体现当前用户身份标识，存在水平越权(IDOR)风险",
    "响应中返回了收货人姓名和地址，属于敏感个人数据"
  ],
  "test_ideas": [
    "将orderId替换为另一用户的订单号，观察响应是否返回他人订单数据",
    "尝试修改请求中的用户标识头字段(如X-User-Id)，观察后端是否信任前端传入的用户身份"
  ],
  "payload_suggestions": [
    {
      "method": "GET",
      "url": "/api/v1/order/detail?orderId=20250112002",
      "body": ""
    }
  ]
}

说实话，第一次看到这个输出的时候，我还是比较惊讶的。它不只是指出了“orderId可能存在问题”，还准确推断出“接口没有在参数中体现当前用户身份标识”，这正是越权漏洞的核心判断依据。传统扫描器几乎不可能给出这种程度的业务逻辑推理。

我按它的建议做了验证：把orderId替换成用户B的订单号20250112002，重新发送请求，结果确实返回了用户B的订单详情，里面包含了完整的收货人姓名和地址。水平越权确认。

整个过程从流量分析到拿到可利用漏洞，大约花了十五分钟，其中大部分时间在等待API响应。如果纯靠人工分析，光是在近千条流量里定位到这条“值得测”的请求，就得花上半小时以上。

4.4 同一套流程用到优惠券场景：逻辑漏洞的延伸

发现越权漏洞之后，我顺带把同样的流程跑了一遍优惠券使用接口。这个接口是 POST /api/v1/coupon/apply，请求体里包含 couponId、orderAmount、userId 三个字段。

AI的分析结论是：orderAmount 字段来自前端请求体，且接口没有在响应中重新校验计算后的金额，存在“金额参数被篡改”的逻辑漏洞风险，建议把 orderAmount 改为0.01尝试。

这个思路真的很关键。一开始我并没有注意到 orderAmount 是从前端传入的事实，直到AI把这个参数标红，我才重新审视了这个接口的参数设计。虽然最终测试环境里这个风险因为服务端的二次校验而不成立，但AI确实帮我找到了一个值得验证的测试点，这在纯人工流程里很容易被忽略。

4.5 真正的省时间环节在哪里

几个场景跑下来，我的体感是：AI在漏洞挖掘工作流中省时间最明显的环节，不是生成Payload，而是第一轮的信息筛选和风险点标注。它能代替我去看那几百上千条请求，把值得关注的接口挑出来并给出理由。人只需要针对高价值的候选项去做验证即可。

Payload生成的价值也有，但没那么大，因为很多Payload在网上模板里都能找到，AI的增量价值是能根据具体的接口参数定制Payload，避免“万能Payload”失效后抓瞎。

5. AI输出不能直接信：误报治理、幻觉识别与合规边界

AI给出的分析结论再怎么像模像样，它本质上依然是一个概率模型，不是真正的安全测试专家。把它当助手用可以，把它当裁判用就危险了。这里分享几个我踩过的坑和正在使用的治理策略。

5.1 误报的三个来源

误报是AI辅助漏洞挖掘里最让人头疼的问题。我总结下来，误报主要来自三个来源。

第一，训练语料偏差。大模型在训练数据里见过太多“看起来很像漏洞”的代码和接口，容易过度敏感。一个正常的、有权限校验的接口，可能只是参数的命名方式长得像IDOR，它就给你标成高危。

第二，上下文缺失。AI只看到了你喂给它的那一段清洗文本，而真实业务里，认证可能在网关层做统一校验，参数校验可能在更前置的WAF层完成。AI看不到这些，自然容易做出错误判断。

第三，授权与业务边界理解不足。模型无法真正理解“这个接口本来就是给管理员用的，返回所有用户列表是正常功能”。它会机械地认为“返回了用户列表=信息泄露”。

理解了误报来源，就能对症下药。

5.2 我的三层过滤流程

现在我处理AI分析结果，遵循一套固定的三层过滤流程。

第一层是规则过滤。我在脚本里内置了一套正则和关键词规则，把明显正常的接口先滤掉。比如静态资源、登录接口、健康检查接口，这些天然不值得做越权测试，AI却经常误报。

第二层是交叉验证。同一个请求，我会用两个不同的模型各分析一次，或者用同一个模型但改变部分提示词再问一次。两次都判定为高风险，可信度才高。这一招的成本不低，但能有效过滤掉大量随机性误报。

第三层是人工Spot Check。AI和规则筛选之后剩下真正需要人工看的请求，一般已经被压缩到总量的5%到10%以内了。这一小部分，我会逐条人工确认。事实上，这种“AI初筛+人工复核”的模式，比我以前纯人工逐条看流量的方式，覆盖面和准确率都更高。

5.3 幻觉案例：模型建议了一个不存在的参数

幻觉问题最典型的案例，是有一次我分析一个手机号注册接口，模型在Payload建议里给出这样一个修改示例：

json复制{"sms_code": "000000", "verify_token": "123456"}

但实际接口的请求体里根本没有 verify_token 这个字段，只有 smsCode 和 phoneNumber。这就是模型“脑补”了一个它认为应该存在的参数。如果测试人员不加验证就直接提交，大概率会得到一个参数错误，白白浪费时间。

这类幻觉很难完全消除，有效的应对方式是：在System Prompt里反复强调“只针对请求中出现的参数进行测试”，并且建议模型在构造测试请求时先列出现有参数，再基于现有参数做修改。实测下来，幻觉出现的概率能下降一半以上。

5.4 合规边界：授权范围必须写进工作流

最后必须提醒一句：AI辅助漏洞挖掘，本质上还是漏洞挖掘，永远不能脱离“授权”这个大前提。不管是挖自己的系统、参加SRC活动，还是做众测，都必须在授权范围内测试。

我的做法是在整个工作流前面加一个配置项，明确当前任务的授权范围：

python复制AUTHORIZATION_SCOPE = {
    "domains": ["shop-test.example.com"],
    "allowed_methods": ["GET", "POST"],
    "prohibited_actions": ["数据导出", "拒绝服务测试"],
    "notes": "仅限测试环境，禁止访问生产环境"
}

这个配置不仅是一句声明，我还会在给AI的提示词里附上授权范围的摘要，让模型在生成测试建议时自动规避超出范围的思路。比如授权范围明确“禁止拒绝服务测试”，模型就会忽略任何与压测、并发轰炸相关的建议。

同时，输出结果里涉及真实个人信息的一律脱敏后再展示和记录。这是对自己负责，也是对被测系统里的用户数据负责。道德黑客的“道德”两个字，不应该只是标题里的装饰，它应该落到工具设计、提示词约束、数据处理的每一个细节里。

这些做完，整套AI辅助漏洞挖掘的工作流才算是闭环了。每次跑完一批流量，我拿到的不只是一份AI分析结果清单，而是经过筛选、验证、可溯源、合规的风险报告——这套流程我跑了几个月，越用越觉得它已经变成我日常测试工作里离不开的一个环节了。如果你也在做软件测试或者刚接触漏洞挖掘，建议先从自己搭建的靶场环境开始试，把流程跑通、把提示词调到自己顺手，再上真实项目。这套东西，值得花一个周末去折腾。