跳过主要内容
Capgo logo

漏洞赏金计划

Capgo 致力于安全和透明度。我们所有的code都是开源的，我们欢迎安全研究人员帮助我们识别我们的代码库中的漏洞。

开源Code

Every repository in the Capgo organization is open source. You can review, audit, and contribute to our code.

GitHub Organization: https://github.com/Cap-go

Capgo Backend & Landing

主Capgo 仓库，包括后端服务和登陆网站

查看仓库 报告安全问题

Capacitor Updater 插件

Capacitor核心插件，负责在移动设备上处理即时更新

查看仓库 报告安全问题

有效报告的要求

为了符合漏洞赏金计划，报告必须满足以下所有要求：

  • 您必须在我们的GitHub仓库中准确标识出存在漏洞的文件和行号
  • 您的报告必须通过GitHub安全咨询在相关仓库提交
  • 您必须提供清晰的漏洞描述和潜在影响
  • 您必须提供可复现的步骤来演示问题

重要提示： 如果您无法提供问题出现在code中的确切GitHub行，则您的报告将不符合Bug Bounty计划的资格。必须通过GitHub安全建议提交报告。通过Algora.io处理付款；请在该平台上创建帐户，我们可以直接在该平台上为您支付。

响应时间和尊严

我们友好且支付有效报告，但无法与不尊严我们时间的人合作。请保持沟通平和，遵循此程序。

  • 我们在24-72小时内响应安全报告和漏洞。
  • 不要向我们发送垃圾邮件。单天超过三封邮件被视为垃圾邮件并将被阻止。
  • 我们不支付忽视这些规则或是垃圾邮件的报告。
  • 仅接受遵循此漏洞赏金计划的范围内的报告；其他任何内容都可能被阻止。
  • 不要询问状态更新，如"您是否检查了？"或类似问题。我们确认收到您的报告后即可。之后仍有大量工作需要做，准备pull请求可能需要几天时间。

重要提示： Capgo 是一家小型自主公司，因此我们的奖金金额较小。没有明确的利用路径的报告将获得最高 $30 的奖金。具有真实、可复制影响的 Capgo 的利用将获得最高 $300 的奖金。我们接受并审查 Capgo 插件的安全报告，但对于 code 插件的付费奖金仅限于 @capgo/capacitor-updater。其他 Capgo 插件是免费使用的，不属于我们的付费产品，因此报告将进行审查但不付费。我们只在确认问题、修复它、打开 pull 请求并您在发布后验证修复后才会发放付款。这一过程通常需要 20 到 30 天。请不要发送类似“要获得付款”的消息；付款只在发布后您测试并验证修复后才会发生。

How to Report

  1. 请前往相关仓库的 GitHub
  2. 点击“安全”标签
  3. 点击“报告漏洞”以创建新安全建议
  4. 包含具体的文件路径和行号（行号）
  5. 提供详细的步骤来复制问题并解释安全影响

不在范围内

  • 没有包含 code 行号参考的 GitHub 的报告
  • 没有通过 GitHub 安全建议提交的报告
  • 理论性漏洞没有概念证明
  • 第三方平台、依赖项或服务的错误， Capgo 无法直接修复（例如报告到 Supabase)。
  • 社会工程或钓鱼攻击
  • 拒绝服务攻击
  • SSRF or DNS spoofing reports against webhooks or website preview. These features run on serverless infrastructure and cannot be used to reach private Capgo infrastructure, so they are not exploitable in our environment.
  • User-owned application code or project configuration that Capgo does not own, ship, or control, including files such as capacitor.config.ts, config.capacitor.ts, app source code, and environment-specific settings.
  • 用户拥有的应用Capgo或项目配置,由__CAPGO_KEEP_1__不拥有,不运送,也不控制,包括文件如__CAPGO_KEEP_2__.config.ts, config.__CAPGO_KEEP_3__.ts,应用源__CAPGO_KEEP_4__,以及环境特定的设置。

访问__CAPGO_KEEP_0__打包文件或证明打包文件可以下载。打包文件是公共网络资产,用户已知此信息,访问它们并不被认为是数据泄露。

If the root cause is a Supabase platform or service bug, report it to Supabase, not Capgo. If the vulnerable logic, SQL, RPC, RLS policy, Edge Function, or configuration was created or chosen by Capgo and we can fix it in our project, it is in scope even when Supabase serves the endpoint. For findings about Supabase behavior itself, include a reproducible case and the exact Supabase setting or config change that prevents it in a project configured like ours.

如果根源是Supabase平台或服务bug,请向Supabase报告,而不是__CAPGO_KEEP_0__。如果易受攻击的逻辑,SQL,RPC,RLS策略,边缘函数,或配置由__CAPGO_KEEP_1__创建或选择,并且我们可以在我们的项目中修复,即使Supabase服务端点,它仍然在范围内。对于Supabase行为本身的发现,请包含可复现的案例和项目配置如我们的那样,预防它的确切Supabase设置或配置更改。

示例

  • 这里无效
  • 仅Supabase可以修复的Supabase平台bug,停机或行为
  • A claim that blames Capgo for Supabase behavior without showing a Capgo-controlled fix or the exact Supabase setting/config change

有效

  • 在我们的项目设置中（步骤）可以修复的Capgo控制的 Supabase 配置错误
  • Capgo拥有的 SQL、RPC、RLS、函数或集成问题，导致不安全的 Supabase 使用
  • Capgo的 Supabase 项目、模式或策略中可重现的问题，即使它是通过 Supabase 端点暴露的

已知 Supabase Auth 限制（已报告）

某些发现反复报告，并由 Supabase Auth 默认值或平台行为引起，而不是Capgo code。我们只在这些情况下进行审查：它们可以在一个配置类似我们的 Supabase 演示项目中重现，并且修复需要 Supabase 端配置更改，而不需要更改Capgo安全规则。如果修复需要更改Capgo拥有的 SQL、RPC、RLS 策略、函数或应用逻辑，请将其报告给我们，因为这在范围内。

  • 提供可重现的案例并确定具体的修复：要么是 Supabase 设置/配置更改，要么是Capgo拥有的code/配置对象需要更改。
  • 电子邮件验证行为应遵循您的 Supabase Auth 项目设置（例如，是否禁用电子邮件确认并使用捕获式认证）。
  • 密码更新和帐户恢复流程可能不总是需要旧密码重新输入或重新验证，如果 Supabase Auth 配置为这样。
  • 如果问题在此列表中，但您可以在提供的项目中展示一个具体的 Supabase 一侧的修复或一个具体的 Capgo 所有安全缺陷，我们可以考虑它在范围内。

关于我们的 Bug Bounty 计划的问题，请通过我们的 GitHub 安全建议联系我们。