wigolo 安全指南：漏洞报告流程、重点攻击面与防护实现解析

wigolo 安全指南漏洞报告流程、重点攻击面与防护实现解析【免费下载链接】wigoloThe go-to web for your AI coding agent — local-first search, fetch, crawl research over MCP. No API keys, no cloud, $0/query. Public beta.项目地址: https://gitcode.com/GitHub_Trending/wi/wigolo本文以 wigolo 仓库根目录下的 SECURITY.md 为骨架系统讲解该本地优先local-firstAI 检索与爬取工具的安全策略如何私密报告漏洞、哪些攻击面被列为重点关注领域、以及仓库源码中对应的防护实现。读完本文你将掌握 wigolo 的安全边界模型SSRF 防护、云 LLM 密钥托管、远程内容隔离并了解公测期间的支持版本策略。漏洞报告为什么必须走私有渠道wigolo 的 SECURITY.md 首先明确了安全问题的提交流程不要为安全漏洞打开公开 Issue。仓库的缺陷跟踪对所有人可见一旦漏洞细节暴露在公开 Issue 中恶意使用者可以在维护者发布补丁前利用它发起攻击即 zero-day 窗口被拉长。正确做法是使用仓库Security 选项卡下的Report a vulnerability功能该功能会创建一个只有报告者与维护者可见的私有 advisory。这与 GitHub 的 security advisory 工作流一致提交方与维护者可以在私有环境中反复沟通直到补丁就绪。报告时建议附上三类信息缺一不可漏洞描述及其影响范围——这个漏洞允许攻击者做什么影响数据机密性、完整性还是可用性复现步骤——尽可能提供最小化 proof of conceptPoC让维护者能在几分钟内复现而不是靠猜。受影响版本与运行环境——OS 类型、wigolo 版本、是否启用了 daemon/serve 模式、是否配置了代理或云 LLM 等。维护者承诺within a few days几天内给出初次响应并在补丁可用后与报告者协同披露coordinated disclosure。仓库对应的使用侧文档 docs/privacy-security.md 末尾也再次强调了同一通道Please dont open public issues for vulnerabilities。重点关注攻击面本地优先模型下的三块高风险区SECURITY.md 的 Scope notes 明确说明wigolo 是本地优先local-first软件运行在用户自己的机器上因此没有集中式服务端可作为攻击目标但本地运行恰恰意味着代码会主动向任意 URL 发起请求、读取并持久化远端内容这构成特有的攻击面。文档点名了三个特别受关注的领域可选的 watch/webhook 子系统SSRF 防护、URL 校验可选云 LLM 密钥的处理OS keychain / 加密文件任何抓取或爬取的远端内容影响宿主机的路径下面逐一结合源码剖析这三块的实际实现。攻击面一watch/webhook 子系统的 SSRF 防护watch工具会周期性地抓取用户指定的 URL并在页面内容变化时向 webhook 地址 POST 变更报告见 src/watch/scheduler.ts。如果 URL 校验缺失攻击者就能诱导 wigolo 进程访问内网服务或云元数据端点如169.254.169.254把本机作为 SSRF 跳板。这正是 SECURITY.md 把 watch/webhook 列为重点的原因。防护核心实现在 src/watch/ssrf.ts协议白名单只允许http:与https:file://、ftp://、gopher://、data:、javascript:等一律拒绝ALLOWED_PROTOCOLS。主机名/地址黑名单localhost、localhost.localdomain、metadata.google.internal等元数据别名IPv4 的 loopback127.0.0.0/8、0.0.0.0/8、RFC 1918 私网段10/8、172.16/12、192.168/16、link-local169.254/16IPv6 的::1、fe80::/10link-local、fc00::/7unique-local以及 IPv4-mapped / IPv4-compatible 的混合写法如::ffff:127.0.0.1、[::127.0.0.1]。稳定机器可读错误码每次拒绝都携带SSRF_CODES中的稳定 codessrf_invalid_url、ssrf_bad_protocol、ssrf_private_target、ssrf_metadataREST 错误适配层据此映射 HTTP 状态码避免人读文案变动导致状态映射漂移。watch 调度器把 SSRF 防护做成了**注册时校验 每次检查时重新校验的双闸门**任务注册时坏 URL 不会进入持久化状态而 runCheck 在每次抓取前会再次调用guardUrl同时校验被 watch 的url与 webhooknotification两个字段——如果策略收紧已持久化的旧任务也不会被 grandfathered豁免。更关键的是 webhook 投递的重定向防御deliverWebhook 使用redirect: manual任何 3xx 都被视为硬性投递错误。原因在注释中写得很清楚一个公网 webhook URL 在注册时能通过校验但如果目标服务器返回 307/308 重定向到http://127.0.0.1/admin默认的follow模式会让 Node fetch 静默地把 POST 转发到 loopback 目标从而在投递时刻绕过 SSRF 防护。针对这套防护的测试位于 tests/unit/watch/ssrf.test.ts如file:///etc/passwd→ssrf_bad_protocol、http://169.254.169.254/latest/meta-data/→ssrf_metadata、http://10.0.0.5/→ssrf_private_target、http://localhost:3000/api→ loopback 拒绝等集成层面另有 tests/integration/watch/watch-handler.test.ts 验证任务注册与投递全链路。攻击面二可选云 LLM 密钥的托管keychain → 加密文件 → envwigolo 允许用户接入可选的云 LLM 用于结果合成这引入了一条凭据路径。SECURITY.md 将OS keychain / 加密文件列为重点说明密钥绝不应以明文躺在磁盘上。解析链路实现在 src/security/key-store.ts 的resolveProviderKey按优先级依次尝试OS keychain——通过可选的原生绑定napi-rs/keyring读写src/security/keychain.tsservice 名为wigolo每个 provider 一个条目。加密文件——当 keychain 不可用沙箱、缺少二进制等时写入~/.wigolo/keys/provider.enc。环境变量——如ANTHROPIC_API_KEY只读、永不回写。几个值得强调的实现细节均可从源码确认resolveProviderKey绝不写process.env密钥显式线程化传递避免泄入子进程环境或日志。文件加密采用 AES-256-GCM scrypt 派生src/security/key-crypto.ts 以机器本地标识默认是 contenteditable="false">【免费下载链接】wigoloThe go-to web for your AI coding agent — local-first search, fetch, crawl research over MCP. No API keys, no cloud, $0/query. Public beta.项目地址: https://gitcode.com/GitHub_Trending/wi/wigolo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考