Programa de recompensa por vulnerabilidades

Capgo se compromete con la seguridad y la transparencia. Todos nuestros code son de código abierto, y acogemos a los investigadores de seguridad para ayudarnos a identificar vulnerabilidades en nuestro código.

Código abierto Code

Cada repositorio en la organización Capgo es de código abierto. Puedes revisar, auditar y contribuir a nuestros code.

Organización GitHub: github.com/Cap-go

Capgo Backend & Landing

Repositorio principal Capgo incluyendo servicios de backend y sitio web de aterrizaje

Ver Repositorio Reportar Problema de Seguridad

Capacitor Updater Plugin

El plugin de núcleo Capacitor que maneja actualizaciones por aire en dispositivos móviles

Ver Repositorio Reportar Problema de Seguridad

Requisitos para Informes Validos

Para calificar para el programa de Bug Bounty, su informe debe cumplir CON TODOS LOS SIGUIENTES REQUISITOS:

Debes identificar el archivo y el número de línea exactos en nuestro repositorio GitHub donde existe la vulnerabilidad
Su informe debe ser presentado a través de GitHub Security Advisory en el repositorio relevante
Debes incluir una descripción clara de la vulnerabilidad y su impacto potencial
Debes proporcionar pasos reproducibles para demostrar el problema

Importante: Si no puede proporcionar la línea exacta de code en GitHub donde existe el problema, su informe no será elegible para el programa de Bug Bounty. Los informes deben ser presentados a través de GitHub Security Advisory solo. Los pagos se manejan a través de Algora.io; por favor, cree una cuenta allí para que podamos pagarle directamente en la plataforma.

Tiempo de respuesta y respeto

Somos amigables y pagamos por informes válidos, pero no podemos trabajar con personas que no respeten nuestro tiempo. Por favor, mantenga la comunicación calmada y siga este programa.

Respondemos a informes de seguridad y brechas dentro de 24-72 horas.
No nos spamifiquen. Más de tres correos electrónicos en un solo día se considera spam y será bloqueado.
No pagamos por informes que ignoren estas reglas o sean spam.
Solo se aceptan informes en el alcance que siguen este programa de bug bounty; cualquier otra cosa puede ser bloqueada.
No le pregunten sobre actualizaciones de estado como "¿has revisado?" o preguntas similares. Una vez que confirmemos que recibimos su informe, eso es suficiente. Después de eso, todavía hay un trabajo significativo por hacer, y preparar una solicitud de extracción puede llevar varios días.

Importante: Capgo es una empresa pequeña y autónoma, por lo que nuestros montos de recompensa son inferiores a los programas de grandes empresas. Los informes sin un camino claro de explotación se pagan hasta un máximo de $30. Las explotaciones con un impacto real y reproducible en Capgo se pagan hasta un máximo de $300. Aceptamos y revisamos informes de seguridad para los plugins de Capgo, pero las recompensas pagadas por los plugins de code están limitadas a @capgo/capacitor-actualizador. Los demás plugins de Capgo son gratuitos y no forman parte de nuestra oferta de producto pagada, por lo que los informes sobre ellos se revisan pero no se pagan. Los pagos se emiten solo después de que hemos identificado el problema, lo hemos corregido, hemos abierto una solicitud de extracción y usted ha verificado después de la liberación que la corrección funciona para usted. Este proceso suele tardar entre 20 y 30 días. No envíe mensajes como "para obtener pagado"; el pago solo ocurre una vez que la liberación esté activa y haya probado y validado la corrección.

Cómo Informar

Navegue hasta el repositorio relevante en GitHub
Haga clic en la pestaña "Seguridad"
Haga clic en "Reportar una vulnerabilidad" para crear un nuevo informe de seguridad
Incluya el archivo de ruta y el número de línea exactos donde existe la vulnerabilidad
Proporcione pasos detallados para reproducir el problema y explique el impacto de seguridad

Fuera del alcance

Los informes sin referencias de línea exactas de code en GitHub
Los informes no presentados a través de GitHub Security Advisory
Vulnerabilidades teóricas sin prueba de concepto
Bugs en plataformas, dependencias o servicios de terceros que Capgo no puede corregir directamente (informe esos upstream, por ejemplo, a Supabase)
Intentos de ingeniería social o phishing
Ataques de denegación de servicio
Reportes de SSRF o DNS spoofing contra webhooks o vista previa del sitio web. Estas características se ejecutan en infraestructura sin servidor y no pueden usarse para acceder a infraestructura Capgo privada, por lo que no son explotables en nuestro entorno.
Configuración de la aplicación o proyecto code propiedad del usuario que Capgo no posee, envía, controla o incluye archivos como capacitor.config.ts, config.capacitor.ts, código fuente de la aplicación code y ajustes específicos del entorno.
Acceso a archivos de paquete Capgo o prueba de que los archivos de paquete pueden descargarse. Los archivos de paquete son activos web públicos, los usuarios están informados de esto y el acceso a ellos no se considera una violación de datos.

Supabase y Servicios de Terceros

Si la causa raíz es un error o comportamiento de la plataforma o servicio de Supabase, informe a Supabase, no a Capgo. Si la lógica vulnerable, SQL, RPC, política de acceso a la capa de datos, función de borde o configuración fue creada o elegida por Capgo y podemos arreglarlo en nuestro proyecto, está en el alcance incluso cuando Supabase sirve el punto final. Para hallazgos sobre el comportamiento de Supabase en sí mismo, incluya un caso reproducible y el ajuste de configuración Supabase o el cambio de configuración exacto que lo previene en un proyecto configurado como el nuestro.

Ejemplos

No válido aquí

Un error de la plataforma de Supabase, una interrupción o un comportamiento que solo Supabase puede arreglar
Un hallazgo que no se puede reproducir
Una afirmación que culpa a Capgo por el comportamiento de Supabase sin mostrar una solución de Capgo-controlada o el ajuste de configuración Supabase/configuración exacta que lo previene

Válido aquí

Un problema de configuración de Supabase controlado por Capgo que podemos corregir en nuestras configuraciones del proyecto (con pasos)
Un problema de SQL, RPC, RLS, función o integración propiedad de Capgo que causa un uso inseguro de Supabase
Un problema reproducible en el proyecto, esquema o políticas de Capgo de Supabase, incluso si se expone a través de un punto final de Supabase

Limitaciones conocidas de Supabase Auth (Ya Informado)

Algunos hallazgos se informan repetidamente y están causados por los valores predeterminados de Supabase Auth o el comportamiento de la plataforma en lugar de Capgo code. Revisamos estos solo cuando pueden reproducirse en un proyecto de demostración compartida de Supabase configurado como el nuestro y cuando la solución es un cambio de configuración de Supabase que no requiere cambiar las reglas de seguridad de Capgo. Si el cambio requiere cambiar SQL, RPCs, políticas de RLS, funciones o lógica de la aplicación propiedad de Capgo, informe sobre ello porque eso está en el alcance.

Proporcione un caso reproducible y identifique la solución exacta: ya sea el cambio de configuración de Supabase/configuración que resuelve un problema de comportamiento de Supabase o el objeto Capgo-propiedad code/config que debe cambiar.
El comportamiento de verificación de correo electrónico se espera que siga las configuraciones del proyecto de Supabase Auth (por ejemplo, si la confirmación de correo electrónico está deshabilitada y se utiliza la autenticación basada en captura).
Los flujos de actualización de contraseña y recuperación de cuenta pueden no requerir siempre la reentrada de la contraseña antigua o la reverificación si Supabase Auth está configurado de esa manera.
Si el problema está en esta lista pero puedes mostrar una solución concreta de Supabase en el proyecto proporcionado o un defecto de seguridad concreto propiedad de Capgo, podemos considerarlo en el alcance.

Para preguntas sobre nuestro programa de Bug Bounty, por favor contacta a través de nuestros GitHub Security Advisories.