安全测试-01-Web业务测试里如何用BurpSuite找出高频安全问题

发表于 分类于 本文字数： 3.4k 阅读时长 ≈ 12 分钟
Burp Suite 在业务测试里最有价值的地方，不是扫一遍漏洞列表，而是帮助测试把请求、鉴权、参数、会话和响应行为放回真实业务流程里看清楚。真正高频的问题，往往出现在登录、修改、导出、审批、支付回调这类关键路径。

一提安全测试，第一反应就是：

  • 这个是不是要专业安全同学做
  • 我们没有时间跑完整套渗透流程
  • Burp 装了，但也只是偶尔抓个包

所以最后常见的结果是：

  • 功能测完了，请求也抓到了
  • 但关键接口有没有越权、有没有参数篡改空间、会话是不是稳，其实没人认真看过

这也是需要强调的是 Burp Suite 在业务测试里非常实用的原因。

它真正的价值，不是把测试同学瞬间变成渗透工程师，而是让你在做真实业务测试时，能把下面这些问题更快看清楚：

  • 请求到底长什么样
  • 哪些字段是前端传上来的，哪些字段其实不该相信
  • 登录态、Token、Cookie 和签名是怎么流动的
  • 关键动作有没有被二次校验
  • 同一个动作换用户、换参数、换顺序之后，系统会不会露出不该露的口子

这篇文章不讲大而空的漏洞百科，只讲一个更实用的问题：

Web 业务测试里，Burp Suite 到底该怎么用，才能更高概率找出高频安全问题。

一、Burp 在业务测试里最适合切入哪些场景

如果只是随手抓几个普通列表接口，Burp 的价值其实不大。
它最适合切进去的，是下面这些“动作一旦出问题，影响就很大”的路径：

  • 登录、注册、找回密码
  • 用户资料修改、手机号修改、邮箱绑定
  • 权限切换、角色分配、审批流
  • 订单提交、支付、退款、优惠券核销
  • 文件上传、下载、导出
  • 后台管理接口
  • 回调接口、Webhook、内部管理接口

这些场景之所以值得优先看，不是因为“它们更像安全测试”，而是因为它们都满足一个共同点：

它们背后往往存在身份、状态、金额、资源、权限中的至少一种关键约束。

只要关键约束存在，就有必要问几个问题：

  • 当前动作是不是只靠前端控住的
  • 服务端有没有重新校验
  • 一个普通用户能不能借改参数把本来不该做的动作做掉
  • 一个请求重复打、多打、换顺序打，系统会不会失控

二、更常用的 Burp 使用顺序：先过业务，再补安全视角

Burp 最容易被用偏的地方，是一上来就把自己带到“扫漏洞”的节奏里。
更常用的方式是：

1. 先正常走一遍业务流程

不要急着改包，先让业务流程完整跑通。

例如做“普通员工提交报销，主管审批，财务打款”这类流程时，先完成：

  • 登录
  • 创建单据
  • 提交审批
  • 审批通过
  • 打款

这一步的目的不是功能回归，而是为了拿到一条完整的请求链。

你需要先知道：

  • 哪几个请求是真正关键动作
  • 哪些请求只是页面渲染
  • 哪些字段在不同步骤之间被复用
  • 哪个 ID 是业务主键
  • 哪个字段看起来像权限、金额、状态、归属人

2. 再把关键请求送到 Repeater 单独验证

我很少在 Proxy 里反复手改，因为一旦链路稍微复杂，就很容易混乱。
把关键请求送到 Repeater 后，最适合做几类动作：

  • 改用户身份再重放
  • 改资源 ID 再重放
  • 改金额、折扣、状态字段再重放
  • 去掉部分头或 Token 再重放
  • 重复提交同一个请求

这一步最关键的不是“改得多花”，而是每次只验证一个假设。

例如：

  • 把 userId=1001 改成 userId=1002
  • 把 orderId 换成另一个用户的订单
  • 把 role=user 直接改成 admin
  • 把 amount=100 改成 1

这样你才知道系统究竟信了什么。

3. 最后再回到业务上下文判断风险

很多测试在 Burp 里看到“改包成功”就直接判高危，这也不严谨。
还得回到业务里问：

  • 这个动作是不是最终真的生效了
  • 生效后影响的是谁
  • 有没有审计、补偿或二次确认挡住后果
  • 这是演示环境的宽松逻辑，还是生产链路同样如此

所以 Burp 不是结论机，它只是把系统真实信任边界暴露出来。

三、最常检查的 5 类高频问题

如果是时间有限的业务测试，最适合优先看的是下面 5 类。

1. 越权与未授权访问

这是业务测试里最常见、也最值得先看的问题。

重点动作包括：

  • 用 A 用户登录，抓取“查看详情 / 修改 / 删除 / 审批”接口
  • 替换成 B 用户的资源 ID
  • 观察是否还能查到、改到、删到

重点不是只看 HTTP 状态码，而是看结果是不是“真的越过去了”。

例如：

  • 返回 200
  • 页面上也拿到了别人的详情
  • 审批结果也真的落库了

这才叫问题成立。

2. 参数篡改

很多系统表面上有前端限制，但后端其实直接信了传参。

高频字段包括：

  • 金额
  • 数量
  • 折扣
  • 角色
  • 状态
  • 审批结果
  • 文件路径
  • 导出范围

这里会特别留意两类接口：

  • “页面不可改，但包里能改”的字段
  • “看起来像展示字段，实际参与业务判定”的字段

3. 会话与身份状态问题

很多问题不是接口本身危险，而是登录态管理不稳。

例如：

  • 退出登录后旧 Token 还能不能继续用
  • 密码修改后旧会话会不会失效
  • 多端登录后，敏感动作是不是需要重新校验
  • Token 过期、刷新、续期逻辑是不是一致

这些问题非常适合用 Burp 重放验证，因为你可以固定住一份旧请求，反复验证状态变化后的行为。

4. 重放与重复提交

支付、审批、提交、发送验证码、批量导出，这些动作如果能被无约束重复触发，风险通常不小。

Burp Repeater 在这里很好用，因为它能帮你复用完全相同的请求。

重点观察：

  • 是否存在幂等校验
  • 是否需要一次性 token
  • 是否依赖时间窗或 nonce
  • 重复提交后数据库状态是否异常

5. 文件上传与下载边界

文件类接口非常适合用 Burp 细看，因为浏览器页面通常把很多细节藏起来了。

上传时会关注：

  • 后缀校验是不是只在前端做
  • Content-Type 改掉后服务端是否仍然接收
  • 文件名、路径、扩展名是否会影响落盘位置

下载和导出时会关注：

  • 文件 ID 是否可以遍历
  • 导出范围是否只靠前端限制
  • 导出任务是否能看到别人的数据

四、一套更实用的最小执行骨架

如果你是把 Burp 当成业务测试里的安全补强工具，而不是独立渗透平台，更推荐用下面这套最小骨架。

1. 先准备两个账号和一组关键业务数据

最少准备：

  • 普通账号 A
  • 普通账号 B
  • 一组 A 自己的资源
  • 一组 B 自己的资源
  • 一个权限更高的管理账号

没有对照账号，很多越权问题根本测不出来。

2. 记录关键请求清单

更稳的做法通常是先记一张表：

请求名称 方法 关键参数 业务含义 风险点
查询详情 GET orderId 查看订单详情 是否可遍历他人数据
修改资料 POST userId 修改用户信息 是否可信前端传参
审批通过 POST taskId result 审批动作 是否可越权审批
导出报表 POST deptId range 导出数据 是否能导出超权限范围

这张表会直接决定你后面要往 Repeater 送哪些请求。

3. 每次只做一类变更

例如按下面这个顺序测：

  1. 换资源 ID
  2. 换用户身份
  3. 改金额或状态
  4. 去掉或替换鉴权头
  5. 重放多次

不要一次把 4 个字段都改掉，不然后面根本解释不清楚。

4. 每次改包都补结果确认

不要只看响应体。

同时确认：

  • 页面是否真的变化
  • 数据库或列表页是否真的生效
  • 审计日志或操作记录是否生成
  • 下游动作有没有被触发

否则你很容易把“接口回包不严谨”误判成“真实漏洞”。

五、Burp 里最常用的几个功能，不需要太多

真正高频能用起来的，通常也就这些：

  • Proxy
    用来抓完整业务链路，定位关键请求。
  • HTTP history
    用来回看一条业务流程里的前后请求关系。
  • Repeater
    用来稳定地复现、改包、对比不同参数结果。
  • Comparer
    用来比较改包前后的响应差异。

如果只是业务测试切安全，不需要一开始把 Burp 全家桶都学完。
先把这几个能力用稳，收益就很明显了。

六、最容易踩的几个坑

1. 抓到了请求，但不知道哪一个才是关键动作

这说明前面的业务链路没有先走明白。
解决方法不是继续乱试，而是先把完整流程按“展示请求 / 查询请求 / 真正写操作请求”分开。

2. 只看响应码，不看业务结果

有些接口返回 200，但业务其实没生效。
也有些接口返回看起来像失败，但实际上脏数据已经落下去了。

3. 只改一个字段名，却没理解它背后的业务约束

比如把 deptId 改成功了，不代表只是一个参数篡改问题，它背后可能是整套数据权限模型没兜住。

4. 把测试环境的宽松配置当成正式漏洞

例如测试环境关闭了验证码、简化了签名、放开了白名单。
这种情况要单独标注，否则问题优先级会被误判。

七、真实案例：审批接口为什么功能没问题，安全上却能出事

场景

一个内部审批系统里，普通员工可以提交申请，主管可以审批。
功能测试时，流程一切正常：

  • 员工提交
  • 主管登录
  • 点击通过
  • 页面显示审批成功

看上去完全没问题。

执行

我在主管账号审批时，用 Burp 抓到了审批请求，然后做了两步验证：

  1. 把主管账号登出，换成普通员工账号
  2. 用普通员工账号的登录态，重放主管的审批请求，只替换 Cookie

请求里的核心参数大概是：

1
2
3
4
5
6
7
8
POST /api/approval/pass HTTP/1.1
Cookie: session=xxx
Content-Type: application/json

{
  "taskId": "A20210318017",
  "result": "pass"
}

现象

接口返回 200，响应体显示“操作成功”。
最关键的是，刷新列表后，这条申请真的已经变成“审批通过”。

这说明问题不是提示文案不严谨，而是业务动作真的落库了。

排查

我继续往下看了几层：

  • 前端页面上，普通员工确实看不到“审批通过”按钮
  • 但后端接口只校验了 taskId 是否存在，没有校验当前用户是否为该任务审批人
  • 操作日志里记录了执行人，却没有在写操作前做权限判断

也就是说，这个系统把“是否显示按钮”当成了“是否有权限操作”。

修复

最后给研发的修复建议不是一句“加权限校验”就结束，而是明确到三层：

  1. 审批接口必须基于当前登录用户重新校验审批权限
  2. 审批任务和审批人关系必须在服务端校验，不能相信前端传参
  3. 增加一条自动化回归用例：
  • 普通员工登录
  • 直接重放审批请求
  • 预期返回无权限
  • 审批状态不能变化

这类问题就是 Burp 在业务测试里最典型的价值：

功能流程没问题，不代表安全约束真的成立。

八、我对 Burp 的一个实际建议

不要把 Burp 当成“有空才补一下的安全工具”，它更适合被当成业务测试里的一个放大镜。

特别是在下面这些场景里：

  • 新系统第一次上线前
  • 权限模型刚改过
  • 审批、支付、导出、管理后台这类高风险模块上线前
  • 研发说“后端一定校验了”的时候

哪怕你只多做下面这几步，收益都很高：

  • 抓关键请求
  • 换账号重放
  • 换资源 ID
  • 改关键参数
  • 看最终业务结果

这已经足够筛出一批真正高频、真正有业务影响的问题。

九、写在最后

Burp 在业务测试里的意义，不是让测试把自己变成漏洞扫描器，而是让测试更接近系统真实信任边界。

真正值得关注的问题，通常不是特别炫的漏洞名词，而是这些很朴素的失守：

  • 不该改的参数被改成功了
  • 不该看的数据被看到了
  • 不该做的动作被做成了
  • 不该重复的请求被重复生效了

如果把这类高频问题先拦住，很多系统的安全底线就已经提升了一大截。