name: supabase-pentest description: 编排完整的Supabase安全审计，提供逐步引导的执行和所有权确认。

Supabase安全审计编排器

🔵 推荐：对于复杂审计使用计划模式

当您的环境支持计划模式时，强烈建议在开始审计之前激活它：

在编排开始时使用EnterPlanMode工具

计划模式支持更好地组织多阶段审计

它允许用户在执行前验证方法

如果计划模式不可用，直接进行执行

计划模式提供更好的可追溯性和用户对审计过程的控制。

🔴 关键：需要渐进式文件更新

您必须逐步写入上下文文件，而不仅仅是在最后。

每次发现后立即写入.sb-pentest-context.json

每次操作前后记录到.sb-pentest-audit.log

不要等到阶段或技能完成才更新文件

如果审计崩溃或被中断，所有先前的发现必须已经保存

这不是可选的。未能逐步写入是关键错误。

这个技能编排一个Supabase-based应用程序的完整安全审计，通过验证检查点引导您通过每个阶段。

⚠️ 强制性：渐进式上下文文件管理

在开始任何审计之前，您必须：

如果不存在，创建.sb-pentest-context.json
如果不存在，创建.sb-pentest-audit.log
创建.sb-pentest-evidence/目录结构
使用目标URL和时间戳初始化上下文

在执行期间 - 逐步写入：

每次操作前 → 记录到.sb-pentest-audit.log
每次发现后 → 立即更新.sb-pentest-context.json
每次测试后 → 保存证据到.sb-pentest-evidence/
不要批量写入 → 每个发现必须在发现时保存
每次技能后验证 → 在继续之前检查所有文件是否已更新

📋 系统性文档要求

所有跟踪文件必须在整个审计期间系统地维护。

必需文件（强制性）

文件	目的	更新频率
`.sb-pentest-context.json`	集中状态和发现	每次发现后
`.sb-pentest-audit.log`	按时间顺序的操作日志	每次操作前后
`.sb-pentest-evidence/timeline.md`	带时间戳的发现叙述	每次重要发现后
`.sb-pentest-evidence/curl-commands.sh`	可复现的测试命令	每次curl/HTTP请求后

验证清单（每次阶段转换前）

在移动到下一阶段之前，编排器必须验证：

[ ] .sb-pentest-context.json包含当前阶段的所有发现
[ ] .sb-pentest-audit.log有所有执行操作的条目
[ ] 证据文件存在于.sb-pentest-evidence/XX-phase-name/
[ ] timeline.md已更新任何P0/P1/P2发现
[ ] curl-commands.sh包含所有HTTP请求

如果任何文件缺失或不完整，不要进行到下一阶段。

渐进式写入模式

每个技能必须遵循此模式：

1. [LOG] 写入START条目到audit.log
2. [CONTEXT] 用"phase_in_progress"更新context.json
3. [ACTION] 执行测试/扫描
4. [EVIDENCE] 立即保存证据文件
5. [CURL] 追加curl命令到curl-commands.sh
6. [TIMELINE] 如果重要发现，更新timeline.md
7. [CONTEXT] 用结果更新context.json
8. [LOG] 写入COMPLETE条目到audit.log

失败恢复

如果技能或阶段失败：

所有更新到失败点的文件都被保存
审计可以从最后一个成功的检查点恢复
上下文文件指示审计停止的位置

⚠️ 为什么这很重要：

如果审计被中断、崩溃或超时，到该点的发现被保存
长时间运行的技能必须增量保存进度，而不仅仅是在最后
用户可以通过观察日志文件实时监控进度

未能逐步更新上下文文件是不可接受的。

每个单独的技能负责在工作时更新这些文件，而不仅仅是在完成时。如果技能没有逐步更新上下文，编排器必须在每次发现后立即进行。

何时使用此技能

运行Supabase应用程序的完整安全评估
在生产前执行内部安全自评估
在安全关注提出后审计应用程序
进行定期安全审查

前提条件

要审计的应用程序的公共URL
授权测试目标应用程序（您必须拥有它或有明确许可）
互联网访问以到达目标URL

重要安全通知

⚠️  需要授权

在继续之前，您必须确认：

1. 我拥有此应用程序，或
2. 我有明确的书面授权执行安全测试

未经授权的安全测试可能违反法律和条款服务。
输入“我确认我有权测试此应用程序”以继续。

审计阶段

编排器按顺序运行这些阶段，每个阶段之间有确认。

📁 提醒：每次阶段后，验证：

.sb-pentest-context.json已更新阶段结果

.sb-pentest-audit.log有START和COMPLETE条目

证据文件保存到.sb-pentest-evidence/XX-phase/

timeline.md反映任何重要发现

curl-commands.sh包含所有HTTP请求

阶段0：初始化

设置审计环境和证据收集。

阶段前操作（如果支持）：

**使用EnterPlanMode**如果环境支持它
这允许用户在执行前验证审计方法
如果计划模式不可用，直接进行

操作：

创建.sb-pentest-context.json
创建.sb-pentest-audit.log
创建.sb-pentest-evidence/目录结构
用头部初始化curl-commands.sh
用审计开始初始化timeline.md
记录初始化到.sb-pentest-audit.log

调用的技能：

supabase-evidence（初始化）

进行前的验证：

[ ] 所有4个跟踪文件存在
[ ] 证据目录结构完整
[ ] 用户授权确认

输出： 准备收集证据，具有完整目录结构

阶段1：检测

确定目标是否使用Supabase并提取基本信息。

调用的技能：

supabase-detect

输出： Supabase使用确认，项目URL识别

证据保存到： .sb-pentest-evidence/01-detection/

阶段2：密钥提取

扫描客户端代码以查找暴露的凭据。

调用的技能：

supabase-extract-url
supabase-extract-anon-key
supabase-extract-service-key
supabase-extract-jwt
supabase-extract-db-string

输出： 所有发现的凭据列表，带有严重性评估

证据保存到： .sb-pentest-evidence/02-extraction/

阶段3：API审计

测试PostgREST API暴露和RLS策略。

调用的技能：

supabase-audit-tables-list
supabase-audit-tables-read
supabase-audit-rls
supabase-audit-rpc

输出： 可访问的表，数据暴露评估，RLS差距

证据保存到： .sb-pentest-evidence/03-api-audit/

阶段4：存储审计

检查存储桶配置和访问。

调用的技能：

supabase-audit-buckets-list
supabase-audit-buckets-read
supabase-audit-buckets-public

输出： 桶清单，公共暴露，可访问文件

证据保存到： .sb-pentest-evidence/04-storage-audit/

阶段5：身份验证审计

分析身份验证配置和潜在弱点。

调用的技能：

supabase-audit-auth-config
supabase-audit-auth-signup
supabase-audit-auth-users
supabase-audit-authenticated ← 新增：创建测试用户（经同意）以检测IDOR

输出： 身份验证提供商分析，注册限制，枚举风险，已验证与匿名比较

证据保存到： .sb-pentest-evidence/05-auth-audit/

⚠️ 注意： supabase-audit-authenticated将在创建测试用户前请求明确同意。这是可选的，但强烈推荐以检测IDOR和跨用户访问漏洞。

阶段6：实时和函数审计

测试WebSocket通道和边缘函数。

调用的技能：

supabase-audit-realtime
supabase-audit-functions

输出： 暴露的通道，函数端点，访问控制问题

证据保存到： .sb-pentest-evidence/06-realtime-audit/和.sb-pentest-evidence/07-functions-audit/

阶段7：报告生成

编译所有发现为综合报告。

调用的技能：

supabase-report

输出： 完整的Markdown报告，带有执行摘要、发现和修复

计划模式的工作流

当支持计划模式时，推荐的工作流是：

1. 用户请求审计 → 代理使用EnterPlanMode
2. 代理表面探索目标（检测Supabase，提取URL）
3. 代理写入计划到计划文件：
   - 目标URL
   - 检测到的Supabase配置
   - 提议执行的阶段
   - 估计范围
4. 代理使用ExitPlanMode → 用户审查并批准
5. 代理执行阶段，系统性文件更新
6. 每次阶段后 → 代理确认文件已更新
7. 最终报告生成

计划模式的优点：

用户可以在执行开始前调整范围
更好地了解将要测试的内容
从规划到执行的更清晰审计跟踪

使用

基本完整审计（带计划模式）

在https://myapp.example.com上运行Supabase安全审计

代理应该：

如果可用，使用EnterPlanMode
呈现审计计划供批准
执行系统性文件更新

基本完整审计（不带计划模式）

在https://myapp.example.com上运行Supabase安全审计 --no-plan

从阶段恢复

从阶段3（API审计）继续Supabase审计

跳过特定阶段

在https://myapp.example.com上运行Supabase审计，跳过身份验证审计

上下文文件和证据（强制性）

⚠️ 关键：更新跟踪文件和收集证据是强制性的。

编排器创建和管理：

文件/目录	目的
`.sb-pentest-context.json`	存储阶段间提取的数据
`.sb-pentest-audit.log`	记录所有操作，带时间戳
`.sb-pentest-evidence/`	专业审计的证据目录

证据收集

编排器在每次审计开始时初始化证据目录：

.sb-pentest-evidence/
├── README.md                    # 证据索引
├── curl-commands.sh             # 所有可复现的curl命令
├── timeline.md                  # 按时间顺序的发现
├── 01-detection/                # 检测证据
├── 02-extraction/               # 密钥提取证据
├── 03-api-audit/                # API审计证据
│   ├── tables/
│   ├── data-samples/
│   ├── rls-tests/
│   └── rpc-tests/
├── 04-storage-audit/            # 存储审计证据
│   ├── buckets/
│   └── public-url-tests/
├── 05-auth-audit/               # 身份验证审计证据
│   ├── signup-tests/
│   └── enumeration-tests/
├── 06-realtime-audit/           # 实时审计证据
├── 07-functions-audit/          # 函数审计证据
└── screenshots/                 # 可选截图

每个技能必须在其相应目录中保存证据。

强制性更新规则

每次技能执行后，.sb-pentest-context.json必须用结果更新
每个操作必须在.sb-pentest-audit.log中记录，带时间戳
如果文件不存在，必须在审计开始时创建
永远不要完成技能而不更新上下文文件

强制性日志格式

.sb-pentest-audit.log中的每个条目必须遵循此格式：

[YYYY-MM-DD HH:MM:SS] [SKILL_NAME] [STATUS] 消息

示例：

[2025-01-31 14:00:00] [supabase-detect] [START] 开始Supabase检测
[2025-01-31 14:00:05] [supabase-detect] [SUCCESS] Supabase检测到
[2025-01-31 14:00:05] [supabase-detect] [CONTEXT_UPDATED] .sb-pentest-context.json已更新

上下文文件结构

{
  "target_url": "https://myapp.example.com",
  "started_at": "2025-01-31T10:00:00Z",
  "authorization_confirmed": true,
  "supabase": {
    "detected": true,
    "project_url": "https://abc123.supabase.co",
    "anon_key": "eyJ...",
    "service_key_exposed": false
  },
  "phases_completed": ["detection", "extraction"],
  "findings": []
}

速率限制

编排器实现自适应速率限制：

以正常请求速度开始
如果检测到HTTP 429（请求过多），指数退避
尊重Supabase的速率限制头部

输出格式

每次阶段后：

═══════════════════════════════════════════════════════════
 阶段2完成：密钥提取
═══════════════════════════════════════════════════════════

 发现：
 ├── ✅ 找到匿名密钥（预期）
 ├── ❌ P0：服务角色密钥在main.js:1247暴露
 └── ⚠️  P1：检测到JWT秘密模式

 继续到阶段3（API审计）？ [Y/n]
═══════════════════════════════════════════════════════════

最佳实践

在非生产时间运行审计以最小化影响
保存上下文文件用于审计跟踪目的
在修复前与安全团队审查发现
实施修复后重新运行审计以验证

常见问题

❌ 问题： 审计在阶段1停止，显示“未检测到Supabase” ✅ 解决方案： 应用程序可能使用自定义域。手动提供Supabase URL：

用Supabase URL https://myproject.supabase.co运行审计

❌ 问题： 在审计期间被速率限制 ✅ 解决方案： 编排器自动调整。如果持续，等待5分钟并恢复。

❌ 问题： 上下文文件损坏 ✅ 解决方案： 删除.sb-pentest-context.json并重新开始审计。

Supabase安全审计编排器Skill supabase-pentest

name: supabase-pentest description: 编排完整的Supabase安全审计，提供逐步引导的执行和所有权确认。