★ FEATURED ARTICLE 1. 这套联动方案到底在解决什么问题做渗透测试的人都有一个共同的痛点手工操作太多重复劳动太重。打开浏览器、点开目标站点、抓包、分析请求、把可疑参数丢到Yakit里重放、改payload、看响应、再回到浏览器验证……这一套流程走下来一个测试点可能就要花十几分钟。如果目标站点有几十个接口光是把这些接口逐个过一遍一天时间就没了。我最初的想法很简单能不能让大模型帮我看浏览器里的页面自动识别出哪些请求值得测然后直接调用Yakit的API去发包验证这个想法听起来有点激进但拆开来看其实就是三件事——浏览器控制、大模型决策、安全工具执行。Chrome MCP负责第一件事Claude负责第二件事Yakit负责第三件事Trae则作为整个流程的编排环境。先说Chrome MCP。MCP是Model Context Protocol的缩写本质上是一套让大模型能够调用外部工具的协议标准。Chrome MCP就是把Chrome DevTools的能力封装成MCP工具让Claude可以直接控制浏览器——打开页面、点击元素、读取DOM、获取网络请求、执行JavaScript。这意味着大模型不再只是看截图猜内容而是能拿到结构化的页面数据和真实的网络流量。再说Yakit。Yakit是国内安全圈子里口碑很好的交互式应用安全测试平台它提供了MITM劫持、Web Fuzzer、漏洞检测、数据包重放等一整套能力。关键是Yakit也支持MCP接口也就是说Claude可以通过MCP协议直接调用Yakit的发包、重放、Fuzz等功能。这就打通了从发现到验证的最后一公里。Trae在这里扮演的角色是集成开发环境Agent运行时。Trae是字节跳动推出的AI IDE支持接入Claude等大模型并且内置了Agent模式可以自主规划任务、调用工具、执行多步操作。把Chrome MCP和Yakit MCP都配置到Trae里Claude就能在一个统一的Agent循环中同时操控浏览器和安全工具。注意这套方案的核心价值不是全自动挖洞而是把渗透测试中信息收集、请求分析、初步验证这三个环节的重复劳动压缩掉让测试人员把精力集中在逻辑漏洞、业务缺陷这些真正需要人类判断的地方。适合读这篇文章的人有一定渗透测试基础熟悉Burp Suite或Yakit的基本操作对MCP协议和大模型Agent有初步了解想尝试把AI引入自己工作流的安全从业者。如果你完全没接触过MCP也不用担心我会在第二章把环境搭建的每一步都拆开讲清楚。2. 环境搭建从零把三个组件串起来2.1 Trae的安装与Claude模型接入Trae的安装没什么特别的官网下载对应平台的安装包Windows下双击安装macOS拖进Applications就行。安装完成后第一次启动会让你登录账号用手机号或者邮箱注册都可以。登录之后进入主界面你会看到一个类似VS Code的布局左侧是文件树中间是编辑器右侧是AI对话面板。接入Claude模型有两种方式。一种是在Trae的设置里直接选择内置的Claude模型Trae自带了一些模型的接入另一种是通过API Key的方式接入你自己的Claude账号。我建议用第二种因为Agent模式下token消耗比较大用自己的API Key更可控。具体操作路径是设置 → 模型配置 → 添加模型 → 选择Anthropic → 填入API Key。这里有个坑要注意Claude的API Key需要你有Anthropic的账号并且开通了API访问权限。如果你用的是Claude Desktop或者Claude Code那是另一套认证体系不能直接拿来当API Key用。填完API Key之后Trae会让你选择模型版本。目前Claude系列里Sonnet版本在速度和能力之间平衡得比较好适合Agent场景下频繁调用。Opus版本更强但更慢更贵如果你要做复杂的多步推理可以选它但日常的页面分析和请求判断Sonnet完全够用。配置完成后在Trae的对话面板里发一条测试消息确认模型能正常响应。如果报400错误大概率是API Key格式不对或者账户余额不足。我遇到过一种情况是Key复制的时候末尾多了个空格排查了半天才发现这种低级错误大家注意一下。2.2 Chrome MCP的配置细节Chrome MCP的配置是整个方案里最容易出问题的环节。它的原理是启动一个本地的MCP Server这个Server通过Chrome DevTools ProtocolCDP连接到Chrome浏览器然后把浏览器操作能力暴露成MCP工具。首先你需要确保本机安装了Chrome浏览器版本不要太老建议100以上。然后安装Chrome MCP Server通常是通过npm安装npm install -g anthropic/chrome-mcp-server安装完成后你需要以调试模式启动Chrome这样MCP Server才能通过CDP连接上去# Windows C:\Program Files\Google\Chrome\Application\chrome.exe --remote-debugging-port9222 # macOS /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port9222 # Linux google-chrome --remote-debugging-port9222启动之后Chrome会打开一个新的窗口这个窗口就是MCP可以控制的浏览器实例。你可以在里面正常登录目标站点、保持会话状态MCP Server会复用这个会话。接下来在Trae的MCP配置文件中添加Chrome MCP Server的配置。Trae的MCP配置文件通常位于用户目录下的.trae/mcp.json格式如下{ mcpServers: { chrome: { command: npx, args: [-y, anthropic/chrome-mcp-server], env: { CHROME_DEBUG_PORT: 9222 } } } }保存之后重启Trae在MCP面板里应该能看到chrome这个Server的状态变成已连接。如果显示连接失败先检查Chrome是否以调试模式启动再检查端口是否被占用。提示Chrome MCP能做的事情包括导航到指定URL、获取页面DOM结构、执行JavaScript、获取网络请求列表、点击元素、填写表单、截图等。它不能做的事情包括绕过验证码、处理复杂的登录流程需要你手动先登录好、访问需要特定插件的页面。2.3 Yakit MCP的对接方式Yakit的MCP对接相对简单一些因为Yakit本身就提供了MCP Server功能。你需要先下载安装Yakit官网直接下载对应平台的安装包即可。安装完成后启动Yakit进入设置 → MCP Server开启MCP服务。Yakit的MCP Server默认监听本地的一个端口通常是11434或者类似的。开启之后你可以在Yakit的界面上看到可用的MCP工具列表包括工具名称功能说明yakit_send_request发送HTTP请求yakit_replay重放历史请求yakit_fuzz对指定参数进行Fuzzyakit_get_history获取历史请求记录yakit_scan对目标发起漏洞扫描然后在Trae的MCP配置文件里添加Yakit的配置{ mcpServers: { chrome: { command: npx, args: [-y, anthropic/chrome-mcp-server], env: { CHROME_DEBUG_PORT: 9222 } }, yakit: { url: http://127.0.0.1:11434/mcp, type: sse } } }注意Yakit的MCP用的是SSEServer-Sent Events协议所以配置里要写type: sse。保存后重启TraeMCP面板里应该能看到yakit也连接成功了。2.4 验证三个组件是否正常联动配置完成后做一个简单的联动测试。在Trae的Agent对话里输入请使用Chrome MCP打开 https://example.com获取页面的所有网络请求然后把其中返回状态码为200的请求URL列出来。如果一切正常Claude会调用Chrome MCP的导航工具打开页面然后调用获取网络请求的工具最后把结果整理出来。这一步验证的是Chrome MCP和Claude的联动。再测试Yakit的联动请使用Yakit MCP向 https://example.com 发送一个GET请求然后把响应状态码和响应头告诉我。如果Yakit MCP配置正确Claude会调用Yakit的发包工具你也能在Yakit的历史记录里看到这条请求。两个都通了之后就可以开始真正的自动化渗透测试流程了。3. 自动化渗透测试的完整工作流拆解3.1 信息收集阶段的自动化传统的信息收集是手工打开目标站点逐个页面点击用Burp或者Yakit的代理抓包然后人工筛选有价值的请求。这个过程在目标站点规模较大的时候非常耗时。用Chrome MCPClaude的组合你可以让Agent自动完成第一轮信息收集。具体的做法是给Claude一个指令让它遍历目标站点的关键页面收集所有XHR/Fetch请求、表单提交、API调用然后按照请求方法、参数类型、响应内容做一个分类整理。我实际用下来比较有效的指令模板是这样的你是一个渗透测试助手。请使用Chrome MCP完成以下任务 1. 打开目标站点 [URL] 2. 遍历首页上所有可点击的链接最多访问20个页面 3. 对每个页面获取所有网络请求 4. 筛选出包含参数query string或POST body的请求 5. 按照参数类型分类数字型、字符串型、JSON型、文件上传型 6. 输出一个表格包含请求URL、方法、参数名、参数示例值Claude会按照这个指令逐步操作中间可能会遇到页面加载慢、元素找不到等问题它会在Agent循环里自己重试或者调整策略。最终输出的表格就是你后续测试的靶点清单。这里有个经验不要让Claude一次性遍历太多页面。我试过让它遍历50个页面结果token消耗巨大而且中间容易因为某个页面超时而中断。比较合理的做法是分批处理每次10-20个页面处理完一批再给下一批指令。3.2 请求分析与可疑点标记拿到请求清单之后下一步是让Claude分析哪些请求值得深入测试。这一步是Claude的强项因为它可以结合请求的上下文页面内容、参数命名、响应结构来判断潜在的风险点。我会给Claude这样的指令请分析以下请求列表标记出可能存在安全风险的请求。判断依据包括 - 参数名包含id、uid、file、path、url、cmd、exec等敏感词 - 参数值看起来像Base64编码或序列化数据 - 请求涉及文件操作、命令执行、数据库查询等敏感功能 - 响应中返回了其他用户的敏感信息 - 存在越权访问的可能如通过修改id访问他人数据 对每个可疑请求说明可疑原因和建议的测试方法。Claude会输出一个标记了风险等级的清单。我实测下来它对参数命名的敏感度很高像user_id、file_path、redirect_url这类参数基本都能识别出来。但它对业务逻辑层面的漏洞判断能力有限比如这个接口虽然参数看起来正常但结合业务流程可能存在竞争条件——这种还是需要人来判断。所以这一步的定位是辅助筛选不是替代人工分析。Claude帮你把明显可疑的请求挑出来你在这个基础上做二次判断。3.3 用Yakit MCP执行验证测试这是整个流程里最核心的环节。Claude分析出可疑请求之后直接通过Yakit MCP调用发包工具进行验证。举个实际的例子。假设Claude发现了一个请求GET /api/user/profile?user_id1001 HTTP/1.1 Host: target.com Cookie: sessionabc123Claude判断user_id参数可能存在越权访问它会自动构造测试请求GET /api/user/profile?user_id1002 HTTP/1.1 Host: target.com Cookie: sessionabc123然后通过Yakit MCP发送这个请求对比响应内容是否包含其他用户的信息。如果响应中返回了user_id1002的用户数据就说明存在水平越权。这个过程Claude可以自动化完成你只需要在指令里告诉它测试策略对于标记为越权风险的请求请使用Yakit MCP执行以下测试 1. 将用户相关参数的值1和-1各发送一次请求 2. 对比响应状态码和响应体长度 3. 如果响应内容与原始请求不同且包含用户数据标记为疑似越权 4. 输出测试结果表格对于SQL注入的测试Claude可以调用Yakit的Fuzz功能对可疑参数注入一组payload请使用Yakit MCP对参数id进行Fuzz测试payload列表 OR 11 OR 12 1 AND SLEEP(5)-- 1 UNION SELECT NULL--Yakit会执行这些请求Claude根据响应时间、状态码、响应内容的变化来判断是否存在注入点。3.4 结果汇总与报告生成测试完成后Claude可以把所有发现整理成一份结构化的报告。我通常会让它输出Markdown格式包含以下内容测试目标与范围发现的漏洞列表按风险等级排序每个漏洞的请求/响应证据复现步骤修复建议这份报告可以直接作为渗透测试报告的初稿你只需要补充业务背景、影响评估这些需要人工判断的内容。注意Claude生成的报告里漏洞描述和修复建议部分需要人工审核。它有时候会给出过于笼统的建议比如对输入进行过滤你需要根据具体业务场景细化。4. 实操中踩过的坑与应对策略4.1 Chrome MCP连接不稳定的排查思路Chrome MCP最常见的问题是连接断开。表现是Claude在执行浏览器操作时突然报错无法连接到Chrome或者CDP连接超时。我排查下来原因主要有三个第一个原因是Chrome窗口被手动关闭了。MCP控制的Chrome实例必须保持运行如果你不小心关掉了那个窗口连接就断了。解决办法是重新以调试模式启动Chrome然后在Trae里重连MCP Server。第二个原因是端口冲突。9222端口可能被其他程序占用了。你可以换一个端口比如9223然后同步修改MCP配置里的CHROME_DEBUG_PORT。第三个原因是Chrome版本更新后CDP协议有变化。这种情况比较少见但如果前面两个原因都排除了还是连不上可以试试更新Chrome MCP Server到最新版本npm update -g anthropic/chrome-mcp-server还有一个隐藏的坑如果你同时开了多个Chrome实例MCP可能会连到错误的那个。建议在启动调试模式Chrome之前先关掉所有其他Chrome窗口。4.2 Yakit MCP调用超时的处理Yakit MCP在执行Fuzz或者扫描任务时因为要发送大量请求很容易超时。默认的超时时间可能只有30秒对于需要发送几十个payload的Fuzz任务来说不够用。解决办法是在Yakit的MCP Server设置里调整超时时间。进入设置 → MCP Server → 高级设置把请求超时改成120秒或者更长。同时在Trae的MCP配置里也可以设置超时参数{ mcpServers: { yakit: { url: http://127.0.0.1:11434/mcp, type: sse, timeout: 120000 } } }另外如果Fuzz的payload列表很长建议分批发送。比如100个payload分成5批每批20个这样单次调用的时间可控也不容易因为某个payload导致整个任务卡死。4.3 Claude在Agent模式下跑偏的纠正方法Agent模式下Claude有时候会自作主张做一些你没让它做的事情。比如你让它分析请求它顺便帮你把请求发出去了或者你让它测试一个参数它把整个页面的所有参数都测了一遍。这种情况的根本原因是Agent的自主性太强而你的指令不够明确。我的经验是指令要尽可能具体把不要做什么也写清楚。比如不要写帮我测试这个接口而要写请只对user_id这一个参数进行测试不要测试其他参数。 测试方法限定为将user_id的值替换为1002和1003各发送一次请求。 不要执行Fuzz不要执行扫描只做这两次替换测试。另外Trae的Agent模式通常有一个最大步数的设置限制Agent在一次任务中最多执行多少步操作。把这个值设小一点比如10步可以防止Claude陷入无限循环。如果任务确实需要更多步骤分多次对话来完成。4.4 目标站点反自动化机制的应对有些目标站点会检测自动化工具比如检测CDP连接、检测无头浏览器特征、检测请求频率等。Chrome MCP控制的浏览器虽然是有头模式但仍然可能被识别。应对方法有几个控制请求频率在指令里明确告诉Claude每次请求之间间隔2-3秒。Yakit MCP也支持设置请求间隔。使用真实的用户会话先在Chrome里手动登录目标站点完成所有验证步骤然后再让MCP接管。这样浏览器里已经有合法的session和cookie。避免触发WAF如果Yakit的Fuzz payload被WAF拦截响应会返回403或自定义的拦截页面。Claude需要能识别这种情况我通常会在指令里加一句如果响应状态码为403或响应内容包含WAF特征请停止测试并报告。提示这套方案仅适用于你有明确授权的测试目标。未经授权的渗透测试是违法行为这个底线不能碰。5. 进阶玩法把流程串成可复用的Agent工作流5.1 用Trae的自定义Agent模板固化流程每次测试都重新写一遍指令太麻烦了。Trae支持自定义Agent模板你可以把上面提到的信息收集、请求分析、验证测试、报告生成这四个阶段的指令固化成一个模板。具体做法是在Trae的Agent设置里创建一个新的Agent给它起个名字比如Web渗透测试助手然后把系统提示词写成你是一个专业的Web渗透测试助手擅长使用Chrome MCP和Yakit MCP进行自动化测试。 你的工作流程是 1. 信息收集使用Chrome MCP遍历目标站点收集所有带参数的请求 2. 请求分析对收集到的请求进行风险标记输出可疑请求清单 3. 验证测试使用Yakit MCP对可疑请求进行验证测试方法包括越权、注入、SSRF等 4. 报告生成整理测试结果输出Markdown格式的报告 在执行每一步之前先向我确认再继续。不要跳过任何步骤不要执行未授权的测试。这样每次开始新的测试任务时直接选择这个Agent输入目标URL就可以了。5.2 结合Claude Code做本地脚本生成有些测试任务用Agent做效率不高比如需要对大量URL进行批量检测。这种情况下可以让Claude生成Python脚本然后你在本地执行。比如你有一个包含500个URL的列表需要检测每个URL是否存在某个特定的漏洞。用Agent逐个测试太慢了但让Claude写一个脚本就很快import requests from concurrent.futures import ThreadPoolExecutor def check_vulnerability(url): try: resp requests.get(url, timeout10) if vulnerable_pattern in resp.text: return f[VULNERABLE] {url} return f[SAFE] {url} except Exception as e: return f[ERROR] {url} - {str(e)} urls [...] # 你的URL列表 with ThreadPoolExecutor(max_workers10) as executor: results executor.map(check_vulnerability, urls) for result in results: print(result)Claude Code可以在Trae的终端里直接运行生成脚本、执行脚本、分析结果一气呵成。这种方式适合批量、重复性的检测任务。5.3 多目标并行测试的编排思路如果你需要同时测试多个目标可以开多个Trae窗口每个窗口配置不同的Chrome实例和Yakit项目。但要注意资源占用每个Chrome实例大概占500MB内存Yakit也占不少资源同时跑3-4个实例已经是普通笔记本的极限了。另一种思路是用Trae的任务队列功能把多个目标排成队列一个接一个自动执行。这种方式虽然不能并行但胜在稳定不会因为资源竞争导致某个任务失败。我个人的做法是重要的目标单独跑用完整的Agent流程批量的小目标用脚本跑只做基础检测。这样既保证了重点目标的测试深度又兼顾了批量目标的覆盖广度。5.4 这套方案的边界与不适合的场景说了这么多好处也得说说这套方案不适合什么场景。第一不适合需要复杂交互的测试。比如需要多步表单提交、需要处理验证码、需要模拟特定用户行为的场景Agent很难处理。这种还是手工测试更靠谱。第二不适合对性能要求高的测试。比如压力测试、并发测试Agent的串行执行模式效率太低。第三不适合对隐蔽性要求高的测试。Agent的请求模式比较固定容易被目标站点的安全设备识别。如果你需要隐蔽测试还是得手工构造请求。第四不适合没有明确测试目标的情况。如果你自己都不知道要测什么Agent更不知道。这套方案的前提是你有明确的测试范围和测试策略Agent只是帮你执行。我在实际项目里的定位是用这套方案做第一轮快速筛查把明显的问题找出来然后人工针对重点区域做深度测试。它替代不了渗透测试工程师的判断力和创造力但可以把重复劳动的时间省下来让你有更多精力去思考真正复杂的问题。最后分享一个小心得Claude在分析请求的时候如果你能把目标站点的业务背景告诉它比如这是一个电商站点重点关注订单和支付相关的接口它的判断准确率会明显提高。业务上下文越丰富Agent的表现越好。这个和带新人一样你给的信息越具体他上手越快。
阅读完成 · 觉得有帮助？
