ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Claude+Trae大模型 配置Chrome MCP联动Yakit自动化渗透测试

2026/10/2 6:35:34 拓冰建站 浏览量
Claude+Trae大模型 配置Chrome MCP联动Yakit自动化渗透测试 1. 从零理解 Chrome MCP 与 Yakit 联动的自动化渗透测试链路Chrome MCP Server 是一个把浏览器能力通过模型上下文协议暴露给 AI 助手的插件方案它让 Claude、Trae 这类支持 MCP 的客户端可以直接接管你日常使用的 Chrome完成页面导航、接口抓取、表单交互、语义搜索等操作。和 Playwright 系 MCP 最大的区别在于它复用你已登录的浏览器会话和完整用户环境不需要额外拉起一个干净浏览器进程启动快、资源占用低对需要保持登录态的渗透测试场景尤其友好。Yakit 则是一款国产安全测试平台内置 MCP 服务后可以把请求抓包、主动扫描、DNSLog 反连等能力同样以 MCP 工具的形式暴露给 AI。把两者串起来就能形成浏览器抓接口 → AI 分析 → Yakit 主动验证 → DNSLog 回显确认的自动化渗透测试闭环。这套链路适合谁适合已经具备基础 Web 安全知识、想在本地靶场或授权环境中提升测试效率的安全从业者。它不能替代你对漏洞原理的理解但能把你从重复的接口收集、请求构造、结果比对中解放出来。我实测下来一个中等规模的靶场站点人工收集接口大概要二三十分钟交给 Chrome MCP 自动遍历后几分钟就能产出一份结构化的 api.txt而且覆盖度往往比手动更全。整条链路涉及三个组件Trae 作为 MCP 客户端和 AI 编排入口Chrome MCP Server 作为浏览器能力提供方Yakit 作为安全测试能力提供方。三者通过本地 HTTP/SSE 端口通信全部跑在 127.0.0.1 上不涉及任何外部网络穿透。下面按环境准备 → 配置声明 → 联动验证 → 排障的顺序展开每一步都给可复制的片段。需要提前说明的是本文所有操作都应在你拥有合法授权的目标上进行本地靶场是最稳妥的练习对象。Yakit 自带一键部署的漏洞靶场正好用来验证整条链路是否按预期流转。2. TaoToken 统一 Key 与 API 通道的前置准备在配置 MCP 之前先把大模型侧的调用通道理顺。Trae 里调用 Claude 需要填入可用的 API 通道如果你手上有多个模型供应商、多个 Key来回切换会很麻烦。TaoToken 提供统一的 Key 和 API 通道把模型调用收敛到一个入口配置一次就能在 Trae、Claude Code、Cline 等客户端复用。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 。具体操作上先在控制台创建一个 API Key然后拿到两个关键信息Base URL 填https://taotoken.net/apiModel ID 按你实际要用的模型填比如claude-sonnet-4-5这类标识。这三件套Base URL Key Model ID是后面所有客户端配置的通用模板Trae 的模型设置、Claude Code 的 settings、Cline 的 provider 配置都遵循同样的结构。如果你用的是 Claude Code配置通常写在~/.claude/settings.json或项目级.claude/settings.json里形如{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的Key, ANTHROPIC_MODEL: claude-sonnet-4-5 } }Trae 侧则在设置里的模型配置处填入同样的 Base URL 和 Key模型名按平台提供的列表选择。配置完成后建议先用一次简单对话验证通道是否通确认模型能正常返回再往下走 MCP 配置。这一步别跳过否则后面 MCP 报错时你分不清是模型通道问题还是 MCP 问题。对于长期做编码和 Agent 任务的场景可以考虑 Coding Plan把额度集中管理避免多个 Key 分散导致排查困难。模型对话入口在 https://taotoken.net/api 接入文档在 https://taotoken.net/api 需要看具体参数时对照文档即可。API Key 管理页面在 https://taotoken.net/api 创建和吊销都在这里操作。把模型通道理顺之后Trae 就具备了大脑接下来给它接上手——Chrome MCP 和 Yakit MCP。3. 可复制的 MCP 配置片段Chrome 与 Yakit 双服务声明这一节是整篇的核心所有配置片段都可以直接复制。先装 Chrome MCP 插件从 GitHub 项目 hangwin/mcp-chrome 下载压缩包解压后在 Chrome 的扩展管理页开启开发者模式选择加载已解压的扩展程序把文件夹丢进去。插件依赖 Node.js 20先用node -v确认版本低于 20 的先升级。然后全局安装通信桥npm install -g mcp-chrome-bridge --registryhttps://registry.npmmirror.com装完后打开 Chrome MCP Server 插件界面显示运行中即可默认端口 12306 不用改。此时 Chrome 侧的 MCP 服务已经就绪地址是http://127.0.0.1:12306/mcp。接着在 Trae 里声明这个 MCP 服务。打开 Trae 设置 → MCP把下面的 JSON 粘进去{ mcpServers: { streamable-mcp-server: { type: streamable-http, url: http://127.0.0.1:12306/mcp } } }保存后 Trae 会尝试连接状态显示正常就说明 Chrome MCP 已挂载。注意type必须是streamable-http写成sse会连不上这是最常见的配置错误之一。然后是 Yakit 侧。更新 Yakit 到较新版本在菜单里找到 MCP 配置直接点启动Yakit 会在本地拉起一个 SSE 服务默认地址http://127.0.0.1:11432/sse。回到 Trae 的 MCP 配置把 Yakit 也加进去形成双服务声明{ mcpServers: { streamable-mcp-server: { type: streamable-http, url: http://127.0.0.1:12306/mcp }, yakit: { url: http://127.0.0.1:11432/sse } } }这里有个细节Chrome MCP 用的是 streamable-httpYakit 用的是 sse两种传输方式在同一个配置文件里共存没问题Trae 会分别处理。保存后确认两个服务都显示已连接。如果 Yakit 那项一直转圈先确认 Yakit 的 MCP 服务确实点了启动再看端口 11432 有没有被占用。配置写完后建议把这份 JSON 单独存一份到项目目录比如.trae/mcp.json方便团队复用和版本管理。路径和字段名保持和上面一致不要自己改mcpServers的拼写大小写敏感。4. 验证请求流转本地靶场跑通抓接口与 SSRF 检测配置就绪后用 Yakit 自带靶场做一次端到端验证。打开 Yakit选择靶场一键安装后访问http://127.0.0.1:8787/能看到靶场首页就说明部署成功。第一步验证 Chrome MCP 是否真的能接管浏览器抓接口。在 Trae 里选好模型输入这样的提示词使用 Google Chrome 浏览器通过 streamable-mcp-server 服务提取接口信息 1. 打开 http://127.0.0.1:8787/ 并访问 2. 全面浏览网站及所有子页面识别并提取所有 API 接口 3. 接口信息包含完整 URL 路径、请求方法、请求参数、响应格式 4. 整理成结构化格式保存为当前目录下的 api.txt编码 UTF-8 5. 验证文件内容完整性执行后观察 Trae 的工具调用日志应该能看到它依次调用 Chrome MCP 的导航、页面内容获取等工具。跑完后检查工作目录下的 api.txt里面应该列出了靶场各页面对应的接口路径和方法。如果文件是空的多半是 Chrome 插件没连上回到第 3 节确认插件状态。第二步验证 Yakit MCP 的主动检测能力。针对靶场的 SSRF 页面输入使用 Yakit 安全测试工具对 http://127.0.0.1:8787/ssrf/ 进行 SSRF 漏洞检测 1. 导入已抓取的数据包至 Yakit 2. 配置 Yakit 内置 DNSLog 反连服务 3. 利用 Yakit-MCP 模块对目标 URL 实施 SSRF 测试 4. 包含本地 IP 探测、内部服务访问、DNS 重绑定等向量 5. 监控 DNSLog 请求记录确认是否有目标服务器发起的 DNS 解析 6. 记录测试结果并生成 .md 格式报告执行过程中切到 Yakit 界面在 DNSLog 面板应该能看到回显记录说明目标服务器确实发起了 DNS 解析请求SSRF 被成功触发。这一步是整个链路的关键验证点Chrome MCP 负责看和抓Yakit MCP 负责打和验AI 负责编排和结果整理。三者各司其职请求按预期在本地端口之间流转。验证通过后你可以把这套流程固化成提示词模板针对不同靶场页面替换 URL 即可复用。接口收集和漏洞检测两个阶段可以分开跑也可以串成一个长任务让 AI 自动衔接。5. 常见报错排查401、local proxy failed 与 OAuth 问题实际配置中会遇到几类典型报错逐个说清楚。401 Unauthorized出现在模型调用阶段说明 TaoToken 的 Key 无效或没填对。检查 Trae 模型设置里的 API Key 是否完整复制Base URL 是否为https://taotoken.net/api有没有多余空格。如果 Key 刚创建确认没有过期或被吊销。Claude Code 场景下检查settings.json里ANTHROPIC_API_KEY字段拼写。local proxy failed / connection refused出现在 MCP 连接阶段说明 Trae 连不上本地服务。分两种情况Chrome MCP 报这个错确认插件是否在运行、端口 12306 是否被占用用curl http://127.0.0.1:12306/mcp测一下Yakit 报这个错确认 Yakit 的 MCP 服务点了启动、端口 11432 是否监听。Windows 上用netstat -ano | findstr 11432查端口状态。reading choices 相关报错通常出现在模型返回格式解析阶段多因模型通道返回了非预期结构。先确认模型 ID 填对再检查是不是把 streamable-http 的 MCP 响应误当成模型响应。换一个简单提示词测试模型通道是否正常能正常对话就说明是 MCP 侧的问题。OAuth 相关报错部分 MCP 客户端在连接远程服务时会走 OAuth 流程本地 127.0.0.1 服务一般不需要。如果 Trae 提示 OAuth检查 MCP 配置里有没有多余的 auth 字段本地服务保持最简配置即可。Yakit 的 SSE 服务不需要 OAuth直接填 URL 就行。Chrome MCP 连上但抓不到接口检查 Chrome 是否真的打开了目标页面插件是否在当前窗口激活。有时候浏览器开了多个窗口插件只对激活窗口生效。另外确认目标页面没有跨域限制导致内容读取失败。Yakit DNSLog 无回显确认靶场 SSRF 页面确实存在漏洞DNSLog 域名配置正确网络能正常解析。本地靶场一般没问题如果换了外部目标确认目标能出网。排查时建议按模型通道 → Chrome MCP → Yakit MCP的顺序逐层验证每层单独测通再串起来比一上来就端到端跑更容易定位问题。6. 把链路用起来从靶场到授权测试的落地建议跑通靶场之后这套链路的真正价值在于把它用到你有合法授权的测试目标上。几个实操建议接口收集阶段让 Chrome MCP 尽量遍历完整包括隐藏路径和参数产出的 api.txt 可以直接作为 Yakit 主动扫描的输入漏洞检测阶段把常见向量拆成多个提示词分批跑避免单次任务过长导致上下文丢失结果整理阶段让 AI 输出结构化报告包含复现步骤和修复建议方便交付。Skills 方面可以给 Trae 挂载安全测试专家技能包把漏洞案例库和测试方法论沉淀进去让 AI 在编排时更有章法。智能体创建时把合法授权前提工具优先调用验证优先这几条原则写进系统提示词能明显减少空泛输出。需要长期跑自动化任务的把模型通道统一到 Coding PlanKey 和额度集中管理避免多客户端配置漂移。API Key 在 https://taotoken.net/api 管理接入细节对照 https://taotoken.net/api 文档。模型对话验证通道在 https://taotoken.net/api Coding Plan 适合长期编码和 Agent 场景。最后提醒一句这套工具链再顺手也只是放大器漏洞判断和风险决策仍然要靠人。靶场练熟、授权范围内使用才是长久之道。