Strix supabase 技能深度解析Supabase 安全测试方法论从 RLS 绕过到 service_role 密钥泄露【免费下载链接】strixOpen-source AI penetration testing tool to find and fix your app’s vulnerabilities.项目地址: https://gitcode.com/GitHub_Trending/strix/strixStrix 内置的supabase技能supabase.md是其 Skills 体系中专攻 Supabase 平台的安全测试知识包覆盖 Row Level Security 失守、PostgREST 越权、RPC 函数滥用、Storage 策略失配、Edge Functions 信任边界与service_role密钥泄露等核心风险面。本文完整继承该技能文档的攻击面模型、端点架构、逐类漏洞测试请求与验证要求并结合 Strix 源码说明该技能如何被解析、注入 Agent 系统提示词并被执行帮助读者既掌握一套可复制的 Supabase 渗透测试方法也理解 AI 渗透工具如何把这类领域知识工程化。一、技能定位Supabase 是 Strix technologies 类别下的专项知识包Strix 的 Skills 是“专业知识包”knowledge packages每个技能是一个带 YAML frontmatter 的 Markdown 文件按需注入 Agent 的上下文把通用大模型转化为针对特定漏洞类别、协议、框架或第三方平台的专家。官方文档 skills.mdx 在 Technologies 类别中将其描述为SkillCoveragesupabaseSupabase RLS bypasses, auth issues该技能文件的 frontmatter 声明了元数据--- name: supabase description: Supabase security testing covering Row Level Security, PostgREST, Edge Functions, and service key exposure ---从源码结构看技能文件遵循root/category/name.md的目录约定内置技能位于 strix/skills/ 下technologies与vulnerabilities、protocols、tooling、cloud等并列skills README 对各类别的分工给出了总览其中/technologies即“针对 Supabase、Firebase、Auth0 等第三方服务的专项技术”。二、Supabase 攻击面与端点架构技能开篇即给出 Supabase 安全测试要聚焦的五个风险点失域mis-scopedRLS 策略、不安全的 RPC 函数、泄露的service_role密钥、宽松的 Storage 策略以及不校验签发方/受众/租户就信任请求头的 Edge Functions。2.1 攻击面划分面覆盖内容数据访问PostgREST表 CRUD、过滤器、嵌入、RPC 远程函数、GraphQLpg_graphql 基于 Postgres schema 并与 RLS 交互、Realtime复制订阅、broadcast/presence 频道存储Buckets、对象、签名 URL、public/private 策略认证AuthGoTrueJWT、cookie/session、magic links、OAuth 流程服务端Edge FunctionsDeno持有密钥调用 Supabase 的服务端代码2.2 端点模型所有请求都围绕ref项目引用展开服务端点RESThttps://ref.supabase.co/rest/v1/tableRPChttps://ref.supabase.co/rest/v1/rpc/fnStoragehttps://ref.supabase.co/storage/v1GraphQLhttps://ref.supabase.co/graphql/v1Realtimewss://ref.supabase.co/realtime/v1Authhttps://ref.supabase.co/auth/v1Functionshttps://ref.functions.supabase.co/请求头只有两个关键身份要素apikey: anon-or-service—— 仅用于标识项目project-scoped不是用户身份Authorization: Bearer JWT—— 绑定用户上下文用户级鉴权真正发生在这里。角色模型分三层anon、authenticated—— 标准角色受 RLS 约束service_role——绕过 RLS绝不应出现在客户端可见的位置前端 bundle、API 响应、错误栈。技能文档反复强调的一条关键原则是auth.uid()从 JWT 中返回当前用户 UUID。策略policy绝不能信任客户端提供的 ID 而忽视服务端上下文。这条原则是后文所有 RLS/RPC/租户隔离测试的判据。2.3 高价值目标清单测试前优先锁定以下对象含敏感数据的表users、orders、payments、PIIRPC 函数尤其是SECURITY DEFINER的存放私有文件的 Storage buckets持有service_role访问权限的 Edge Functions生成签名输出的导出/报表端点管理员/员工路由与授予权限的端点。三、侦察枚举面与获取主体3.1 枚举表面按技能文档给出的路径模式逐一探测/rest/v1/table /rest/v1/rpc/fn /storage/v1/object/public/bucket/ /storage/v1/object/list/bucket?prefix /graphql/v1 /auth/v13.2 获取测试主体Principals未认证身份仅 anon key普通用户 A、用户 B两个横向对比账号管理员/员工身份若可获取检查service_role密钥是否已泄露在客户端 bundle 或 Edge Function 响应中——一旦发现整个 RLS 防线等于不存在应第一时间按最高优先级记录。后续所有测试都围绕“资源 × 操作 × 主体”的矩阵展开。四、核心漏洞测试方法4.1 Row Level SecurityRLS基线要求每一张非公共表都必须启用 RLS未启用或存在“全放行”permit-all策略即意味着批量数据暴露。常见缺口策略只对 SELECT 检查auth.uid()却忘了 UPDATE/DELETE/INSERT缺少租户约束org_id/tenant_id导致跨租户访问策略依赖客户端传入的列如 payload 里的user_id而非 JWT 身份复杂 join 场景下策略在过滤器之后才生效可通过计数差推断数据。测试请求# 对比两个用户可见行数 GET /rest/v1/table?select*Prefercountexact # 跨租户探测 GET /rest/v1/table?org_ideq.other_org GET /rest/v1/table?or(org_id.eq.other,org_id.is.null) # 写路径 PATCH /rest/v1/table?ideq.foreign_id DELETE /rest/v1/table?ideq.foreign_id POST /rest/v1/table # 携带外部的 owner_id4.2 PostgREST 与 REST 层过滤器面eq、neq、lt、gt、ilike、or、is、in关系嵌入select*,profile(*)会在 resolver 跳过逐行检查时造成过度取数overfetch宽松的LIKE/ILIKE过滤叠加缺失 RLS 会经通配查询导致批量泄露。关键请求头请求头作用Prefer: returnrepresentation回显写入结果Prefer: countexact通过计数暴露数据存在性Accept-Profile/Content-Profile选择 schemaIDOR 模式/rest/v1/table?select*ideq.other_id /rest/v1/table?select*slugeq.other_slug /rest/v1/table?select*emaileq.other_email批量赋值Mass Assignment若接口未走 RPC 收敛PATCH 可能更新到不该更新的列需确认受限列是否通过数据库权限/策略真正锁死而不只是接口层过滤。4.3 RPC 函数RPC 端点映射到 SQL 函数SECURITY DEFINER以属主权限运行会绕过 RLS除非函数体内做了严谨检查SECURITY INVOKER则以调用者权限运行、尊重 RLS。反模式SECURITY DEFINER 缺少属主校验 → 垂直/水平越权set search_path暴露给 public函数解析到不安全对象信任客户端传入的user_id/tenant_id而非auth.uid()。测试# 以不同用户身份、携带外部 ID 调用 POST /rest/v1/rpc/fn {user_id: foreign_id} # 直接移除 JWT 身份 Authorization: Bearer anon_token验证要点函数是否在 SQL 内部做了显式的属主/租户检查。4.4 Storage对象存放在storage.objects表上受类 RLS 策略约束。常见失配# 公开桶里放了敏感数据 GET /storage/v1/object/public/bucket/path # 无认证列前缀 GET /storage/v1/object/list/bucket?prefix # 签名 URL 跨租户/跨路径复用Content-Type 滥用上传 HTML/SVG 后被以text/html或image/svgxml返回需检查X-Content-Type-Options: nosniff与Content-Disposition: attachment是否生效。路径混淆大小写混用、URL 编码、..段可能在 UI 被拒绝却被 API 接受——重点测试客户端校验与服务端路径归一化之间的差异。4.5 Realtime端点为wss://ref.supabase.co/realtime/v1。风险点频道名由表/schema/过滤器派生RLS 或频道守卫弱时会泄露其他用户的更新broadcast/presence 频道允许未认证跨房间加入/发布。测试方法订阅受保护表的public:realtime变更确认可见性与 RLS 一致尝试加入他人频道room:user_id、org:org_id。4.6 GraphQL端点/graphql/v1pg_graphql同样受 RLS 约束。风险introspection 泄露 schema 关系嵌套关系过度取数全局 node ID 泄露后可被其他视图者复用。测试方法对同一主体与同一查询形态对比 REST 与 GraphQL 的响应查询深层嵌套字段验证 RLS 在每一层边上都成立。4.7 认证与令牌GoTrue 签发的 JWT 携带subuid、role、audauthenticated等声明。验证要求覆盖签发方issuer、受众audience、过期、签名与租户上下文。常见陷阱令牌存 localStorage → 可被 XSS 窃取把apikey当身份用它只是项目作用域标识;service_role密钥暴露在前端 bundle 或 Edge Function 响应中Refresh token 管理失当导致会话远超预期 TTL。测试把令牌跨服务重放检查 audience/issuer 是否被固定用降级令牌过期/其他受众打自定义端点。4.8 Edge FunctionsDeno 函数通常以service_role初始化 Supabase 客户端。风险不校验 JWT 的签发方/受众就信任 Authorization/apikey 头CORS 通配 origin 带凭证、响应中反射 Authorizationfetch 触发 SSRF错误栈或日志暴露密钥。测试带/不带 Authorization 分别调用函数对比行为差异payload 中塞入外部资源 ID验证服务端是否从 JWT 重新推导用户/租户尝试通过函数内 fetch 触达内部端点如元数据服务。4.9 租户隔离每条查询都应 join 或过滤 JWT 上下文派生的tenant_id/org_id而不是客户端输入。测试时保持 JWT 租户不变只改子域/请求头/路径中的租户选择器对导出/报表端点确认查询运行在调用者作用域内。五、进阶技巧绕过与盲枚举绕过技术内容类型切换application/json↔application/x-www-form-urlencoded↔multipart/form-data参数污染JSON/query 中重复键PostgREST 依解析器取第一个或最后一个GraphQLREST 对等性探测保护逻辑常在两条路径间漂移走较弱的一条竞态窗口并行写入以绕过插入后的属主更新。盲枚举无响应体差异时的推断Prefer: countexact与 ETag/长度差推断未授权行的存在条件请求If-None-Match检测对象存在性Storage 签名 URL 的耗时/长度差用于区分有效与无效令牌。六、标准测试流程与配套工具技能文档给出的六步方法论是整套技能的“执行骨架”Inventory surfaces—— 测绘 REST、Storage、GraphQL、Realtime、Auth、Functions 端点Obtain principals—— 收集 anon、用户 A/B、管理员令牌检查service_role泄露Build matrix—— 建立“资源 × 操作 × 主体”矩阵REST vs GraphQL—— 双通道测试以发现对等性缺口Seed IDs—— 先从列表/搜索端点收集 IDCross-principal—— 跨主体交换 ID、租户与传输通道。工具集领域工具与做法PostgRESThttpie/curl jq枚举表fuzz 过滤器or、ilike、neq、is.nullGraphQLgraphql-inspector、voyager深度查询验证字段级强制Realtime自定义 ws 客户端订阅可疑频道按主体 diff payloadStorage枚举桶列 API脚本化签名 URL 模式Auth/JWTjwt-cli/jose 校验 audience/issuer向 Edge Functions 重放策略 diff按角色维护请求集跨版本对比结果验证要求报告成立门槛REST/GraphQL 上“属主 vs 非属主”请求展示未授权访问内容或元数据层面失域 RPC 或 Storage 签名 URL 可被另一用户/租户使用Realtime 或 GraphQL 暴露与缺失的策略检查一一对应附带最小可复现请求并记录所用角色上下文。七、Strix 如何加载并执行这个技能理解了技能内容再看 Strix 如何把它变成 Agent 的能力。整个链路在源码中清晰可查7.1 解析与加载strix/skills/__init__.pyload_skills(skill_names)按strix/skills/category/name.md解析技能支持裸名supabase或限定名technologies/supabase解析后剥掉 frontmatter 只注入 Markdown 正文init.py 中的load_skills与_parse_skill_contentvalidate_requested_skills对每次请求做三重校验单 Agent 最多 5 个技能、名称必须存在、跨类别重名时必须用category/name限定get_available_skills()按类别聚合所有技能的 name description供系统提示词中的available_skills清单渲染。7.2 注入系统提示词strix/agents/prompt.pyrender_system_prompt调用_resolve_skills构建有序技能列表调用方显式请求的技能在前随后固定追加scan_modes/mode、tooling/agent_browser、tooling/python、analysis/counterevidence、analysis/severity_calibration等根 Agent 还会追加coordination/root_agentprompt.py。技能正文经 Jinja 模板渲染进系统提示词位于 system_prompt.jinja 的specialized_knowledge区块中每个技能独立包在supabase等标签内未预载的技能则列在available_skills清单里由 Agent 运行时按需拉取。7.3 运行时拉取与子代理分配两条路径都能让supabase技能生效临时内联Agent 在动手测试前调用 load_skill 工具技能正文作为工具结果直接进入对话上下文“no permanent prompt change, just in-conversation reference”永久分配根 Agent 通过create_agent(task..., skills[...])生成专职子代理时传入技能列表子代理系统提示词会完整内联该技能。系统提示词中的多代理规则明确要求“每个 Agent 1-3 个相关技能、最多 5 个”并给出了类似Auth Testing Agent with skills: authentication_jwt, business_logic的专项化范例——对 Supabase 目标一个典型的委派形态就是“Supabase 数据面 Agentskills:supabase,idor”加“Supabase 服务端 Agentskills:supabase,ssrf”这样的拆分。build_strix_agentfactory.py负责把 skills 参数传给render_system_prompt并统一挂载think、load_skill、create_vulnerability_report、record_coverage等基础工具——也就是说技能文档第六节的“最小可复现请求 角色上下文”验证要求最终由报告工具create_vulnerability_report的字段强制落地且报告与修复fix_before/fix_after在同一步骤内完成。八、实战入口在 Strix 中发起一次 Supabase 目标扫描该技能的适用前提目标是自托管 Supabase 实例或*.supabase.co项目且测试已获授权。Strix 的扫描入口按 scan-modes.mdx 提供三档深度deep 为默认模式# 对本地代码 Supabase 部署目标做深度扫描白盒 动态验证 strix --target ./app --scan-mode deep # CI 场景的快速冒烟 strix --target https://ref.supabase.co --scan-mode quick结合技能文档的方法论一次典型的 Strix 运行会呈现如下轨迹根 Agent 只做编排系统提示词中的 root_agent_directive 明确禁止根 Agent 亲自发 payload委派子代理按“侦察枚举端点 → 收集 anon/用户 A/B 主体 → 建立资源×操作×主体矩阵 → RLS/RPC/Storage/Realtime/GraphQL 逐面验证 → 用create_vulnerability_report提交带最小可复现请求的报告”的流程执行每个面包括干净结果都会写入record_coverage台账。白盒场景下仓库中的 supabase client 初始化代码哪一侧持有service_role、migration 里的 RLS 策略定义会成为动态验证的优先线索——这正是技能“策略必须从 JWT 而非客户端输入推导身份”原则的源码级印证方式。九、小结supabase技能的价值在于把 Supabase 特有的信任边界apikey 与 JWT 的分层、auth.uid()作为唯一身份源、service_role的绝对隔离、RLS 覆盖全部 DML 动词翻译成了一份可直接执行的测试清单七个端点、九类漏洞面、每类都配了请求级 PoC 与验证门槛。对使用者它是 Strix 子代理的“领域手册”对维护者strix/skills/technologies/supabase.md 本身就是一个符合 Skills 规范 的模板——frontmatter 元数据、攻击面/方法论/绕过/验证的章节骨架与strix/skills/README.md中对技能结构的定义一一对应。【免费下载链接】strixOpen-source AI penetration testing tool to find and fix your app’s vulnerabilities.项目地址: https://gitcode.com/GitHub_Trending/strix/strix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考