Manifest V3 实战：从补天网站逆向到 Chrome 扩展开发全记录

Manifest V3 实战：从补天网站逆向到 Chrome 扩展开发全记录

本文将完整记录如何从零逆向补天漏洞赏金平台的 API，并基于 Manifest V3 开发一款实用的 Chrome 扩展------补天SRC助手。涵盖接口抓包分析、MV3 架构设计、Content Script 双 World 通信、智能推荐算法等核心环节，附完整源码。

---

一、为什么要做这个扩展？

补天（butian.net）是国内主流的漏洞赏金平台，白帽子们每天都要在上面浏览 SRC 列表、比较奖金范围、查看新入驻企业。但原版网站存在几个痛点：没有跨维度的排序筛选，没有"性价比"维度的推荐，每次都要打开完整页面才能获取信息。我希望做一个浏览器扩展，在工具栏弹窗里一键聚合所有关键数据，同时顺带记录自己在补天上的操作轨迹，方便复盘报名流程。

这个需求本身不复杂，但在 Manifest V3 的限制下，每一步都踩了不少坑。下面从逆向分析开始，一步步还原整个开发过程。

---

二、逆向补天 API：抓包与接口分析

2.1 打开 DevTools，观察网络请求

打开 https://www.butian.net/Reward/plan（奖励计划页面），在 Network 面板中筛选 XHR 请求，能看到几个关键接口：

第一个是 平台统计数据接口 ，地址是 GET /Rank/getNumbers?ajax=1，返回结构如下：

{
  "status": 1,
  "data": {
    "loo": 358921,
    "reward": 289000000,
    "whitehat": 52130,
    "company": 1247
  }
}

字段含义一目了然：累计漏洞数、奖励总额（单位：元）、白帽子数量、入驻企业数。注意 ajax=1 这个查询参数，补天用它来区分页面请求和 AJAX 数据请求。

第二个是 奖励企业列表 ，地址是 POST /Reward/corps，请求体是 name=&sort=2，表示不按名称筛选、按默认排序。返回一个 data.list 数组，每个元素包含 company_id、company_name、logo、max_reward、min_reward、service_status、change_time、introduce 等字段。

第三个是 新入驻企业列表 ，地址是 POST /Reward/pub，请求体是 name=&p=1。返回结构类似，但字段稍有不同，logo 字段叫 avatar。

2.2 请求特征分析

观察请求头，有几个关键点。所有 API 请求都带有 X-Requested-With: XMLHttpRequest 头，这是补天后端判断是否为 AJAX 请求的依据。POST 请求的 Content-Type 是 application/x-www-form-urlencoded，不是 JSON。最重要的是，这些接口依赖 Cookie 中的 Session 信息来判断登录状态------虽然上述三个接口不需要登录也能访问，但后续如果要做报名等操作，Session 是必须的。

这就引出了 MV3 架构中最核心的设计决策：如何在扩展中发起带正确 Cookie 的请求？

---

三、Manifest V3 的困境与架构设计

3.1 MV3 vs MV2：为什么不能直接在 Background 里 fetch？

在 Manifest V2 时代，Background Page 是一个持久化的页面环境，可以直接发起 fetch 请求，配合 webRequest API 修改请求头，甚至注入 Cookie。但在 MV3 中，Background 被替换为 Service Worker，它运行在独立的上下文中，不携带任何网站的 Cookie。

这意味着在 Service Worker 里直接请求 https://www.butian.net/Rank/getNumbers?ajax=1，拿到的要么是未登录状态的数据，要么直接被后端拒绝。同时 MV3 移除了 webRequestBlocking 能力（除了企业策略部署的扩展），无法在请求级别动态注入 Cookie。

3.2 架构方案：Content Script 代理模式

最终采用的方案是让 Content Script 作为 API 代理。思路如下：

Popup (前端 UI)
    ↓ chrome.runtime.sendMessage
Service Worker (调度中心/缓存层)
    ↓ chrome.tabs.sendMessage
Content Script (运行在 butian.net 页面上下文)
    ↓ fetch (same-origin, 自动携带 Cookie)
补天 API 服务器

Content Script 注入到 https://www.butian.net/* 页面中，它执行的 fetch 请求天然属于同源请求，浏览器会自动附加该域名下的所有 Cookie。Service Worker 负责调度和缓存，Popup 只负责 UI 渲染。这种三层架构在 MV3 中非常常见，也是目前绕过 Cookie 限制的标准做法。

但这里有一个前提条件：必须有一个打开着的补天标签页。如果用户没有打开补天网站怎么办？我在 Service Worker 中加入了自动创建后台标签页的逻辑，这个后面详细展开。

3.3 manifest.json 配置详解

{
  "manifest_version": 3,
  "name": "补天SRC助手",
  "version": "1.0.0",
  "permissions": ["storage", "tabs"],
  "host_permissions": [
    "https://www.butian.net/*",
    "https://oss-yg-cztt.yun.qianxin.com/*"
  ],
  "content_scripts": [
    {
      "matches": ["https://www.butian.net/*"],
      "js": ["content/api-bridge.js"],
      "run_at": "document_start"
    },
    {
      "matches": ["https://www.butian.net/*"],
      "js": ["content/page-tracker.js"],
      "run_at": "document_start",
      "world": "MAIN"
    }
  ],
  "background": {
    "service_worker": "background/service-worker.js"
  },
  "action": {
    "default_popup": "popup/popup.html"
  }
}

几个值得注意的配置：

permissions 只申请了 storage 和 tabs 。storage 用于本地缓存，tabs 用于查询和创建标签页。没有申请 cookies 或 webRequest，因为我们根本不需要------Cookie 由 Content Script 的同源 fetch 自动处理。

两个 Content Script 使用了不同的 world 。api-bridge.js 运行在默认的 ISOLATED world（隔离环境），它可以与 Service Worker 通过 chrome.runtime 通信。page-tracker.js 运行在 MAIN world（页面上下文），它能拦截页面原生的 XMLHttpRequest、fetch、pushState 等方法。这是 MV3 引入的一个非常强大的特性，后面会详细讲解。

host_permissions 包含了补天的 CDN 域名 。企业 logo 图片托管在 oss-yg-cztt.yun.qianxin.com 上，需要这个权限才能在扩展中正常加载。

---

四、Service Worker：调度中心与缓存层

4.1 缓存设计

Service Worker 在 MV3 中有一个重要特性：它不是持久化运行的。空闲一段时间后会被浏览器终止，下次收到消息时重新启动。这意味着内存中的变量不可靠，必须用持久化存储来做缓存。

我选择了 chrome.storage.local，配合一个简单的 TTL 机制：

const CACHE_TTL = 5 * 60 * 1000; // 5分钟

async function getCachedData(key) {
  return new Promise((resolve) => {
    chrome.storage.local.get([key, `${key}_ts`], (result) => {
      const data = result[key];
      const ts = result[`${key}_ts`];
      if (data && ts && Date.now() - ts < CACHE_TTL) {
        resolve(data);
      } else {
        resolve(null);
      }
    });
  });
}

async function setCachedData(key, data) {
  return new Promise((resolve) => {
    chrome.storage.local.set(
      { [key]: data, [`${key}_ts`]: Date.now() },
      resolve
    );
  });
}

每次读取时检查时间戳，超过 5 分钟就视为过期。这比使用 chrome.alarms 定时清理要简单得多，而且对于这种信息聚合类场景，5 分钟的缓存足够了。

4.2 自动寻找或创建补天标签页

这是 Service Worker 中最关键的一段逻辑。当 Popup 请求数据时，我们需要找到一个运行着补天页面的标签页来执行 API 请求：

async function findButianTab() {
  const tabs = await chrome.tabs.query({ url: 'https://www.butian.net/*' });
  return tabs.length > 0 ? tabs[0] : null;
}

async function ensureButianTab() {
  let tab = await findButianTab();
  if (tab) return tab;

  // 没有打开的补天标签页，在后台创建一个
  tab = await chrome.tabs.create({
    url: 'https://www.butian.net/Reward/plan',
    active: false,
  });

  // 等待页面加载完成，Content Script 注入后才能通信
  await new Promise((resolve) => {
    const listener = (tabId, info) => {
      if (tabId === tab.id && info.status === 'complete') {
        chrome.tabs.onUpdated.removeListener(listener);
        resolve();
      }
    };
    chrome.tabs.onUpdated.addListener(listener);
    setTimeout(() => {
      chrome.tabs.onUpdated.removeListener(listener);
      resolve();
    }, 10000);
  });

  return tab;
}

active: false 确保新标签页在后台打开，不会打断用户当前的工作。10 秒的超时保护避免因网络问题导致 Promise 永远挂起。

4.3 失败重试机制

Content Script 有一个容易被忽略的问题：当扩展重新加载（开发时常见）或更新后，已打开页面中注入的 Content Script 会失效 ，因为它们绑定的是旧的扩展实例。此时 chrome.tabs.sendMessage 会报错 "Could not establish connection"。

解决方案是在首次通信失败时，刷新标签页后重试：

async function fetchViaContentScript(endpoint, method, data, retry = true) {
  const tab = await ensureButianTab();
  const url = endpoint.startsWith('http') ? endpoint : `${API_BASE}${endpoint}`;

  try {
    return await sendToTab(tab.id, {
      type: 'API_REQUEST', url, method: method || 'GET', data
    });
  } catch (err) {
    if (retry) {
      await chrome.tabs.reload(tab.id);
      await waitForTabLoad(tab.id);
      return fetchViaContentScript(endpoint, method, data, false);
    }
    throw err;
  }
}

retry 参数确保最多重试一次，避免无限循环。

---

五、Content Script 双 World 架构

这是整个项目中最有意思的部分。我使用了两个 Content Script，分别运行在不同的 World 中，各司其职。

5.1 ISOLATED World：api-bridge.js

这个脚本运行在 Chrome 为 Content Script 分配的隔离环境中。它可以访问 chrome.runtime API 与 Service Worker 通信，同时可以执行 fetch 发起同源请求。它是整个数据链路的桥梁：

chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  if (message.type === 'API_REQUEST') {
    const { url, method, data } = message;
    const opts = {
      method: method || 'GET',
      headers: { 'X-Requested-With': 'XMLHttpRequest' },
      credentials: 'same-origin',
    };
    if (data && method === 'POST') {
      opts.headers['Content-Type'] = 'application/x-www-form-urlencoded';
      opts.body = new URLSearchParams(data).toString();
    }
    fetch(url, opts)
      .then((r) => r.json())
      .then((json) => sendResponse({ data: json }))
      .catch((err) => sendResponse({ error: err.message }));
    return true; // 保持消息通道开放，等待异步 sendResponse
  }
});

注意几个细节。credentials: 'same-origin' 确保 fetch 携带 Cookie。X-Requested-With: XMLHttpRequest 是补天后端识别 AJAX 请求的标志。return true 是 Chrome 扩展消息系统的约定------如果 sendResponse 会异步调用，必须返回 true，否则消息通道会在函数返回时立即关闭。

5.2 MAIN World：page-tracker.js

这个脚本运行在页面自身的 JavaScript 上下文中，与页面代码共享全局对象。这意味着它可以直接修改 window.fetch、XMLHttpRequest.prototype、history.pushState 等原生 API。

为什么需要这个能力？因为我想记录用户在补天网站上的所有操作轨迹------包括页面跳转、SPA 路由变化、AJAX 请求等。在 ISOLATED World 中，你无法拦截页面代码发起的 XHR，因为两个 World 的全局对象是隔离的。

(function () {
  var CHANNEL = 'BT_TRACKER';

  function send(type, data) {
    window.postMessage({ channel: CHANNEL, type: type, data: data }, '*');
  }

  // 拦截 pushState
  var origPush = history.pushState;
  history.pushState = function () {
    origPush.apply(this, arguments);
    var newUrl = location.href;
    if (newUrl !== lastUrl) {
      lastUrl = newUrl;
      send('url', { url: newUrl, trigger: 'pushState' });
    }
  };

  // 拦截 XMLHttpRequest
  var origOpen = XMLHttpRequest.prototype.open;
  var origSend = XMLHttpRequest.prototype.send;

  XMLHttpRequest.prototype.open = function (method, url) {
    this._btMethod = method;
    this._btUrl = url;
    return origOpen.apply(this, arguments);
  };

  XMLHttpRequest.prototype.send = function (body) {
    var self = this;
    this.addEventListener('load', function () {
      // 过滤静态资源，只记录 API 请求
      if (isPOST || isApiUrl(fullUrl)) {
        send('api', {
          url: fullUrl,
          trigger: 'XHR-' + method,
          body: body ? String(body).substring(0, 300) : '',
          response: self.responseText.substring(0, 300),
        });
      }
    });
    return origSend.apply(this, arguments);
  };

  // 拦截 fetch（类似逻辑，略）
})();

5.3 两个 World 如何通信？

MAIN World 的脚本无法访问 chrome.runtime，ISOLATED World 的脚本无法直接读取 MAIN World 的数据。解决方案是使用 window.postMessage 作为桥梁：

MAIN World (page-tracker.js)
    ↓ window.postMessage({ channel: 'BT_TRACKER', data: ... })
ISOLATED World (api-bridge.js)
    ↑ window.addEventListener('message', handler)
    ↓ chrome.storage.local.set(...)
Service Worker / Popup

api-bridge.js 监听 message 事件，通过 channel 字段过滤出来自 page-tracker.js 的消息，然后将数据存入 chrome.storage.local。这样 Popup 就能读取完整的操作历史了。

这里有一个安全考虑：postMessage 是全局的，页面上任何脚本都可以发送消息。因此在接收端做了 event.source !== window 的检查，只处理同一窗口发来的消息，并通过 channel 字段做了二次验证。

---

六、智能推荐算法

奖励列表本身只是原始数据的展示，我想做一个更实用的"智能推荐"功能，帮白帽子快速找到性价比最高的 SRC。

6.1 评分模型

综合评分由四个维度加权构成：

function calcScore(item, allItems) {
  // 最高奖金得分 (权重 40%) --- 归一化到 0-100
  var maxScore = (maxReward / globalMaxReward) * 100;

  // 最低奖金得分 (权重 20%) --- 体现企业诚意
  var minScore = (minReward / globalMaxMin) * 100;

  // 服务状态得分 (权重 20%) --- 开放=100, 暂停=0
  var statusScore = isOpen ? 100 : 0;

  // 活跃度得分 (权重 20%) --- 90天内满分，线性衰减至365天归零
  var activityScore = daysSince <= 90 ? 100 :
    Math.max(0, 100 - ((daysSince - 90) / 275) * 100);

  return maxScore * 0.4 + minScore * 0.2 + statusScore * 0.2 + activityScore * 0.2;
}

为什么最低奖金也纳入评分？因为有些 SRC 的最高奖金看起来很诱人（比如 50 万），但最低奖金只有 100 元，说明大部分漏洞类型的奖金其实很低。最低奖金高的 SRC 通常意味着"保底收入"更可观。

活跃度使用了分段线性衰减：90 天内的企业被认为是活跃的（满分），90-365 天线性下降，超过 1 年直接归零。这反映了一个直觉------长期不更新的 SRC 可能响应慢、审核周期长。

6.2 难度分级与类型分类

为了让筛选更直观，我对企业做了两个维度的标签化处理。

难度分级基于最高奖金额度：入门（≤5000）、中等（≤5万）、困难（≤20万）、专家（>20万）。这不完全等同于技术难度，但从经验来看，高奖金的 SRC 通常资产复杂度更高、安全能力更强。

类型分类基于关键词匹配，对企业名称和简介进行扫描：

var TYPE_RULES = [  { key: 'finance',  label: '金融', keywords: ['银行','金融','保险','证券','支付',...] },
  { key: 'ecommerce',label: '电商', keywords: ['电商','商城','购物','零售',...] },
  { key: 'gaming',   label: '游戏', keywords: ['游戏','电竞','米哈游',...] },
  // ...
];

这种简单的规则引擎在数据量不大时效果不错，匹配顺序也隐含了优先级------如果一个企业同时匹配"金融"和"互联网"，它会被归类为"金融"，因为金融规则排在前面。

---

七、Popup UI：暗色主题与交互细节

7.1 暗色主题设计

考虑到安全从业者普遍偏好暗色界面（长时间使用低光照环境），整个 UI 采用了类似 GitHub Dark 的配色方案：

body {
  width: 420px;
  height: 560px;
  background: #0d1117;
  color: #e6edf3;
}

主背景 #0d1117，卡片背景 #161b22，边框 #21262d，高亮蓝 #1890ff，成功绿 #3fb950，警告橙 #f0883e。这套配色经过验证，对比度满足 WCAG AA 标准，长时间阅读不会造成视觉疲劳。

7.2 Tab 切换与懒渲染

四个 Tab（奖励排行、智能推荐、新入驻、报名记录）采用了纯 CSS 的显示/隐藏控制，配合 JavaScript 的按需渲染：

function renderCurrentTab() {
  switch (state.currentTab) {
    case 'reward':     renderRewardList();     break;
    case 'recommend':  renderRecommendList();  break;
    case 'newCompany': renderNewCompanyList();  break;
    case 'urlHistory': renderUrlHistory();      break;
  }
}

切换 Tab 时只渲染当前面板的内容，避免一次性渲染所有列表导致的性能问题。搜索框是全局共享的，输入时会根据当前活动的 Tab 来决定过滤哪个列表。

7.3 搜索防抖

搜索输入使用了 200ms 的防抖，避免每按一个键就重新渲染列表：

var timer = null;
dom.searchInput.addEventListener('input', function () {
  clearTimeout(timer);
  timer = setTimeout(function () {
    state.searchQuery = dom.searchInput.value.trim();
    renderCurrentTab();
  }, 200);
});

200ms 是一个经验值------足够短以保证即时反馈感，足够长以过滤掉连续快速输入。

---

八、图标生成：纯代码绘制 PNG

为了让项目完全自包含（不依赖任何外部图片资源），我用两种方式实现了图标生成。

8.1 浏览器端：Canvas 绘制

icons/generate-icons.html 使用 Canvas 2D API 绘制一个蓝色圆角矩形背景 + 白色盾牌 + 蓝色对勾的图标，然后通过 canvas.toDataURL('image/png') 导出：

function drawIcon(canvas) {
  const s = canvas.width;
  const ctx = canvas.getContext('2d');

  // 圆角矩形背景
  ctx.beginPath();
  ctx.moveTo(r, 0);
  ctx.lineTo(s - r, 0);
  ctx.quadraticCurveTo(s, 0, s, r);
  // ...
  ctx.fillStyle = '#1890ff';
  ctx.fill();

  // 盾牌路径
  ctx.beginPath();
  ctx.moveTo(cx, top);
  ctx.lineTo(cx - w, top + s * 0.12);
  // ...（贝塞尔曲线构建盾牌轮廓）
  ctx.fillStyle = '#ffffff';
  ctx.fill();

  // 对勾
  ctx.beginPath();
  ctx.strokeStyle = '#1890ff';
  ctx.lineWidth = Math.max(s * 0.08, 1.5);
  ctx.moveTo(cx - s * 0.12, s * 0.45);
  ctx.lineTo(cx - s * 0.02, s * 0.57);
  ctx.lineTo(cx + s * 0.14, s * 0.37);
  ctx.stroke();
}

所有坐标都使用相对比例（如 s * 0.15），确保 16px、48px、128px 三种尺寸下图标都清晰锐利。

8.2 Node.js 端：手工构建 PNG 二进制

icons/gen.js 是一个更极客的方案------直接用 Node.js 逐像素计算颜色，然后手工拼接 PNG 文件的二进制格式（Signature → IHDR → IDAT → IEND），连 canvas 库都不需要安装：

function createPNG(size) {
  const pixels = Buffer.alloc(size * size * 4);

  for (let y = 0; y < size; y++) {
    for (let x = 0; x < size; x++) {
      // 判断像素是否在圆角矩形内
      // 判断是否在盾牌区域内
      // 判断是否在对勾线段上（点到线段距离计算）
      // 根据结果设置 RGBA 颜色
    }
  }

  // 手工构建 PNG：签名 + IHDR + 压缩数据(IDAT) + IEND
  const compressed = zlib.deflateSync(rawData);
  return Buffer.concat([signature, chunk('IHDR', ihdr), chunk('IDAT', compressed), chunk('IEND', empty)]);
}

这段代码本身就是一个迷你的 PNG 编码器教程。对勾的绘制使用了点到线段距离公式，当距离小于线宽时就判定为对勾区域------这种逐像素判断的方式在低分辨率（16px）下比矢量绘制更可控。

---

九、踩坑记录

坑 1：Service Worker 被终止后状态丢失

最初我把缓存数据存在 Service Worker 的全局变量中，结果发现有时候 Popup 拿到的是空数据。原因是 Chrome 会在 Service Worker 空闲约 30 秒后将其终止，全局变量全部丢失。解决方案就是前面提到的 chrome.storage.local 持久化缓存。

坑 2：Content Script 在扩展重载后失效

开发阶段频繁修改代码并重新加载扩展，但已打开的补天页面中的 Content Script 仍然是旧版本。chrome.tabs.sendMessage 会抛出连接错误。解决方案是在首次通信失败时刷新标签页，让新版 Content Script 重新注入。

坑 3：MAIN World 脚本无法使用 chrome API

刚开始我把所有逻辑写在一个 Content Script 里，设置了 "world": "MAIN"。结果发现 chrome.runtime.onMessage 是 undefined------MAIN World 的脚本运行在页面上下文中，没有扩展 API 的访问权限。必须拆成两个脚本，MAIN World 负责拦截，ISOLATED World 负责通信，通过 postMessage 桥接。

坑 4：sendResponse 的异步陷阱

在 chrome.runtime.onMessage 的回调中，如果要异步调用 sendResponse（比如等待 fetch 完成），必须 return true。否则消息通道会在回调函数同步执行完毕后立即关闭，之后的 sendResponse 调用不会生效，Popup 端会收到 undefined。这是 Chrome 扩展开发中最经典的坑之一。

坑 5：Popup 关闭后 Promise 中断

Popup 的生命周期很短------用户点击其他地方就会关闭。如果此时有正在进行的 API 请求，Promise 会被中断。因此数据加载使用了 Promise.allSettled 而非 Promise.all，确保即使部分请求失败也能展示已获取的数据。

---

十、项目结构总结

butian-helper/
├── manifest.json                  # MV3 配置，双 Content Script + Service Worker
├── background/
│   └── service-worker.js          # 调度中心：缓存管理 + 标签页管理 + 消息路由
├── content/
│   ├── api-bridge.js              # ISOLATED World：API 代理 + 追踪数据收集
│   └── page-tracker.js            # MAIN World：XHR/fetch/pushState 拦截
├── popup/
│   ├── popup.html                 # 弹窗骨架
│   ├── popup.css                  # 暗色主题样式
│   └── popup.js                   # UI 渲染 + 评分算法 + 交互逻辑
├── icons/
│   ├── gen.js                     # Node.js PNG 生成器
│   └── generate-icons.html        # 浏览器端图标生成
└── README.md

整个项目零外部依赖，纯原生 JavaScript 实现，总代码量约 1200 行。在 MV3 的约束下，通过 Content Script 代理请求、双 World 协作、postMessage 桥接等技巧，完整实现了数据抓取、智能排序、操作追踪等功能。

---

十一、后续优化方向

当前版本还有几个可以优化的地方。分页加载 ------目前奖励列表只获取了第一页，如果企业数量超过单页上限，需要实现滚动加载或分页请求。离线模式 ------当用户没有登录补天或网络不可用时，可以展示上次缓存的数据并标注"可能不是最新"。通知推送 ------利用 chrome.alarms 定时检查是否有新入驻企业或奖金变动，通过 chrome.notifications 推送桌面通知。导出功能------将筛选后的企业列表导出为 CSV 或 Markdown，方便整理到个人的 SRC 清单中。

---

如果你也在做 Chrome 扩展开发，特别是需要与目标网站的 Session/Cookie 交互的场景，希望这篇文章中的架构设计和踩坑经验能帮到你。完整源码已在文中给出，可以直接加载使用。