5.1 Extender与扩展API

5.1 Extender与扩展API

本节摘要：扩展模块是工具的开放接口：它把代理、扫描、站点地图等核心组件的事件与数据暴露出来，插件按事件挂载、按接口读写。本节讲清挂载点模型、最小插件的构成，以及"写一个"之前要想清楚的成本账。

扩展点在哪里

上一章末尾的判断题——哪些活交给机器——先要弄清机器在哪些位置可以被插手。扩展的挂载模型围绕请求的生命周期：请求进入代理时、转发前、响应返回时、进入历史时、扫描审计时，都是约定好的事件时机。插件向内核登记"这个事件发生时调用我"，就能在那个时机看到（或改写）消息。此外还有界面扩展（往面板加标签页）与数据扩展（往问题条目里加自定义字段），覆盖"处理流量"之外的需求。

按 4.3 节的口径补全判断链：能用声明式规则表达的不写代码，必须写代码时优先扩展现有能力而不是另起炉灶。扩展的真实成本不在代码量，而在维护——接口版本演进、内部数据结构变化，插件都要跟着走。企业环境里跑着一个三年没动过的老插件，是常见的事故源。

最小插件长什么样

下面用一个"流量标注器"说明最小构成：凡响应头里带某个内部标记的请求，在历史里自动加备注。代码以 Java 风格示意，Python 路线逻辑相同，类与接口名以所用版本的开发接口文档为准。

public class TagExtension implements IBurpExtender, IHttpListener {
    private IExtensionHelpers helpers;

    @Override
    public void registerExtenderCallbacks(IBurpExtenderCallbacks callbacks) {
        this.helpers = callbacks.getHelpers();
        callbacks.setExtensionName("Lab Tagger");
        callbacks.registerHttpListener(this);
    }

    @Override
    public void processHttpMessage(int toolFlag, boolean messageIsRequest, IHttpRequestResponse message) {
        if (messageIsRequest) { return; }
        IResponseInfo info = helpers.analyzeResponse(message.getResponse());
        for (String header : info.getHeaders()) {
            if (header.toLowerCase().startsWith("x-lab-marker")) {
                message.setComment("内部标记请求");
            }
        }
    }
}
​

三个构件值得指出。注册环节声明了"我要挂在 HTTP 事件上"；辅助接口封装了消息解析，插件代码几乎不手工拆字节流；处理函数里的方向判断是新手最容易漏的——不区分请求与响应方向，逻辑会在两个方向上各跑一遍。加载与调试都在扩展面板完成：载入编译产物，输出面板看日志，改一处重载一次。建议第一个插件就做这种只读观察型：不碰流量内容，出错也不影响测试主线。

选型与审查的落地做法

商店插件的审查按上一章分层图执行，这里补具体的动作清单。装前看三样：作者与更新时间、要求的权限范围描述、用户反馈里的异常报告。装后核两样：输出面板有没有可疑的外联日志、历史请求有没有被静默改写的痕迹（对比同一请求在无插件环境的行为）。涉及核心业务数据的机器，插件保持最小集，用不到的季度性清理——供应链风险的管理颗粒度就到这个层面。

⚠️ 插件能看见你全部流量，包括测试凭证。这是"审查三问"必须走完的原因：谁写的、还在维护吗、它要求看到什么数据。

开发路线与调试环境

从零到第一个可用插件的路线值得铺一遍。语言选择：Java 路线性能与类型安全最好，需要工具链编译；Python 路线（经内嵌的解释器加载脚本）迭代最快，改完即载，适合逻辑探索；两者可以混用——探索期用脚本，成型后翻成 Java。调试环境：日志是主要手段，把关键路径都打日志，输出面板看信息；再进阶的做法是让插件暴露一个状态面板，运行时可视。版本升级的维护点集中在接口变化上，官方的接口变更记录在每次升级后值得通读一遍——半小时的阅读换来插件寿命的延长。

值得写的第一批插件，建议从这些类型里挑：协议解析类（把私有格式转成可读形态显示在消息面板）、批量操作类（对选中请求做统一处理，如批量加标记）、结果加工类（把扫描条目按团队口径重分级）。每类都围绕一个真实痛点——为写而写的插件是练习，为省时而写的插件才是资产。

插件行为的验证方法

审查别人的插件与验证自己的插件用同一套方法。隔离验证：新插件先在非关键环境加载，观察输出面板的日志有没有异常外联、报错循环。行为对照：同一组请求在插件加载前后各过一遍，对比历史里的请求响应有没有非预期差异——尤其关注出站连接。权限复盘：对照插件声称的功能，思考它实际需要的最小数据范围，明显超出的要有合理解释。这套方法三分钟一轮，把它变成装任何新插件前的固定动作，供应链风险就从"听天由命"变成了"可控流程"。

高频疑问

问：插件能把测试数据传到外部吗？
答：技术上完全可能，这正是审查的原因。凡涉及向插件作者控制的服务发送数据的插件，说明里必须有明确披露，没有披露的一票否决。评估环境对数据出境有要求的，装机清单要在委托方处备案。

问：脚本语言路线的性能上限够用吗？
答：高频处理（每个请求都要过的逻辑）建议 Java；低频处理（人工触发、批量后处理）脚本毫无压力。按调用频率选语言，而不是按熟悉度——当然，原型期永远脚本优先。

问：有没有必要给插件做图形界面？
答：先做无界面的最小版本跑通逻辑，界面的价值在验证之后才成立。很多插件的生命周期里，一个配置文件加清晰日志就够了，界面是锦上添花不是必需品。

与后续章节的接口

写扩展是手段，落点仍是流程效率。下一节把镜头拉远：从单个插件到整条自动化流水线，给出"哪些环节值得自动化"的三个判据，并用最小流水线演示判据怎么用。

本节要点回顾

• 模型：按事件挂载，请求生命周期各环节都可插手，界面与数据也能扩展。
• 成本：代码量小头，维护大头；先声明式规则、再扩展、别重造轮子。
• 第一课：从只读观察型插件起步，方向判断与辅助接口是最小构成的两根柱子。
• 审查：装前看来源与权限，装后核对行为，最小集原则常年有效。