之前在做授权渗透测试巡检时,经常要重复处理登录、翻页、抓取响应、核对接口参数这类操作。纯手工效率低,写脚本又容易因为页面结构调整而失效。后来尝试把 AI Agent 和浏览器 MCP 组合起来,用自然语言驱动浏览器自动执行安全检测流程,效果比想象中好很多。本文围绕“DeepSeek Harness + 浏览器 MCP”这套链路,完整拆解安装配置、核心原理、授权测试场景实践,以及 WebShell 与数据库凭据检测的自动化思路。适合对 AI Agent、MCP 协议和安全测试自动化感兴趣的开发者一起交流。
1. 背景与核心概念
1.1 DeepSeek Harness 到底是什么
DeepSeek Harness 可以理解为一个面向 DeepSeek 模型的 AI Agent 工具框架。它把大模型本身的语言理解、规划、工具调用能力封装成工程可用的形态,支持在程序里编排任务、定义工具、管理多轮对话上下文。
用一句话概括:DeepSeek 负责“想”,Harness 负责“做”。
在原生模型状态下,DeepSeek 只能基于训练数据和输入的上下文生成文本,没办法直接打开浏览器、读取页面 DOM、点击按钮。而 Harness 这类 Agent 框架补齐了模型与真实系统之间的连接,模型可以输出调用指令,框架负责执行并返回结果。
浏览器 MCP 是这套链路里的另一个关键角色。MCP(Model Context Protocol,模型上下文协议)是 Anthropic 提出的一种标准化协议,目的是让 AI 模型可以统一接入外部工具和数据源。MCP 把浏览器能力封装成工具列表,模型通过调用这些工具完成打开 URL、输入文本、点击元素、执行 JavaScript、读取响应头等操作。
1.2 浏览器 MCP 在安全测试中的价值
Web 安全测试为什么需要浏览器自动化?因为大量安全问题都发生在浏览器可交互的页面里,例如登录表单、文件上传接口、权限校验按钮、响应头缺失等。如果交给人工测试,流程极其繁琐;如果交给传统爬虫脚本,又很难应对前端渲染、复杂交互和反爬逻辑。
浏览器 MCP 提供的是一层更通用的控制面。它并不关心页面是 Vue、React 还是传统服务端渲染,只要浏览器能渲染出来,MCP 工具就能操作。对于授权渗透测试和日常安全巡检来说,这意味着可以用 AI 自然语言指令完成以下事情:
- 自动访问目标页面并完成登录。
- 分析页面中的表单控件、请求 URL、隐藏字段。
- 提取浏览器 Network 面板里的关键请求和响应。
- 在隔离环境里观察文件上传后的响应返回。
- 检测页面中是否存在可能的 WebShell 特征字符串。
- 辅助排查前端 JS 中硬编码的数据库连接凭据。
需要特别强调的是,本文所有案例都基于本地靶场或明确授权的测试环境。任何针对未授权目标的扫描、探测、验证利用都属于违规行为,轻则违反平台安全规范,重则触犯法律。本文的目的不是指导入侵,而是帮助安全工程师在红队授权测试、蓝队应急响应和日常巡检场景中提高效率。
1.3 本文的阅读收益
读完这篇文章,你会掌握以下内容:
- 了解 MCP 和浏览器 MCP 服务器的核心概念与配置方式。
- 能看懂 DeepSeek Harness 注册外部 MCP 工具的基本思路。
- 能搭建一个最小可用的 AI 浏览器自动化环境。
- 学会在本地 DVWA 靶场上用 AI 自动做登录和风险分析。
- 知道如何用 AI 辅助检测 WebShell 和数据库密码硬编码问题。
- 掌握这类工具在落地时的常见报错、排查思路和最佳实践。
下面进入正题。
2. 环境准备与版本说明
2.1 运行环境要求
在开始之前,需要先准备好一套可运行的环境。不同机器的系统环境有差别,下面是建议的软硬件基线:
| 类别 | 建议要求 | 说明 |
|---|---|---|
| 操作系统 | Windows 10/11、Ubuntu 20.04+、macOS 12+ | 本文示例以 Ubuntu 为主 |
| Node.js | 18.0 以上 | MCP 客户端和浏览器服务器依赖 Node.js |
| Python | 3.10 以上 | 部分 Agent 框架脚本和检测脚本用 Python |
| 浏览器 | Chrome 或 Chromium | 浏览器 MCP 一般基于 Chromium 控制 |
| DeepSeek API Key | 可调用 DeepSeek 模型的 Key | 在环境变量中配置 |
| 内存 | 建议 8GB 以上 | 浏览器实例和模型推理对资源有要求 |
这里需要说明,DeepSeek Harness 本身属于高速迭代的工程工具,安装方式、配置文件字段、命令行参数可能随版本变化。本文不会刻意写死某个固定的安装包名,而是以“通用 Agent 项目”的方式讲解安装思路。真正操作时,请以你拉取到的仓库 README 为准。
2.2 安装 Node.js 与 Python 环境
浏览器 MCP 服务器大多基于 Node.js 开发,因此必须确保本机有 Node.js。
在 Ubuntu 环境下,可以通过 nvm 安装:
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 18 node -v npm -v在 Windows 环境下,可以直接从 Node.js 官网下载 msi 安装包,或者使用 winget 安装:
winget install OpenJS.NodeJS.LTS接着创建 Python 虚拟环境,用于后续运行检测脚本:
mkdir -p ~/ai-sec-browser cd ~/ai-sec-browser python3 -m venv venv source venv/bin/activate2.3 安装 DeepSeek Harness
DeepSeek Harness 的安装方式需要参考项目当前提供的说明。为了避免散落不同版本的命令混淆,这里给出通用的 Python 项目安装过程:
git clone https://your-repo-host/deepseek-harness.git cd deepseek-harness python -m venv venv source venv/bin/activate pip install -r requirements.txt如果你的环境支持一键安装命令,也可以直接使用 pip 或 npm 对应的包管理命令。安装完成后,建议先运行一个快速验证命令,确认框架能够启动:
deepseek-harness --version如果命令不存在,请回到项目 README 检查路径是否加入了系统 PATH。
2.4 配置 DeepSeek API Key
AI Agent 的核心能力来自大模型,因此需要配置 DeepSeek 的 API Key。在项目根目录下创建.env文件:
touch .env内容如下:
DEEPSEEK_API_KEY=sk-你的密钥 DEEPSEEK_BASE_URL=https://api.deepseek.com部分 Agent 框架还会用到模型名称配置,例如:
DEEPSEEK_MODEL=deepseek-chat不同版本的模型名称可能不同,建议以 DeepSeek 官方文档为准。配置完成后,重新启动终端或执行source .env让环境变量生效。
3. 浏览器 MCP 核心配置与原理解析
3.1 MCP 协议的工作方式
MCP 协议把外部能力抽象为“服务器”和“工具”。模型侧通过 Agent 框架与 MCP 服务器建立通信,获取可用工具列表;当模型决定调用某个工具时,Agent 框架会把参数传给服务器,服务器执行具体动作后返回结果。
浏览器 MCP 服务器做的事情就是接收“打开页面”“点击元素”“获取文本”这类指令,并和实际浏览器实例交互。常见的落地实现有两种:
- 基于 Puppeteer 控制 Chrome 或 Chromium。
- 基于 Playwright 控制多个浏览器内核。
具体选择哪种,取决于你的目标浏览器和稳定性要求。Puppeteer 的生态更成熟,Playwright 对多浏览器支持更好。
3.2 创建 MCP 配置文件
DeepSeek Harness 通常支持通过 JSON 或 JSONC 文件声明 MCP 服务器。下面是一个典型的浏览器 MCP 配置:
{ "mcpServers": { "browser": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-puppeteer" ], "env": { "NODE_ENV": "development" } } } }这个配置表示:启动一个名为browser的 MCP 服务器,使用npx运行 Puppeteer 官方 MCP 服务器包。
如果你的网络环境访问 npm 比较慢,可以先把包下载到本地:
npm install -g @modelcontextprotocol/server-puppeteer然后将配置修改为:
{ "mcpServers": { "browser": { "command": "mcp-server-puppeteer", "args": [], "env": {} } } }3.3 浏览器 MCP 暴露的常见工具
不同 MCP 服务器暴露的工具名会有差异,但通常覆盖以下几类:
| 工具名 | 用途 | 典型参数 |
|---|---|---|
browser_navigate | 打开一个 URL | url |
browser_click | 点击页面元素 | selector |
browser_fill | 填充表单 | selector,value |
browser_screenshot | 截图 | path,type |
browser_evaluate | 在页面执行 JS | script |
browser_get_content | 获取页面文本 | 无 |
browser_get_cookies | 获取 Cookie 信息 | 无 |
browser_list_network_requests | 查看网络请求 | 无 |
模型并不需要记住所有工具,Agent 框架会在对话开始时自动加载工具列表。这个过程有点类似 Function Calling,模型根据用户的任务描述挑选合适的工具和参数。
3.4 底层通信链路
为了让后续排错更容易,这里画一个简单的链路图:
你(自然语言) -> DeepSeek Harness Agent -> MCP 客户端 -> 浏览器 MCP 服务器 -> Chrome / Chromium 实例 -> 页面渲染、网络请求、JS 执行当浏览器 MCP 服务器启动后,它会在本地建立一个子进程,连接到一个可用的 Chromium 实例。后续所有工具调用都会映射成 CDP(Chrome DevTools Protocol)指令。理解这条链路很重要,因为后续大多数连接失败、页面打不开的问题,都可以定位到链路某一环。
4. 在 DeepSeek Harness 中注册浏览器 MCP
4.1 创建项目结构
为了便于管理,建议建立清晰的项目目录:
ai-sec-browser/ ├── .env ├── mcp-config.json ├── agent_runner.py ├── detect_webshell.py └── prompts/ └── dvwa_scan.md其中:
mcp-config.json存放 MCP 服务器配置。agent_runner.py是启动 Agent 的入口脚本。detect_webshell.py是 WebShell 特征扫描脚本。prompts/dvwa_scan.md保存用于靶场检测的提示词。
4.2 用 Node.js 验证 MCP 客户端
在正式接入 DeepSeek Harness 之前,我们可以先用 Node.js 的 MCP SDK 验证浏览器 MCP 是否可以正常通信。创建一个test_mcp.mjs文件:
// test_mcp.mjs import { Client } from "@modelcontextprotocol/sdk/client/index.js"; import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js"; const transport = new StdioClientTransport({ command: "npx", args: ["-y", "@modelcontextprotocol/server-puppeteer"] }); const client = new Client({ name: "browser-test", version: "1.0.0" }); await client.connect(transport); const tools = await client.listTools(); console.log("已连接 MCP 服务器,可用工具:"); tools.forEach((tool) => { console.log(`- ${tool.name}: ${tool.description}`); }); const result = await client.callTool({ name: "browser_navigate", arguments: { url: "https://example.com" } }); console.log("打开页面结果:", result); await client.close();运行命令:
node test_mcp.mjs如果配置正确,你会看到类似输出:
已连接 MCP 服务器,可用工具: - browser_navigate: 打开指定 URL - browser_click: 点击页面元素 ... 打开页面结果:页面加载成功注意,MCP SDK 的包名和方法名可能随版本更新,如果方法不匹配,请参考当前版本文档。
4.3 编写 Agent 启动脚本
当你确认 MCP 客户端可以连接后,下一步就是把浏览器 MCP 注册到 DeepSeek Harness 的 Agent 里。下面是一个面向常见 Agent 框架的示例脚本思路:
# agent_runner.py import os from dotenv import load_dotenv load_dotenv() # 以下代码是核心思路,需要根据你使用的 Agent 框架 API 调整 from deepseek_harness import DeepSeekAgent, load_mcp_config config = load_mcp_config("mcp-config.json") agent = DeepSeekAgent( model=os.getenv("DEEPSEEK_MODEL", "deepseek-chat"), api_key=os.getenv("DEEPSEEK_API_KEY"), mcp_servers=config ) agent.system_prompt = """ 你是一名在授权测试环境中的安全分析助手。 你只能访问本地靶场或已经获得授权的目标。 在分析任务时,你可以使用浏览器工具查看页面、填写表单、提取内容。 禁止修改目标系统数据,禁止上传任何文件,禁止对未授权目标执行主动测试。 """ result = agent.run("访问 http://localhost:8080/DVWA/login.php 并完成登录") print(result)由于 DeepSeek Harness 本身迭代较快,这里的DeepSeekAgent、load_mcp_config不一定与某个具体版本完全一致。重点是理解:Agent 框架负责将mcp-config.json中声明的工具加载到模型上下文里,模型只负责生成工具调用,真正执行操作的是浏览器 MCP 服务器。
如果框架不支持自动加载 MCP 配置,也可以手动把需要调用的工具名称和参数规则写进 System Prompt。虽然不够优雅,但在最小原型验证阶段够用。
4.4 验证浏览器操作
启动脚本后,可以要求 Agent 执行一个简单任务:
请用浏览器打开 http://localhost:8080/DVWA/login.php,输出页面标题和是否有登录表单。预期流程:
- Agent 调用
browser_navigate打开目标 URL。 - Agent 调用
browser_get_content获取页面内容。 - Agent 分析页面内容,输出登录表单和标题信息。
如果页面里的输入框有固定的name或id,也可以让 Agent 完成自动填充:
请使用 admin / password 作为测试凭据,在登录表单中自动填入并登录,但不要点击提交后的任何功能模块。这里再次强调,只允许在靶场或授权系统中操作。真实系统中的账号密码写入提示词属于敏感行为,生产环境不要这样做。
5. 授权测试实战:AI 自动登录 DVWA 并分析风险
5.1 DVWA 靶场准备
DVWA(Damn Vulnerable Web Application)是一个专门用于安全训练的靶场应用,适合测试浏览器 MCP 的自动化能力。
假设 DVWA 已经运行在http://localhost:8080/DVWA/,默认登录凭据是admin/password。通过浏览器手动验证可以访问后,再交给 AI 自动操作。
如果本机还没有 DVWA,可以快速启动一个 Docker 容器作为测试环境:
docker run -d -p 8080:80 vulnerables/web-dvwa启动后,首次访问需要点击“Create / Reset Database”。这个动作用手点更快,也可以让 AI 操作,但需要确保提示词明确。
5.2 设计 AI 扫描提示词
下面是一份面向 DVWA 登录页面的提示词模板,可以存放在prompts/dvwa_scan.md:
你是一个 Web 安全测试助手,当前目标为授权的本地靶场 DVWA。 任务步骤: 1. 用浏览器工具打开 http://localhost:8080/DVWA/login.php 2. 获取页面中的表单字段信息,判断是否存在用户名和密码输入框 3. 使用 admin / password 登录 4. 登录成功后,访问 http://localhost:8080/DVWA/vulnerabilities/upload/ 页面 5. 仅观察页面结构和提交接口,不做任何文件上传 6. 输出以下信息: - 页面是否可以正常访问 - 是否存在文件上传接口 - 接口是否有任何可见的防护提示这份提示词把 AI 的行为限制在“观察和读取”,不涉及主动攻击。实际渗透测试过程中,很多信息收集工作完全可以通过这种方式自动完成。
5.3 运行并观察输出
在项目目录执行:
python agent_runner.py如果 Agent 支持交互式输入,也可以进入交互模式后手动粘贴提示词。预期运行结果类似:
[2025-06-01 10:23:11] 正在打开 http://localhost:8080/DVWA/login.php [2025-06-01 10:23:12] 页面标题: Login :: Damn Vulnerable Web Application [2025-06-01 10:23:12] 检测到用户名输入框: name='username' [2025-06-01 10:23:12] 检测到密码输入框: name='password' [2025-06-01 10:23:12] 开始登录... [2025-06-01 10:23:18] 登录成功,当前 Cookie 有效 [2025-06-01 10:23:18] 正在访问上传页面... [2025-06-01 10:23:20] 发现上传接口: /DVWA/vulnerabilities/upload/ [2025-06-01 10:23:20] 页面存在前端限制(仅允许图片上传)这个输出说明浏览器 MCP 成功完成了整条链路。值得注意的是,很多真实站点会在前端隐藏“高危按钮”,只有登录用户或特定角色才看得到。AI 通过浏览器操作可以模拟这种身份行为,比单纯发送 HTTP 请求更接近实际攻击者视角。
5.4 在结果中隐藏风险
对于安全工程师来说,AI 自动登录后再读取页面的意义不仅仅是省人工,更在于可以持续监控页面变化。例如:
- 监听登录页面是否有异常改动。
- 检测上传页面是否新增了奇怪的表单字段。
- 分析页面是否引入了可疑的外部 JavaScript。
- 查看响应头里有没有安全头缺失。
这些都可以通过浏览器 MCP 的browser_evaluate工具执行脚本,或者配合 Network 请求列表完成。
下面是一个让 AI 提取页面中所有外部脚本地址的提示词示例:
请分析当前页面的所有 <script> 标签,列出外部 src URL,并标记哪些域名与主站域名不同。AI 可以通过browser_evaluate执行如下脚本:
Array.from(document.querySelectorAll('script[src]')).map(s => s.getAttribute('src'))然后 AI 对结果做域名比对,并输出可疑项。这个能力在排查页面篡改和供应链攻击时非常实用。
6. AI 辅助 WebShell 与数据库凭据检测
6.1 为什么把 WebShell 检测交给 AI
标题里提到的“冰蝎 WebShell”“一句话木马”并不是鼓励你使用,而是安全工程师在做应急响应或红队验证时需要掌握的一类风险特征。WebShell 本质上是一个部署在 Web 目录下的恶意脚本,攻击者上传后,可以通过 HTTP 请求执行系统命令或数据库操作。
在过去,蓝队工程师需要在一堆日志和文件里人工寻找可疑脚本,工作量很大。现在,AI 可以辅助完成以下工作:
- 扫描目录中是否存在常见的一句代码特征。
- 分析可疑 PHP/JSP 文件的代码逻辑。
- 在网络流量中识别加密后门工具的特征。
- 定位数据库配置文件中是否硬编码了明文密码。
下面这个 Python 脚本可以从文件特征层面辅助检测 WebShell:
# detect_webshell.py import re from pathlib import Path import sys webshell_patterns = [ r"(?i)@\s*eval\s*\(\s*\$_", r"(?i)(assert|system|exec|shell_exec|passthru)\s*\(\s*\$_", r"(?i)base64_decode\s*\(\s*[\"']", r"(?i)gzinflate\s*\(\s*base64_decode", r"(?i)str_replace\s*\(\s*[\"']", r"(?i)call_user_func\s*\(\s*\$_", ] def scan_path(path): file_count = 0 hit_count = 0 target_exts = {".php", ".asp", ".aspx", ".jsp", ".jspx"} for p in Path(path).rglob("*"): if not p.is_file(): continue if p.suffix.lower() not in target_exts: continue file_count += 1 try: text = p.read_text(encoding="utf-8", errors="ignore") except Exception: continue for pattern in webshell_patterns: if re.search(pattern, text): hit_count += 1 print(f"[!] 命中模式: {pattern}") print(f" 文件: {p}") print(f"扫描完成,共检查 {file_count} 个文件,命中 {hit_count} 个可疑模式。") if __name__ == "__main__": if len(sys.argv) < 2: print("用法: python detect_webshell.py <目录>") sys.exit(1) scan_path(sys.argv[1])运行方式:
python detect_webshell.py /var/www/html需要注意的是,正则命中只是“可疑”,不代表文件一定是 WebShell。误报很常见,例如某些合法的加密函数、混淆代码也会触发正则。推荐的做法是把扫描结果交给 AI 二次分析,由 AI 判断代码上下文是否真的存在危险调用链。
6.2 冰蝎流量的检测思路
冰蝎是一款基于加密流量的 WebShell 管理工具。攻击者上传服务端后,客户端会通过加密通信发送命令。冰蝎的流量特征比较隐蔽,但也并非无迹可循。在授权测试或应急响应中,可以通过以下几个方面辅助分析:
- 服务端连接路径通常是一个隐藏在正常站点中的
.php或.jsp文件。 - 请求和响应内容经过加密处理,载荷看起来像随机字节。
- 部分版本存在固定的请求头或响应头特征。
- 连接过程中可能存在与常规业务明显不同的请求频率。
浏览器 MCP 在这里的用途是:当 AI 分析到一个可疑 WebShell 文件时,它可以打开对应 URL,观察页面返回内容,甚至主动模拟一次无害的请求来观察响应特征。但必须强调的是,连接真实攻击者的 WebShell 属于危险操作,只能在隔离的应急响应环境中进行,并且需要严格授权。
6.3 数据库密码硬编码检测
数据库密码泄露是另一个需要关注的问题。很多 Web 应用在部署时,会把数据库连接字符串写在前端 JavaScript、配置文件或代码仓库中。AI 可以通过浏览器 MCP 提取页面源码和 Network 请求中的可疑字符串。
例如提示词:
请检查当前页面以及所有加载的 JavaScript 文件,搜索是否存在类似 password、passwd、pwd、connectionString、jdbc: 等敏感关键字,并输出可疑字段。下面是一个用于本地代码扫描的脚本片段:
# scan_hardcoded_secrets.py import re from pathlib import Path secret_pattern = re.compile( r"(?i)(password|passwd|pwd|secret|api[_-]?key)\s*[:=]\s*[\"'][^\"']{6,}[\"']" ) def scan_dir(path): for p in Path(path).rglob("*"): if p.suffix.lower() not in {".js", ".ts", ".py", ".php", ".env", ".properties", ".yaml", ".yml"}: continue try: text = p.read_text(encoding="utf-8", errors="ignore") except Exception: continue for m in secret_pattern.finditer(text): print(f"{p}:{m.start()} -> {m.group(0)}")这类扫描脚本本身不复杂,但真正有价值的是把结果和 AI 分析结合起来,让 AI 判断哪些是测试数据、哪些是真实生产环境的敏感凭据、哪些误报可以忽略。
6.4 把检测脚本接入 Agent
理论上,你可以把上面的 Python 脚本封装成一个 MCP 工具,让 DeepSeek Harness 在需要时调用。但这一步对新人来说成本略高。更简单的做法是:
- 先用脚本扫描文件目录,生成结果文本。
- 再把结果文本粘贴给 AI 分析。
- AI 输出风险评估和修复建议。
例如:
下面是目录扫描到的可疑命中文档,请逐条分析是真实风险还是误报,并给出处理建议: [在此粘贴扫描结果]这种方式在工程上实现成本低,也符合当前大多数 Agent 框架的工具调用范围。
7. 常见问题与排查思路
7.1 MCP 连接失败
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
spawn npx ENOENT | Node.js 未安装或 npx 不在 PATH | 检查node -v,重新安装 Node.js |
| MCP 服务器连接超时 | 网络无法访问 npm 仓库 | 手动下载并配置本地命令 |
| 浏览器不启动 | Chrome 或 Chromium 未安装 | 安装 Chrome,或配置executablePath |
| 权限不足 | 浏览器无法创建用户目录 | 指定独立的--user-data-dir |
| 端口冲突 | Puppeteer 默认端口被占用 | 增加--no-sandbox或更换端口 |
| Agent 找不到工具列表 | MCP server 路径配置错误 | 验证 JSON 配置,检查日志 |
排查顺序建议:先跑通 Node.js 的test_mcp.mjs,确认 MCP 本身没问题,再回到 DeepSeek Harness 排查 Agent 注册逻辑。这样能把问题隔离在某一层。
7.2 浏览器无头模式不稳定
很多服务端环境没有图形界面,需要启用无头模式。Puppeteer MCP 默认可能会启动有头浏览器,如果部署在纯命令行服务器上,需要在环境中配置:
{ "mcpServers": { "browser": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-puppeteer" ], "env": { "HEADLESS": "true", "PUPPETEER_SKIP_CHROMIUM_DOWNLOAD": "false" } } } }如果页面需要登录,并且涉及证书等复杂操作,建议把浏览器配置成“有头 + 手动登录一次并保存状态”的方式,再交给 AI 自动化。这样在本地调试时更直观,也能减少 AI 误解页面的概率。
7.3 AI 对页面元素定位不准
浏览器 MCP 的点击和填充依赖选择器。如果页面元素是动态渲染的,AI 可能找不到目标。解决办法有:
- 在提示词里明确告诉 AI 页面元素的
name、id或>如果发现当前 URL 与预期不符,先获取当前 URL,分析页面内容,再决定是否需要重新登录。这种简单的指令可以显著提高容错率。
8. 最佳实践与工程建议
8.1 合法授权是绝对前提
任何时候运行 AI 浏览器自动化,都必须确保你有权限访问目标系统。最稳妥的做法是:
- 只在本地靶场、CTF 平台或公司明确授权的测试环境中操作。
- 不在 ChatGPT、公开 API 中传入真实系统敏感数据。
- 对所有测试行为保留操作日志和授权文件。
对于安全工程师来说,授权不仅是合规要求,也是保护自己职业生涯的底线。
8.2 最小权限原则
和人工渗透测试一样,AI 自动化也要遵循最小权限:
- 浏览器使用独立的测试账号,不要复用生产管理员账号。
- 使用临时 Cookie 或 Session,测试结束后立即失效。
- 脚本运行环境使用 Docker 容器,避免污染宿主机文件系统。
- 扫描脚本只读文件,不修改业务数据。
8.3 让 AI 输出结构化报告
在真实团队协作中,AI 的临时输出价值有限,最好让它生成结构化报告。例如:
请用表格格式输出扫描结果,包含:目标URL、风险级别、问题描述、复现步骤、修复建议。结构化报告方便提交给开发团队,也方便后续自动化归档。
8.4 日志监控与审计
浏览器 MCP 的每一次操作都可以记录到日志里。建议至少记录以下字段:
- 操作时间。
- 调用的 MCP 工具名。
- 传入的参数。
- 返回值摘要。
- AI 的思考过程。
通过日志,你可以在 AI 出现误操作时快速定位原因。同时,日志也是安全审计的重要依据。
8.5 敏感信息不外传
浏览器 MCP 会读取页面源码、Cookie、Network 请求。这些内容很可能包含敏感数据。需要注意:
- 不要在提示词里直接写入生产数据库密码。
- 不要让 AI 把页面内容发送到外部服务。
- 如果使用云端大模型 API,要提前做数据脱敏。
对于高安全级别项目,建议部署本地模型版本,或者通过内部网关对 API 请求做内容过滤。
8.6 从脚本知识库到 Agent 知识库
常见的 Web 安全检测知识点是相对稳定的。你可以把这些知识沉淀到提示词模板中,让 AI 遇到同类问题时自动调用。例如:
- SQL 注入检测先从参数点和报错信息入手。
- XSS 检测关注反射点与编码链路。
- WebShell 检测优先观察上传接口的响应特征。
- 数据库凭据泄露检测优先检查环境变量和配置文件。
把规则、经验变成 Agent 的工具调用链,这是比单纯写一次性爬虫更有长期价值的事情。
9. 总结与下一步学习方向
本文围绕 DeepSeek Harness 和浏览器 MCP 的组合,介绍了 AI Agent 如何接管浏览器完成授权安全测试场景下的自动化操作。内容包括 MCP 协议的核心概念、环境搭建、浏览器 MCP 服务器的配置、Agent 启动脚本、DVWA 靶场自动登录、WebShell 特征扫描、数据库密码硬编码检测,以及常见问题排查和工程最佳实践。
如果你对这套链路感兴趣,下一步可以根据自己的角色继续深入:
- 如果是开发背景,建议研究 MCP 协议源码,尝试自己开发一个浏览器工具插件。
- 如果是安全工程师,建议把本文的检测脚本封装成可复用的 Web 服务,再通过 HTTP 方式与 Agent 对接。
- 如果你是团队负责人,可以考虑搭建一套基于 AI 的安全巡检流水线,定时用浏览器 MCP 巡检核心业务页面,发现页面异常时自动通知。
最后提醒一句:AI 很强大,但也只是工具。浏览器 MCP 让 AI 拥有了“手”和“眼睛”,真正决定它用途的,始终是使用者自己。在授权范围内进行测试和防御,这套技术能成为安全建设的助推器;一旦越过边界,后果也会很严重。希望这篇文章能给你带来实用的工程思路,也欢迎在评论区聊聊你在 AI Agent 自动化测试中踩过的坑和经验。