当前位置： 首页 > news >正文

Burp Suite扫描深度配置指南：被动扫描、主动扫描与自定义插入点协同调优

news 2026/5/24 4:19:42

1. 这不是“点一下就扫完”的配置，而是扫描质量的分水岭

很多人把 Burp Suite Scanner 当成一个“自动漏洞探测器”——填个 URL，点下“Active Scan”，等它跑完弹出一堆高危告警，就以为任务完成了。我见过太多这样的场景：安全测试报告里列着 37 个“SQL 注入（高）”，结果开发一查日志，全是扫描器往/favicon.ico、/robots.txt甚至POST /login的 JSON 字段里硬塞' OR 1=1--导致的 400 错误；也见过被动扫描开了半年，却漏掉了整个管理后台的/api/v2/internal/*路径，只因为 Burp 默认不把带internal的路径当“敏感上下文”。这些不是工具不行，而是配置没穿透到业务逻辑层。

Burp Suite Scanner 的核心价值，从来不在“能不能扫”，而在于“扫得准不准、深不深、稳不稳”。主动扫描（Active Scan）决定你能否发现可利用的漏洞，被动扫描（Passive Scan）决定你能否捕获真实流量中的逻辑缺陷，而自定义插入点（Custom Insertion Points）则决定了扫描器是否真正理解你的应用——它知道哪些参数是 JWT 的Authorization头里的 Base64 编码字段，哪些是 GraphQL 请求体中嵌套三层的variables.user.id，哪些是 WebSocket 消息里用\x00分隔的二进制字段。这三者不是并列功能模块，而是一条递进链：被动扫描喂数据，自定义插入点定靶心，主动扫描打穿靶心。本文讲的，就是如何把这条链从“能跑通”调校到“打得准”。

关键词全部落在标题里：Burp Suite Scanner是载体，主动扫描是攻击面验证手段，被动扫描是流量感知机制，自定义插入点是语义理解能力。如果你正在做渗透测试、红队评估、SDL 安全左移或 API 安全治理，且已熟悉 Burp 基础界面（Proxy、Repeater、Target），那么这篇内容就是为你写的——它不教你怎么安装 Burp，也不讲“什么是 SQLi”，而是聚焦在：当你面对一个 Vue+Spring Cloud+gRPC 的混合架构后台、一个带 JWT 和动态签名头的移动端 API、或一个用 Protobuf 序列化请求体的 IoT 管理平台时，如何让 Scanner 不再是“盲扫”，而是成为你业务语义的延伸。

我试过 17 种不同配置组合，踩过包括“扫描器因自定义插入点正则写错导致 CPU 占满 100% 持续 6 小时”“被动扫描误将加密 token 当作普通参数注入导致大量误报”在内的 9 类典型坑。下面的内容，就是我把这些实操经验反向拆解后，按真实工作流重构的深度配置指南。

2. 被动扫描不是“开着就行”，它是整个扫描策略的数据源与质量基线

2.1 被动扫描的本质：流量镜像 + 上下文建模，而非简单抓包

很多人以为 Passive Scan 就是“Proxy 流量自动进 Scanner”，这是最大误解。Burp 的被动扫描器（Passive Scanner）实际执行的是三阶段处理流水线：

  1. 流量捕获层（Capture）：监听 Proxy、Spider、Repeater、Intruder 等所有模块发出的 HTTP(S) 请求/响应（注意：默认不捕获 WebSocket 帧、gRPC 流、FTP 或非 HTTP 协议流量）；
  2. 上下文提取层（Extraction）：对每个请求/响应，提取 URL、参数名、参数值、Header 名/值、Cookie、JSON Key/Value、XML Tag/Text、HTML Form Action/Field 等结构化元素；
  3. 规则匹配层（Matching）：将提取出的每个元素，逐条比对内置的 200+ 条被动扫描规则（如 “检测响应中是否含mysql_fetch_array错误字符串”、“检测Set-Cookie是否缺失HttpOnly标志”）。

关键点在于：被动扫描不发任何新请求，它只分析已有流量；但它分析的粒度，直接决定后续主动扫描的靶点质量。如果被动扫描漏掉了某个关键参数（比如前端拼接在 URL 中的?token=xxx&region=cn-shanghai），那么主动扫描就不会把这个region当作可注入点；如果它把加密后的data字段当成明文参数处理，就会在错误位置尝试注入，导致大量无效 payload 和误报。

提示：被动扫描的“上下文提取”能力，完全依赖 Burp 对协议结构的理解深度。默认情况下，它能正确解析标准 JSON、XML、HTML、URL-encoded 表单，但对以下场景会失效：

  • GraphQL 请求体中的{"query":"query{user(id:$id)}","variables":{"id":"123"}}——$id是变量占位符，但 Burp 默认不会识别variables.id为独立插入点；
  • Protobuf 序列化后的二进制请求体 —— Burp 无法解析其字段结构，仅将其视为原始字节流；
  • 自定义编码的 Header（如X-Signature: base64(hmac-sha256(body+secret))）—— Burp 不会解码X-Signature值，更不会意识到 body 改变后该 Header 必须重算。

2.2 关键配置项详解：从“能运行”到“懂业务”

Burp 的被动扫描配置入口在Dashboard → Passive Scan，但真正起效的设置分散在三个地方：全局扫描配置、目标范围定义、以及最关键的“Scope”控制。我们逐项拆解：

2.2.1 Scope 设置：不是“加域名”，而是“画语义边界”

很多用户在Target → Site map里右键添加目标时，只输入https://api.example.com，以为这就覆盖了全部。但实际中，https://api.example.com/v1/users和https://api.example.com/v2/internal/debug的安全等级天差地别。Burp 的 Scope 机制，本质是定义“哪些流量值得被深度分析”。正确做法是：

  • 在Target → Scope中，显式勾选Use advanced scope control；
  • 点击Add，输入正则表达式而非简单 URL：
    • ✅ 推荐：^https?://api\.example\.com/v[1-2]/(?!internal/).+
      （匹配 v1/v2 下除/internal/外的所有路径，避免扫描调试接口）
    • ❌ 避免：https://api.example.com
      （会匹配到https://api.example.com/internal/healthz，且无法排除）

更进一步，可结合Context字段做语义过滤。例如，某 SaaS 平台多租户 API 通过X-Tenant-IDHeader 区分客户，你只想扫描tenant-a的流量，则在Target → Scope → Context中添加规则：Header: X-Tenant-IDcontainstenant-a。这样，即使同一域名下的tenant-b流量经过 Proxy，也不会进入被动扫描队列。

2.2.2 扫描规则开关：关掉“噪音制造机”，打开“业务探测器”

Burp 内置被动扫描规则共 214 条（v2024.8 版本），但其中约 35% 属于“通用型低价值告警”，如：

  • Cookie without HttpOnly flag（无 HttpOnly 的 Cookie）：现代框架默认开启，除非你明确禁用，否则纯属干扰；
  • Server header contains version information（Server 头含版本号）：信息泄露类，但修复优先级远低于逻辑漏洞；
  • Missing X-Frame-Options header（缺少 X-Frame-Options）：已被Content-Security-Policy: frame-ancestors取代。

我实测过：在扫描一个中型电商后台时，全开规则产生 1287 条被动告警，其中 912 条是上述三类；关闭后剩余 375 条，人工复核确认 289 条为真实风险（含 3 条越权访问、2 条未授权文件读取）。因此，我的推荐开关策略是：

规则类别推荐状态理由
认证与会话类（如Weak password in login form,Session token in URL）✅ 开启直接关联账户安全，误报率低
API 逻辑类（如Insecure direct object reference (IDOR),Missing rate limiting）✅ 开启被动扫描可通过响应码/响应体长度差异发现 IDOR
加密与传输类（如TLS version too old,Weak cipher suite）⚠️ 按需开启需配合 TLS 握手日志分析，单独看响应无效
信息泄露类（如Server header version,X-Powered-By header）❌ 关闭修复成本低但价值极小，挤占有效告警空间
前端安全类（如Missing CSP header,Unsafe eval() usage）⚠️ 仅对 Web 前端开启后端 API 无需关注 CSP

操作路径：Dashboard → Passive Scan → Options → Rules，取消勾选对应规则即可。注意：关闭规则不影响主动扫描，只影响被动扫描告警生成。

2.2.3 插入点提取策略：让扫描器“读懂”你的协议

这是被动扫描最易被忽视、却影响最大的配置。入口在Dashboard → Passive Scan → Options → Insertion Points。默认设置是“Extract from all locations”，即从 URL、Body、Headers、Cookies 等所有位置提取参数。但问题在于：它不知道哪些位置是“业务关键参数”，哪些是“固定元数据”。

以一个典型的 JWT 认证 API 为例：

GET /api/v1/orders?status=pending HTTP/1.1 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... X-Request-ID: a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8
  • status=pending是业务参数，应作为插入点；
  • Authorization头的 JWT 是加密凭证，不应被修改（否则请求失败）；
  • X-Request-ID是追踪 ID，格式固定，无注入风险。

但默认配置下，Burp 会把Authorization值的 Base64 解码后，当作普通字符串尝试注入（如在ey...中插'; DROP TABLE），导致请求 401，且污染扫描日志。

解决方案：禁用高风险位置的自动提取，改用白名单模式。

步骤：

  1. 在Insertion Points选项卡，取消勾选Extract from headers和Extract from cookies；
  2. 勾选Extract from URL query string和Extract from request body；
  3. 点击Add，手动添加白名单插入点：
    • Location:URL query string
    • Parameter name:status
    • Parameter type:String
    • Context:All requests to https://api.example.com/api/v1/.*

这样，被动扫描只会在/api/v1/路径的 URL 查询参数中提取status，其他位置一律忽略。实测效果：某金融 API 的被动扫描告警量下降 63%，但高危逻辑漏洞检出率提升 22%（因减少了无效请求对真实流量的干扰）。

2.3 被动扫描的实战陷阱与避坑清单

我在给三家银行做 API 安全评估时，反复踩过这些坑，现总结为可立即执行的检查清单：

陷阱现象根本原因修复操作验证方式
被动扫描无告警，但手动测试明显存在 XSS目标域名未加入 Scope，或 Scope 正则语法错误（如忘记转义点号.）进入Target → Scope，点击Show details查看当前匹配的请求 URL 列表；用^https?://[^/]+/api/.*替代https://api.example.com发送一个带<script>alert(1)</script>的请求，观察Dashboard → Passive Scan是否出现Reflected XSS告警
大量401 Unauthorized告警刷屏被动扫描尝试修改Authorization头，但未配置Session Handling规则更新 Token进入Project options → Sessions → Session Handling Rules，添加规则：Check if session is valid→Check response for failure message（如"invalid_token"）→Run macro（调用登录宏刷新 Token）在Proxy → HTTP history中找一条 401 请求，右键Send to Repeater，手动修改Authorization后发送，确认是否仍 401；若仍 401，说明 Token 未自动刷新
GraphQL 查询体中的变量未被识别为插入点Burp 默认不解析 GraphQLvariables字段结构进入Extender → Extensions，安装官方GraphQL Scanner插件（免费）；启用后，在Dashboard → Passive Scan → Options → Insertion Points中勾选Extract from GraphQL variables发送 GraphQL 请求{"query":"query($id:Int!){user(id:$id)}","variables":{"id":123}}，观察被动扫描是否生成IDOR in GraphQL variable 'id'告警
扫描器 CPU 占用持续 95%+自定义插入点正则过于宽泛（如.*）或包含回溯灾难（如(a+)+b）进入Dashboard → Passive Scan → Options → Insertion Points，检查所有自定义规则的正则；用在线工具 regex101.com 测试其性能；替换为原子组(?>...)或限制量词{1,10}修改正则后，重启 Burp，用top命令监控java进程 CPU 使用率，应稳定在 30% 以下

注意：被动扫描的“质量”必须在主动扫描前验证。我的标准流程是：先让目标应用正常运行 10 分钟（模拟用户操作），然后检查Dashboard → Passive Scan的Issues数量和分布。如果 10 分钟内仅产生 <5 条告警，或 >80% 告警集中在Information Leakage类别，说明被动扫描配置有重大缺陷，必须修正后再进行主动扫描。

3. 主动扫描不是“暴力穷举”，而是基于上下文的风险驱动探测

3.1 主动扫描的底层逻辑：从“发请求”到“建模型”

Burp Suite 的主动扫描（Active Scan）常被误解为“自动 Fuzzing 工具”，但它真正的设计哲学是：基于被动扫描构建的上下文模型，对每个插入点执行最小化、最精准的探测序列，以验证其是否构成可利用风险。

其执行流程分为四步：

  1. 目标选择（Target Selection）：从被动扫描的插入点列表中，筛选出符合当前扫描策略的候选点（如仅选String类型、URL query string位置的参数）；
  2. 探测序列生成（Payload Generation）：为每个候选点，按预设顺序加载探测 payload（如先发 SQLi 基础 payload，再发 Blind SQLi 时间延迟 payload，最后发 Error-based payload）；
  3. 响应差异分析（Response Analysis）：对比原始响应与 payload 响应，在 7 个维度上计算差异度：
    • 响应状态码变化（如 200 → 500）
    • 响应长度变化（如 1234 → 12345）
    • 响应时间变化（如 120ms → 3200ms）
    • 响应体文本相似度（Levenshtein 距离）
    • 响应头变化（如新增X-Debug: true）
    • HTML 结构变化（DOM 树节点增减）
    • 错误关键词匹配（如SQL syntax error）
  4. 风险判定（Risk Assessment）：综合以上差异，结合 payload 类型，给出High/Medium/Low/Informational四级风险评级。

关键洞察：主动扫描的准确率，70% 取决于被动扫描提供的插入点质量，20% 取决于 payload 序列的合理性，仅 10% 取决于扫描器自身的算法。这就是为什么跳过被动扫描直接开主动扫描，往往得到一堆“疑似 SQLi”却无法复现的告警——因为插入点本身就不在业务逻辑的关键路径上。

3.2 扫描策略配置：拒绝“全量扫描”，拥抱“精准打击”

Burp 主动扫描策略入口在Dashboard → Active Scan，但核心配置在Project options → Spider和Project options → Scanner。以下是经我实测验证的黄金配置组合：

3.2.1 扫描范围控制：用“路径白名单”替代“域名黑名单”

默认的主动扫描会遍历整个 Scope 域名下的所有路径，但现实中，/api/v1/login和/static/js/app.js的风险等级完全不同。我的做法是：

  • 在Project options → Spider → Scope中，禁用Include all child resources；
  • 手动添加精确路径白名单：
    • https://api.example.com/api/v1/users
    • https://api.example.com/api/v1/orders
    • https://api.example.com/api/v2/products
  • 对每个路径，设置Scan only this folder and its subfolders。

这样，扫描器只会针对这三个业务核心路径发起请求，跳过/docs/、/healthz、/metrics等运维接口。实测某政务系统：全路径扫描耗时 47 分钟，产生 213 条告警（其中 189 条为/healthz的 200 响应误判）；路径白名单扫描耗时 8 分钟，产生 24 条告警，100% 为真实业务接口风险。

3.2.2 插入点类型精筛：只扫“可能被污染”的位置

在Project options → Scanner → Active scanning中，Insertion points设置决定扫描器从哪里发起探测。默认全选，但这是效率杀手。我的推荐组合：

插入点位置推荐状态理由典型场景
URL query string✅ 必开GET 参数最易受污染，且无需构造复杂请求体/api/v1/users?id=123
Request body✅ 必开POST/PUT/PATCH 的 JSON/XML/FormData 是主要攻击面{"name":"test","email":"test@example.com"}
HTTP headers⚠️ 按需开仅开启X-Forwarded-For、User-Agent、Referer等可伪造 Header测试 IP 伪造、UA 注入
Cookies❌ 关闭现代应用 Cookie 多为 HttpOnly 加密，修改即失效session=abc123; csrftoken=def456
Multipart form data✅ 开（仅对文件上传接口）文件名、文件内容、表单字段均可能注入<input type="file" name="avatar">

特别提醒：永远不要开启URL filename。Burp 会尝试在 URL 路径末尾添加.php.bak、.git/config等后缀探测备份文件，这极易触发 WAF 的路径遍历规则，导致 IP 被封禁。真实业务中，99% 的备份文件泄露源于开发人员误传，而非路径猜测。

3.2.3 Payload 序列优化：砍掉 60% 的无效探测

Burp 内置 12 类主动扫描 payload（SQLi、XSS、OS Command、LDAP、XPath 等），每类含 50~200 个具体 payload。全量执行不仅慢，还易被 WAF 拦截。我的裁剪原则是：

  • 按业务技术栈裁剪：
    若后端是 Node.js + MongoDB，关闭Oracle SQL injection、Microsoft SQL Server injection等无关 payload 组；
    若前端是 React + CSR，关闭Stored XSS in HTML context（服务端不渲染 HTML）；
    若 API 全部使用 JWT，关闭CSRF token not validated（JWT 本身无 CSRF 问题）。

  • 按风险等级分层执行：
    在Project options → Scanner → Active scanning → Payloads中，将 payload 分为三级：

    • Level 1（快速验证）：仅 5 个基础 payload（如' OR 1=1--、<img src=x onerror=alert(1)>），用于 10 秒内快速确认是否存在基础注入；
    • Level 2（深度探测）：30 个针对性 payload（如基于time.sleep(5)的 Blind SQLi、基于fetch()的 DOM XSS），用于 Level 1 确认为真后深入验证；
    • Level 3（绕过测试）：10 个 WAF 绕过 payload（如'%20OR%201=1--、<scr<script>ipt>alert(1)</scr<script>ipt>），仅在确认目标有 WAF 时启用。

操作路径：Project options → Scanner → Active scanning → Payloads → Payload generation，点击Edit，删除不需要的 payload 组。实测某社交 APP：全 payload 扫描耗时 32 分钟，Level 1+2 组合仅需 4.5 分钟，检出率无差异（因 Level 3 的绕过 payload 在无 WAF 时全失败）。

3.3 主动扫描的致命误区与实战对策

以下是我在红队演练中总结的 4 个高频致命误区，每个都附带可立即落地的对策：

3.3.1 误区一：“扫描速度越快越好” → 导致 WAF 拦截、请求丢包、漏报飙升

现象：将Threads调至 20，Request per second设为 50，扫描启动 2 分钟后，Burp 日志显示Connection refused，目标服务器返回429 Too Many Requests。

真相：WAF（如 Cloudflare、AWS WAF）的速率限制策略，通常基于IP+User-Agent+Path三元组。Burp 默认 User-Agent 是Mozilla/5.0 (Burp Suite)，极易被识别为扫描器。高并发请求会瞬间触发阈值。

对策：模拟真实用户行为，而非机器压测。

  • 在Project options → Connections → Incoming requests中，设置Maximum number of concurrent requests= 2；
  • 在Project options → Connections → Outgoing requests中，设置Threading→Number of threads= 3；
  • 在Project options → Connections → HTTP中，勾选Use browser user-agent strings，并添加 3 个真实 UA：
    Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Safari/605.1.15 Dalvik/2.1.0 (Linux; U; Android 13; SM-S901B Build/TP1A.220624.014)
  • 在Project options → Scanner → Active scanning中，启用Delay between requests= 800ms（模拟用户思考间隔）。

效果：某电商网站 WAF 误拦截率从 92% 降至 3%，扫描成功率从 17% 提升至 89%。

3.3.2 误区二：“所有告警都要人工复核” → 导致时间浪费、重点遗漏

现象：扫描完成，生成 156 条High级告警，逐条用 Repeater 验证，3 小时后发现 142 条是400 Bad Request或500 Internal Server Error，仅 14 条为真实漏洞。

真相：Burp 的风险评级基于统计学模型，而非 100% 确认。High仅表示“该插入点在多个 payload 下表现出显著响应差异”，不等于“已确认可利用”。

对策：建立三级复核漏斗，聚焦高价值线索。

  1. 第一级（自动过滤）：在Dashboard → Active Scan中，右键告警 →Filter issues，设置：
    • Status≠False positive
    • Severity=HighorCritical
    • Confidence=CertainorFirm
    • Issue detailcontainsresponse time increased by more than 2000ms（时间盲注特征）
  2. 第二级（批量验证）：选中过滤后的告警，右键Send to Intruder，用Sniper模式发送 3 个 payload（' OR 1=1--、' AND SLEEP(5)--、<script>alert(1)</script>），观察响应时间/状态码；
  3. 第三级（手工确认）：仅对 Intruder 返回200且响应时间 >3000ms 的请求，用 Repeater 手工构造 PoC。

实测：156 条告警经三级过滤后，仅剩 7 条需手工验证，平均每人小时产出从 2.3 个漏洞提升至 8.6 个。

3.3.3 误区三：“扫描器能发现所有逻辑漏洞” → 忽略业务语义鸿沟

现象：对/api/v1/transfer?from=1001&to=1002&amount=100扫描，Burp 报告IDOR in 'from' parameter，但实际from是用户自己的账户 ID，无法越权。

真相：Burp 的 IDOR 检测基于“相同请求结构下，修改参数值导致响应变化”，但它无法理解from=1001是当前登录用户的 ID，而from=1002是他人 ID。这需要业务上下文知识。

对策：用自定义插入点 + 业务规则补全语义。

  • 在Dashboard → Active Scan → Options → Insertion Points中，为/api/v1/transfer添加自定义插入点：
    • Location:URL query string
    • Parameter name:to
    • Context:Only when 'from' equals current user ID（此为伪代码，实际需配合 Session Handling）
  • 在Project options → Sessions → Session Handling Rules中，添加规则：
    • Rule action:Set macro→Run macro→Get current user ID from /api/v1/profile
    • Rule action:Add custom header→X-Current-User-ID: {macro_result}

这样，扫描器在探测to参数时，会确保from始终为当前用户 ID，从而精准定位真正的越权点。该方案已在 3 个金融项目中验证有效。

3.3.4 误区四：“一次扫描定终身” → 忽略动态业务变更

现象：月初扫描报告无高危漏洞，月底上线新功能后，未重新扫描，导致新接口POST /api/v2/ai/chat的 prompt 注入漏洞未被发现。

真相：API 接口是活的，不是静态资产。新功能、新参数、新认证方式都会引入新攻击面。

对策：建立“扫描即代码（Scan-as-Code）”流水线。

  • 将 Burp 扫描配置导出为burp-config.json（路径：Project options → Import / export project options）；
  • 在 CI/CD 流程中，用burpsuite-pro --project-file=project.burp --scan-target=https://staging.example.com/api/v2/ai/chat --config-file=burp-config.json命令行启动扫描；
  • 扫描结果输出为scan-report.xml，用脚本解析，若severity=High数量 >0，则阻断发布。

我们为某 SaaS 客户实施后，新功能上线漏洞平均发现时间从 17 天缩短至 22 分钟。

4. 自定义插入点：让扫描器从“工具”升级为“业务伙伴”

4.1 为什么默认插入点永远不够用？

Burp Suite 的默认插入点提取逻辑，是基于 RFC 标准和常见 Web 框架设计的。它能完美处理：

  • GET /search?q=test&sort=price
  • POST /login application/json {"username":"a","password":"b"}
  • GET /api/users/123 Accept: application/json

但它对以下现代 API 架构束手无策：

架构类型默认行为业务影响示例
GraphQL将整个{"query":"...","variables":{"id":123}}当作一个 Body 字符串无法识别variables.id为独立插入点，漏扫 IDOR{"query":"query($id:Int!){user(id:$id)}","variables":{"id":123}}
gRPC-Web将 Protobuf 序列化后的二进制 Body 当作不可解析字节流完全无法提取字段，主动扫描失效0a 03 75 73 65 12 03 31 32 33（name="use", id="123"）
WebSocket仅捕获握手请求（HTTP Upgrade），忽略后续帧无法扫描实时通信中的命令注入{"type":"command","payload":"ls -la"}
JWT 透传将Authorization: Bearer xxx的 Base64 解码后全文扫描在加密部分插入 payload 导致 JWT 无效，产生海量 401eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

根本原因在于：默认插入点是“语法层面”的，而业务安全是“语义层面”的。variables.id的语义是“用户查询的目标 ID”，gRPC 的 field_2的语义是“操作指令”，WebSocket 帧中的 payload的语义是“执行命令”。要让扫描器理解这些，必须用自定义插入点为其注入业务知识。

4.2 自定义插入点的三种实现方式：从简单到深度

Burp 提供三种自定义插入点途径，适用不同复杂度场景：

4.2.1 方式一：GUI 白名单（适合 REST/GraphQL）

这是最轻量、最安全的方式，适用于 80% 的现代 API。

操作路径：Dashboard → Active Scan → Options → Insertion Points → Add。

关键字段详解：

  • Location: 插入点所在位置（URL query string、Request body、HTTP headers）；
  • Parameter name: 参数名（支持正则，如^id$|^user_id$）；
  • Parameter type: 数据类型（String、Integer、Boolean），影响 payload 选择（Integer 类型不会发 XSS payload）；
  • Context: 作用域限定（All requests、Only requests to specific URL、Only requests matching regex）；
  • Enabled: 是否启用。

实战案例：为 GraphQL API 添加variables.id插入点。

  • Location:Request body
  • Parameter name:variables\.(id|userId|account_id)
  • Parameter type:Integer
  • Context:Only requests to https://api.example.com/graphql
  • Enabled: ✅

Burp 会自动解析 JSON Body，定位到variables对象下的id字段，并将其作为独立插入点。无需写代码，5 分钟内完成。

4.2.2 方式二：扩展插件（适合 gRPC/WebSocket）

当 GUI 无法满足时，必须用 Java/Python 扩展。Burp 官方提供IBurpExtender和IExtensionHelpers接口。

以 gRPC-Web 为例，其请求体是 Protobuf 序列化后的二进制，需：

  1. 解析 Protobuf Schema（.proto文件）；
  2. 识别字段类型（string、int32、repeated）；
  3. 对string字段注入 XSS payload，对int32字段注入 SQLi payload。

我开发的gRPC-Scanner插件核心逻辑：

public class CustomInsertionPoint implements IScannerInsertionPoint { private final IHttpRequestResponse baseRequestResponse; private final byte[] originalRequest; private final List<String> stringFields; // 从 .proto 解析出的 string 字段名列表 @Override public String getInsertionPointName() { return "gRPC String Field"; } @Override public List<PayloadData> getPayloads() { List<PayloadData> payloads = new ArrayList<>(); for (String field : stringFields) { payloads.add(new PayloadData("'" + field + "' injected")); payloads.add(new PayloadData("<script>alert(1)</script>")); } return payloads; } @Override public byte[] buildRequest(byte[] payload) { // 1. 反序列化原始 protobuf // 2.
http://www.jsqmd.com/news/875066/

相关文章：

  • 信息论视角下的模型压缩与贝叶斯非参数建模理论边界分析
  • 卷积神经网络频谱分析与LFA-SVD优化方法
  • 当国产欧拉系统遇上VMware ESXi：一次非官方兼容环境的部署实践与思考
  • Pico Neo3 Unity XR开发实战：从黑屏到手柄响应的完整链路
  • LeetCode 724：寻找数组的中心下标 | 前缀和的平衡点
  • [智能体-42]：深度解读：Python 免编译 + 动态执行，支撑智能体落地大模型决策
  • Juno平台TF-A安全调试功能恢复与配置指南
  • 深入解析：浏览器如何“咀嚼”HTML头部——从字节流到渲染树的完整链路与性能优化实战
  • 鸿蒙electron跨端框架PC墨案写作实战：把 Markdown 正文区做成桌面写作的中心
  • LeetCode 1248：统计「优美子数组」 | 前缀和与奇数计数
  • 基于FeFET的动态可重构FPGA：实现亚纳秒级上下文切换的硬件加速新架构
  • 司法AI风险评估：性能与公平性的技术悖论与工程实践
  • 反事实推理：用因果视角评估与缓解AI模型偏见
  • 基于LLM与多智能体的微服务自治运维系统设计与实践
  • 边缘计算融合触觉互联网与数字孪生：构建超低延迟人机交互框架
  • 稀疏结式与动作矩阵：多项式方程组求解的几何代数化方法
  • 鸿蒙electron跨端框架PC片段匣实战：给常用代码片段一个能搜索、复制和整理的桌面仓
  • FPGA加速机器学习在粒子物理触发系统中的应用与实战
  • 计算机视觉模型失败模式自动化发现与自然语言描述技术详解
  • Unity PBR材质工作流：800个开箱即用的工业级材质球
  • SMGI框架：通用人工智能的结构元模型与实现路径解析
  • 前缀和与差分 | 数组区间查询的利器
  • TabularMark表格数据水印：原理、实现与参数调优实战
  • LeetCode 560：和为 K 的子数组 | 前缀和与哈希表
  • 除了Easy App Locker，还有哪些Mac应用加锁方案？横向对比与避坑指南
  • Claude写代码到底靠不靠谱？实测37个真实开发任务后，我删掉了80%的Copilot订阅
  • 边缘计算中LLM部署的挑战与CLONE系统优化方案
  • 2026年比较好的新疆低压电力电缆/新疆高压电力电缆定制加工厂家推荐 - 品牌宣传支持者
  • AI+PDCA循环：构建医院后勤韧性系统的实践与思考
  • Cortex-R82集成ELA-600调试模块的信号连接问题解析