跳过主要内容
Capgo logo

Bug Bounty Program

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

开源 Code

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

GitHub Organization: github.com/Cap-go

Capgo Backend & Landing

Main Capgo repository including backend services and landing website

查看仓库 报告安全问题

Capacitor Updater Plugin

The core Capacitor plugin that handles over-the-air updates on mobile devices

查看仓库 报告安全问题

有效报告的要求

为了参加Bug Bounty计划，报告必须满足以下所有要求：

  • 您必须在我们的GitHub仓库中找出确切的文件和行号，哪里存在漏洞
  • 您的报告必须通过GitHub安全建议在相关仓库提交
  • 您必须提供漏洞的清晰描述及其潜在影响
  • 您必须提供可复现的步骤来演示问题

重要： 如果您无法提供GitHub中的code确切行号，哪里存在问题，那么您的报告将不符合Bug Bounty计划的要求。报告必须通过GitHub安全建议提交。通过Algora.io处理付款；请在那里创建一个账户，我们可以直接在平台上为您支付。

响应时间和尊严

我们友好并且为有效报告支付，但我们无法与不尊严我们的时间的人合作。请保持沟通平和，并遵循这个计划。

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

重要： Capgo 是一个小型自举公司，因此我们的赏金金额低于大公司计划。没有明确的利用路径的报告最高可获得 $30。具有真正、可重复影响的 Capgo 的利用最高可获得 $300。我们只在确认问题、修复它、打开拉取请求并您在发布后验证修复后才会发放报酬。这整个过程通常需要 20-30 天。请不要发送类似"获取报酬"的消息；报酬只在发布后且您已测试和验证修复后才会发放。

如何报告

  1. 导航到 GitHub 相关的存储库
  2. 点击"安全"标签
  3. 点击"报告漏洞"以创建一个新的安全建议
  4. 包含漏洞存在的确切文件路径和行号
  5. 请提供详细的步骤来复现问题，并解释安全影响

不在范围内

  • 没有准确的code行引用在GitHub中的报告
  • 通过GitHub安全建议提交的报告
  • 理论上的漏洞没有概念证明
  • 第三方平台、依赖项或服务中的bug，Capgo无法直接修复（例如，报告到 Supabase）。
  • 社会工程或钓鱼企图
  • 拒绝服务攻击
  • SSRF 或 DNS 欺骗报告针对 webhook 或网站预览。这些功能在无服务器基础设施上运行，无法用于访问私有Capgo基础设施，因此它们在我们的环境中不可利用。

Supabase 和第三方服务

如果根源是 Supabase 平台或服务 bug，报告到 Supabase，而不是Capgo。如果易受攻击的逻辑、SQL、RPC、RLS 策略、边缘函数或配置由Capgo创建或选择，我们可以在项目中修复它，即使 Supabase 提供了端点。对于 Supabase 行为本身的发现，包括可复现的案例和在项目配置类似 ours 的项目中预防它的确切 Supabase 设置或配置更改。

示例

Not valid here

  • 仅 Supabase 可以修复的平台错误、停机或行为
  • 无法复现的发现
  • 指控 Capgo 导致 Supabase 行为问题而没有提供 Capgo 控制的修复或具体 Supabase 设置/配置更改

有效

  • 我们可以在项目设置（带步骤）中修复的 Capgo 控制的 Supabase 缺陷
  • Capgo 所有 SQL、RPC、RLS、函数或集成问题导致不安全的 Supabase 使用
  • 在 Capgo 的 Supabase 项目、模式或策略中，甚至通过 Supabase 端点暴露的可复现问题

已知 Supabase Auth 限制（已报告）

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

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

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