Burp Suite 生产落地案例

五、生产落地案例

说明：以下案例均为在自有系统或已获书面授权的目标上开展的工作，流程与结论仅作方法参考，不构成对任何具体系统的评估结论。

案例一：企业自建系统的上线前安全自查。背景是一个企业内部管理系统计划上线，团队在预发布环境做一次安全自查，授权文件由系统所有方签发，范围限定为预发布域名与其 API 路径，时间为上线前一周。做法是在预发布环境部署一份与生产同配置的应用，用 Burp Suite 把浏览器流量接入代理，先手工走一遍全部业务功能，把请求记录进 HTTP history，再针对权限相关的接口做重点验证。关键配置上，范围严格锁定预发布域名，Intruder 的并发设为 1、请求间隔设为 1 秒，Scanner 的主动扫描只在明确允许的路径上开启。效果是发现了若干越权访问与会话管理方面的问题，全部在开发阶段修复，避免了上线后暴露。踩到的坑有两个：一是最初把预发布环境的 CDN 域名也纳入了范围，导致扫描在 CDN 上消耗了大量时间且毫无意义，后来通过 exclude 规则排除；二是初期测试直接在浏览器里切换账号，导致会话状态混乱、结论不可靠，后来改为用 Repeater 精确控制请求头中的会话标识，结论才可复现。

案例二：移动应用接口的授权测试。背景是一个自有 App 的后端接口需要验证访问控制强度，授权范围限定为接口域名与其认证相关路径。做法是把手机与测试机接入同一网络，让手机代理指向 Burp 的监听端口，安装 CA 证书后抓取 App 与后端的全部交互，重点分析接口是否在服务端做了权限校验，而不是只依赖客户端的界面隐藏。关键配置上，代理只监听回环地址、通过额外端口给手机接入，范围限定为接口域名，且明确不在生产用户数据上做任何写操作。效果是发现了若干接口在服务端缺少权限校验的问题，通过改为服务端强制校验修复。踩到的坑有三个：一是 App 使用了证书固定，抓包直接失败，在向授权方书面说明并得到同意后，使用开发调试版本进行测试；二是初期测试触碰到了真实用户数据，虽然有授权但在报告流程上处理不当，后来把"先造测试账号、只在测试账号上验证"写进了测试规范；三是长时间抓包导致内存占用很高，需要定期清理历史记录并分卷保存工程文件。

这两个案例给出的经验是：Burp Suite 用得是否专业，不取决于会不会用 Intruder，而取决于有没有把授权、范围、留痕和报告这四件事做成流程。一份合格的测试报告应当包含：授权依据、测试范围与时间、使用的工具与方法、发现的问题（含复现步骤与影响评估）、未完成的部分与原因、以及修复建议。凡是超出授权范围能做的事，都应当先停下来沟通，而不是先做了再解释。