【免费下载链接】hermes-workspaceNative web workspace for Hermes Agent — chat, terminal, memory, skills, inspector.项目地址https://gitcode.com/gh_mirrors/he/hermes-workspace点击查看免费下载Hermes Workspace 是一个面向 Hermes Agent 的本地 Web 工作区chat、terminal、memory、skills、inspector 一站式管理。本文以仓库根目录的 SECURITY.md 为骨架结合src/server/、src/routes/api/等源码实现系统梳理该项目 v3.0.0 的安全模型从漏洞上报流程与版本支持策略到认证会话、CSRF、CORS、限流、路径穿越防护、Agent 安全与配置安全并给出可验证的源码级证据。读完本文你将能理解该工作区“本地优先、服务端掌控密钥、全路由鉴权、fail-closed”的纵深防御思路并可直接对照源码核验每一道防线。一、漏洞上报渠道与响应承诺SECURITY.md 开篇即明确了本项目接受安全漏洞报告的规范流程禁止公开渠道披露不得在公开 Issue 中提交安全漏洞避免 0-day 被恶意利用。私密上报渠道通过 GitHub Security Advisories 提交或直接私信维护者。响应 SLA收到报告后48 小时内确认对关键critical漏洞目标在7 天内提供修复。从仓库结构看该流程属于社区协作契约仓库侧未包含自动化的漏洞反馈端点因此实际 SLA 以维护者响应为准。漏洞范围界定Scope / Out of Scope范围内需向本项目报告范围外分别上报各自项目Hermes Workspace Web 应用代码Hermes Agent 本体API 路由与 Claude 通信层第三方依赖交给对应维护者认证与会话管理社会工程攻击客户端数据处理与渲染—Exec 审批与 human-in-the-loop 控制—浏览器代理与截图端点—范围界定说明Hermes Workspace 本身不实现 Agent 的推理内核而是作为其网关与管理界面存在因此 Agent 侧漏洞与依赖库漏洞不在此仓库的修复范围内。二、支持版本矩阵版本支持状态v3.xmain✅ 活跃支持v2.x⚠️ 仅安全修复 v2.0❌ 不再支持安全审计与加固措施如全路由认证以v3.0.0 为分水岭v3.0.0 之后提交的新代码默认必须满足下述安全基线。需要留意的是仓库根 README.md 顶部的版本徽章显示的是 2.x 时代的发布版本而 SECURITY.md 已将 v3.x 定义为当前主线安全策略请以 SECURITY.md 为准。三、认证与会话安全v3.0.0SECURITY.md 列出了四项认证基线全部可在源码中找到对应实现1. 所有 API 路由强制认证v3.0.0 起所有 API 路由默认要求认证。认证中间件集中在 src/server/auth-middleware.ts任何未携带有效会话的请求都会被拦截避免“少配一条路由就裸奔”的经典疏漏。SEC-3 审计中还专门核验了/api/config-get、/api/debug-analyze、/api/context-usage、/api/paths等容易遗漏的高危端点均已覆盖鉴权。2. 定时安全比较Timing-Safe Comparison密码与令牌校验使用node:crypto的timingSafeEqual防止通过响应时间差异猜测密码。实现位于 src/server/auth-middleware.ts// Timing-safe comparison const passwordBuf Buffer.from(password, utf8) const configuredBuf Buffer.from(configured, utf8) // If lengths differ, still do a comparison to avoid timing leak if (passwordBuf.length ! configuredBuf.length) { return false } try { return timingSafeEqual(passwordBuf, configuredBuf) } catch { return false }注意注释中的关键细节即使长度不同也立即返回false而非抛错避免通过“长度不同时的异常/耗时差异”泄露密码长度信息。3. httpOnly SameSiteStrict Cookie会话令牌以 Cookie 形式下发属性包含httpOnlyJS 无法读取与SameSiteStrict跨站请求不带 Cookie构成 CSRF 的第一道防线。相关代码见 src/server/auth-middleware.ts// SameSiteStrict — CSRF protection attrs.push(SameSiteStrict, Path/, Max-Age${30 * 24 * 60 * 60})会话 Cookie 名为claude-auth由 getSessionTokenFromCookie 解析。对应的 src/server/auth-middleware.test.ts 中明确断言响应 Cookie 必须包含SameSiteStrict将此策略固化为回归测试。4. 登出即撤销令牌注销操作会立即使当前会话令牌失效杜绝“登出后令牌仍可复用”的会话残留风险。密码配置的兼容细节从源码看密码读取同时兼容两个环境变量getConfiguredPassword 优先读HERMES_PASSWORD重命名后的现行变量名回退到CLAUDE_PASSWORD重命名前遗留保证存量部署升级不受影响。只有当密码非空时鉴权才生效isPasswordProtectionEnabled。四、CSRF 防护requireJsonContentTypeSEC-3 审计将 CSRF 内容类型强制requireJsonContentType补到了所有 POST 处理器上包括 auth 与终端管理端点。其原理位于 src/server/rate-limit.tsexport function requireJsonContentType(request: Request): Response | null { const method request.method.toUpperCase() if (method GET || method HEAD || method OPTIONS) return null const ct request.headers.get(content-type) ?? if (ct.includes(application/json)) return null return new Response( JSON.stringify({ error: Content-Type must be application/json }), { status: 415, headers: { Content-Type: application/json } }, ) }为什么这能防 CSRF浏览器发起的跨站表单/导航请求不会携带Content-Type: application/json——该头只能由程序化调用fetch、curl显式设置。因此拒绝非 JSON 的写请求即可将“跨站自动提交表单”这类攻击挡在门外。写接口未通过校验会收到415 Unsupported Media Type。测试证据src/routes/api/-mcp.test.ts 覆盖了requireJsonContentType的正反用例——不带 JSON 头返回 415带application/json通过GET 请求直接放行。该函数被 src/routes/api/auth.ts、conductor-spawn.ts 等大量路由复用属于全局写操作闸门。五、网络层防线CORS、同源限制与限流1. CORS 无通配符SECURITY.md 明确Access-Control-Allow-Origin仅允许 localhost禁止*通配符。这使得部署在工作区机器上的服务不会被任意网页跨域读取。注意 playground-ws-worker/src/worker.ts 中的 Cloudflare Worker 示例使用了*但那属于隔离的公开 playground 服务不承载工作区私密数据与主应用同源策略无关。2. 浏览器代理与截图端点锁定同源浏览器代理browser proxy与截图screenshot端点仅允许同源访问防止这些可执行远程浏览的能力被第三方站点当作开放代理滥用。3. 滑动窗口限流10 次/分钟/IP限流器实现在 src/server/rate-limit.ts是零依赖的内存滑动窗口实现export function rateLimit( key: string, maxRequests: number, windowMs: number, ): boolean { const now Date.now() let entry store.get(key) if (!entry) { entry { timestamps: [] } store.set(key, entry) } // Remove timestamps outside the window entry.timestamps entry.timestamps.filter((t) now - t windowMs) if (entry.timestamps.length maxRequests) { return false } entry.timestamps.push(now) return true }超限时返回标准的429 Too Many RequestsrateLimitResponse。SEC-3 将高危端点收紧到10 次/分钟/IP/api/terminal-input终端注入/api/terminal-stream终端流/api/restart服务重启/api/update-checkPOST更新检查4. 客户端 IP 提取的防伪造细节限流按 IP 为 key但直接信任x-forwarded-for头会被攻击者轻易轮换限流 key仓库注释明确记录了 issue #125。因此 getClientIp 仅在设置了TRUST_PROXY1/true/yes时才信任转发头否则回退到真实 socket 地址或local桶——只有在部署于可信反向代理Traefik、Nginx、Cloudflare之后才应开启TRUST_PROXY。5. 生产环境错误信息脱敏safeErrorMessage 在NODE_ENVproduction下将一切异常统一替换为Internal server error防止堆栈与内部路径通过 API 响应泄露给客户端。六、数据与文件访问路径穿越防护与最小权限1. ensureWorkspacePath防御 #121 回归漏洞SECURITY.md 明确所有文件与 memory 路由通过ensureWorkspacePath()防路径穿越。核心实现在 src/routes/api/files.tsfunction ensureWorkspacePath(input: string, workspaceRoot: string) { const raw input.trim() if (!raw) return workspaceRoot const resolved path.isAbsolute(raw) ? path.resolve(raw) : path.resolve(workspaceRoot, raw) if (resolved workspaceRoot) return resolved const relative path.relative(workspaceRoot, resolved) if ( !relative || relative.startsWith(..) || relative .. || path.isAbsolute(relative) ) { throw new Error(Path is outside workspace) } return resolved }关键点校验基于path.relative计算出的规范化相对路径——若结果以..开头、等于..或仍为绝对路径一律拒绝。这正是对历史漏洞#121的修复此前用朴素的startsWith()判断前缀攻击者可通过../或路径归一化绕过。回归测试见 src/routes/api/-files.test.ts文件头注释写明“Regression tests for #121 — path traversal via naive startsWith()”把该漏洞的修复固化为长期防护。ensureWorkspacePath被文件浏览、读取、写入、删除、移动、复制等全部文件操作files.ts统一调用属于“单一强制检查点”设计。MCP 侧的 trust 校验同样拒绝路径穿越与/tmp、~/.cache等敏感目录见 src/server/mcp-hub/trust.ts。2. memory 写路由仅允许 .mdMemory 写入路由限制只能写 Markdown 文件.md-only缩小了写入面即便写接口被滥用也无法向工作区注入可执行文件如 HTML/JS 后门。3. 密钥与诊断信息API Key 与密钥绝不进入客户端代码——前端拿不到任何供应商密钥Claude 令牌仅存于服务端由服务端统一代管与调用诊断输出对敏感数据做脱敏日志与诊断接口不落原始密钥。七、Agent 安全Exec 审批与技能扫描1. Exec 审批Human-in-the-LoopSECURITY.md 描述敏感的 Claude exec 命令需要显式人工审批通过 UI 内模态框modal确认后才能执行。这与 README 中“ Security — Auth middleware on every route, CSP, path-traversal guard, fail-closed remote bind”的能力清单相互印证。需要说明的是从当前仓库源码结构看src/lib/approvals-store.ts 目前是占位实现注释为 “Stub — exec approvals are not used in Hermes Workspace”说明该工作流主要由上游 Hermes Agent 网关侧驱动、工作区侧负责审批 UI 呈现实际生效链路以部署的 Agent 版本为准。2. 技能安全扫描来自技能市场的每个技能在安装前都会做可疑模式扫描。前端在 src/screens/skills/skills-screen.tsx 渲染扫描结果时展示了security.flags计数——“The skills code was scanned for common risk patterns. N item(s) noted.”即技能卡片会明确标注扫描出的风险模式数量安装决策基于可读的安全报告做出。八、配置安全SECURITY.md 的配置安全基线环境文件被 gitignore.env类文件不入库。安装流程见 README也是先cp .env.example .env再自行填写保证仓库内永远是模板而非真实密钥配置端点响应脱敏返回给前端的配置响应会 redact 凭据字段避免密码/令牌被 echo 回客户端示例配置仅用占位符.env.example 中的键值均为占位引导部署者替换为真实值而非直接可用。九、SEC-3 安全审计2026-02-25回顾SECURITY.md 记录的最近一次安全审计要点可作为理解当前安全基线的“验收清单”全 API 鉴权覆盖审计未发现新的私有路由鉴权缺口/api/config-get、/api/debug-analyze、/api/context-usage、/api/paths均已验证需要认证。CSRF 加固requireJsonContentType补全到剩余 POST 处理器含 auth 与终端管理端点源码证据见上文第四节。限流收紧高危端点统一为 10 次/分钟/IP滑动窗口端点列表为 terminal-input、terminal-stream、restart、update-check(POST)。十、部署自查清单综合 SECURITY.md 与源码实现给自部署者一份可对照执行的检查清单检查项依据操作密码已配置isPasswordProtectionEnabled仅在密码非空时启用鉴权设置HERMES_PASSWORD旧部署兼容CLAUDE_PASSWORD未误开代理信任TRUST_PROXY默认关闭仅当位于可信反向代理后设TRUST_PROXY1否则转发头可被伪造#125仅本机可达CORS 限制 localhost、浏览器代理/截图端点同源如需远程访问优先走 PWA Tailscale 而非暴露公网写接口走 JSON全部 POST/PUT/PATCH/DELETE 经requireJsonContentType集成/脚本调用必须带Content-Type: application/json不触碰工作区外路径ensureWorkspacePath统一校验文件/memory 操作若出现 Path is outside workspace 属预期拦截生产环境运行safeErrorMessage生产模式隐藏细节部署时设置NODE_ENVproduction环境文件不入库.envgitignored用.env.example复制后填真实值结语从 SECURITY.md 出发结合 auth-middleware.ts、rate-limit.ts、files.ts 等核心模块可以清晰看到 Hermes Workspace 的安全设计主线本地优先部署 全路由鉴权 fail-closed 的默认拒绝。认证、CSRF、CORS、限流、路径穿越、密钥隔离构成六道互补防线而 SEC-3 审计与针对 #121 的回归测试表明这些防线不是静态文档而是被测试固化的活代码。对于希望自托管该工作区的开发者将本文第十节的清单逐项落地即可获得文档承诺的安全基线。赞分享【免费下载链接】hermes-workspaceNative web workspace for Hermes Agent — chat, terminal, memory, skills, inspector.项目地址https://gitcode.com/gh_mirrors/he/hermes-workspace点击查看免费下载相关推荐HanaAgentopenhanako安全策略解析漏洞上报流程与本地凭证存储的防护机制HanaAgentopenhanako安全策略解析漏洞上报流程与本地凭证存储的防护机制 本篇技术指南围绕开源仓库 SECURITY.md https://人工智能AI AgentAI 应用桌面应用多智能体Agent 记忆AI 技能工具调用Wiki.js 安全机制全解安全策略、漏洞报告流程与防护实现Wiki.js 安全机制全解安全策略、漏洞报告流程与防护实现 Wiki.js 作为开源维基平台在 SECURITY.md https://link.gitc后端前端知识库知识管理WinBoat 安全策略漏洞报告流程与 Guest Server 防护机制解析WinBoat 安全策略漏洞报告流程与 Guest Server 防护机制解析 导读 本文基于 WinBoat 仓库的 SECURITY.md https:/桌面应用虚拟化上一篇12 款 Typora 主题怎么选DrakeTyporaTheme 搭配、安装与自定义速通指南下一篇Android设备桌面控制神器AYA全新交互体验指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考