# 逆向工程视角：Moltbook 安全漏洞剖析与防护加固指南 > 从 Moltbook 的 Supabase 数据库泄露事件出发，逆向剖析其配置错误与密钥暴露根源，并给出 API 安全与运行时监控的工程化参数。 ## 元数据 - 路径: /posts/2026/02/03/hacking-moltbook-security-analysis/ - 发布时间: 2026-02-03T05:03:37+08:00 - 分类: [security](/categories/security/) - 站点: https://blog.hotdry.top ## 正文 Moltbook 的崛起速度令人咋舌。作为一个定位于"智能体互联网首页"的社交平台，它在短短数日内便吸引了 Andrej Karpathy 等业界大佬的关注，被形容为"近年来最接近科幻 takeoff 的事物"。然而，伴随着热度一同到来的，是一场赤裸裸的安全危机。安全研究人员通过简单的逆向工程手段，便获取了其整个生产数据库的读写权限，150 万个 API 密钥、3.5 万个用户邮箱以及数千条私信因此暴露。这场事故并非源于复杂的零日漏洞，而是源于对基础安全配置的忽视。本文将从逆向工程的视角复盘这次攻击路径，剖析其架构层面的防护缺失，并给出可落地的加固参数与监控清单。 ## 逆向侦察：从客户端 JS 到数据库密钥 Moltbook 采用了典型的现代 Web 架构——Next.js 前端配合 Supabase 后端。安全研究人员仅通过常规的浏览器操作，便发现了关键线索。在分析站点加载的客户端 JavaScript 文件时，特别是位于 `/_next/static/chunks/` 路径下的资源包，研究人员发现了硬编码在代码中的 Supabase 连接字符串。这个看似不起眼的疏忽，实际上等同于将金库的钥匙遗失在了大庭广众之下。 通过提取出的 `Supabase Project ID` 和 `API Key`，攻击者可以直接访问其 REST API 端点。这里暴露的 Key 具备极高的权限级别（虽然 Supabase 设计允许暴露部分 Public Key 以便客户端初始化，但在本例中，由于缺乏 Row Level Security 策略，这个 Key 实际上拥有了管理员级别的读写能力。研究人员通过简单的 `GET` 请求，便枚举出了数据库中的 `agents`、`owners`、`agent_messages` 等核心表结构，获取了大量敏感凭证。 更令人担忧的是，不仅读权限全面沦陷，写权限同样洞开。研究人员通过构造 `HTTP POST` 请求，不仅能够批量注册虚假的智能体账号，甚至能够直接修改平台上的已有帖子内容。这意味着攻击者完全可以篡改智能体发布的观点、植入恶意提示词（Prompt Injection），或者进行大规模的内容污染。这种对数据完整性的破坏，对于一个以智能体交互为核心的社交生态而言，构成了根本性的信任危机。 ## 架构防护缺失：Vibe Coding 的代价 Moltbook 的创始人曾在公开场合表示，整个平台是"AI 生成的代码"（Vibe Coding），他没有亲自编写一行业务逻辑代码。这一声明虽然展示了 AI 辅助开发的惊人效率，但也暴露了该模式的核心痛点：AI 擅长快速实现功能逻辑，却往往忽视了安全边界配置。 具体而言，Moltbook 的安全漏洞集中在以下几个关键层面。首先是 Row Level Security 的缺席。Supabase 官方文档明确强调，对于暴露在客户端的 API Key，必须配合严格的 RLS 策略才能保证安全。RLS 策略本质上是一套数据库层面的访问控制规则，它告诉数据库"哪些用户能看到哪些数据"。在 Moltbook 的配置中，这道防线完全缺失，导致任何一个获取到 API Key 的人都能访问所有表的所有数据。这不是代码逻辑的漏洞，而是基础设施配置的灾难。 其次是密钥管理的混乱。敏感的服务凭证（如 Supabase 的 Secret Key 或高权限 Token）绝对不应该出现在客户端代码中。最佳实践是将这些 Key 存储在后端服务器的环境变量中，并通过服务端代理（Server Proxy）来控制数据库访问。如果前端确实需要直接连接 Supabase（如实现 Realtime 功能），也应仅使用anon Key，并确保该 Key 对应的 RLS 策略严格限制了仅能访问必要的公开数据。Moltbook 将高权限 Key 硬编码在 JS 包中，等同于自毁长城。 第三是缺乏有效的速率限制与行为验证。数据显示，Moltbook 声称拥有 150 万智能体账号，但背后实际上只有约 1.7 万个人类用户。这意味着平台上绝大多数账号是由脚本批量注册的，且系统对此毫无察觉。缺乏验证码、缺乏行为分析、缺乏 API 调用频率限制，使得攻击者可以轻易地制造海量僵尸账号，进而操控平台的舆论生态。这不仅是安全风险，更是平台数据可信度的灾难。 ## 工程化加固：参数与监控清单 面对上述问题，我们需要从密钥管理、数据库策略、API 边界三个维度建立纵深防御体系。以下是可直接应用于类似架构的工程化参数与监控指标。 **第一，Supabase 与数据库配置加固。** 必须立即启用 Row Level Security 并编写严格的策略。所有表在创建时应默认开启 RLS，确保未经认证的请求默认被拒绝。对于 `agents` 表，查询策略应限制为仅允许通过 JWT Token 验证的 Agent 访问自己的记录，或者允许公开读取非敏感的 `agent_id` 与 `display_name`，但必须屏蔽所有 `api_key` 与 `claim_token` 字段。更新与删除操作应严格限定为记录所有者。同时，应立即轮换所有已暴露的 API Key 和 Secret，并确保新的凭证仅存放在服务端环境变量中，绝不进入代码仓库。 **第二，API 安全与身份验证参数。** JWT Token 的过期时间（Expiration Time）应设置为较短的窗口，例如 15 分钟到 1 小时，并启用刷新 Token（Refresh Token）机制以维持会话。对于涉及敏感操作（如发布内容、修改设置）的 API 端点，应强制要求二次验证或邮箱确认。引入速率限制中间件，对所有 API 端点设置合理的阈值：注册接口建议限制为每 IP 每分钟不超过 5 次，发布接口限制为每 Token 每分钟不超过 10 次，敏感数据查询接口限制为每 Token 每分钟不超过 60 次。这些参数应根据实际流量动态调整，并配置告警机制。 **第三，运行时监控与异常检测。** 建立完善的审计日志，记录所有对敏感表（如 `owners`、`agents`、`agent_messages`）的访问请求，包括来源 IP、User-Agent、Token ID、请求时间与操作类型。配置入侵检测规则，当检测到来自单一 IP 或 Token 的异常高频请求时，自动触发临时封禁。对于数据导出或批量查询操作，应增加人工审批流程或二次确认步骤。监控数据库的连接数与查询延迟，及时发现潜在的暴力枚举攻击。 **第四，代码与供应链安全。** 将密钥扫描工具（如 TruffleHog 或 Gitleaks）集成到 CI/CD 流水线中，防止敏感信息提交到代码仓库。定期使用动态应用安全测试（DAST）工具对前端应用进行扫描，检测硬编码凭证与不安全的 API 调用。此外，考虑到"Vibe Coding"的流行，建议在 AI 生成的代码审查清单中增加安全配置项，确保 RLS 策略、环境变量注入等关键步骤不被遗漏。 Moltbook 的案例是一记响亮的警钟。在 AI 加速软件开发的浪潮中，我们享受着前所未有的构建速度，却也必须直面安全补课的紧迫性。安全从来不是事后补丁，而是架构设计的第一步。当我们用 AI 生成代码时，更需要用严谨的安全框架去约束和校验这些代码。唯有如此，"智能体互联网"的愿景才不会停留在幻想层面，而是建立在可信、稳固的基础设施之上。 **资料来源：** - Wiz Blog, "Hacking Moltbook: The AI Social Network Any Human Can Control" (https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys) - DEV Community, "MoltBook: Reddit for AI Agents, or Just Humans with Extra Steps? A Technical Reality Check" (https://dev.to/sivarampg/moltbook-reddit-for-ai-agents-or-just-humans-with-extra-steps-a-technical-reality-check-523l) ## 同分类近期文章 ### [微软终止VeraCrypt账户：平台封禁下的供应链安全警示](/posts/2026/04/09/microsoft-terminates-veracrypt-account-platform-lock-risk/) - 日期: 2026-04-09T00:26:24+08:00 - 分类: [security](/categories/security/) - 摘要: 从VeraCrypt开发者账户被终止事件，分析Windows代码签名的技术依赖、平台封禁风险与开发者应对策略。 ### [GPU TEE 远程认证协议在机密 AI 推理中的工程实现与安全边界验证](/posts/2026/04/08/gpu-tee-remote-attestation-confidential-ai-inference/) - 日期: 2026-04-08T23:06:18+08:00 - 分类: [security](/categories/security/) - 摘要: 深入解析 GPU 可信执行环境的远程认证流程，提供机密 AI 推理场景下的工程参数配置与安全边界验证清单。 ### [VeraCrypt 1.26.x 加密算法演进与跨平台安全加固深度解析](/posts/2026/04/08/veracrypt-1-26-encryption-algorithm-improvements/) - 日期: 2026-04-08T22:02:47+08:00 - 分类: [security](/categories/security/) - 摘要: 深度解析 VeraCrypt 最新版本的核心加密算法改进、跨平台兼容性与安全加固工程实践，涵盖 Argon2id、BLAKE2s 及内存保护机制。 ### [AAA 游戏二进制混淆：自研加壳工具的工程现实与虚拟化保护参数](/posts/2026/04/08/binary-obfuscation-in-aaa-games/) - 日期: 2026-04-08T20:26:50+08:00 - 分类: [security](/categories/security/) - 摘要: 解析 AAA 级游戏二进制保护中的自研加壳工具、代码虚拟化性能开销与反调试实现的技术选型。 ### [将传统白帽黑客习惯引入氛围编程：构建 AI 生成代码的防御纵深](/posts/2026/04/08/old-hacker-habits-for-safer-vibecoding/) - 日期: 2026-04-08T20:03:42+08:00 - 分类: [security](/categories/security/) - 摘要: 将传统白帽黑客的安全实践应用于氛围编程，通过隔离环境、密钥管理与代码审计，为 AI 生成代码建立防御纵深，提供可落地的工程参数与清单。