GeckoFlag es un software que se ejecuta en tu propio servidor. Para que puedas confiarle la información de tus proyectos con tranquilidad, el propio desarrollador realiza pruebas de seguridad en cada versión y publica en esta página qué se revisó y cuáles fueron los resultados.
Esta página es un registro de las autoevaluaciones realizadas por el desarrolladorNo se trata de una certificación ni de una auditoría de un organismo externo. Como también publicamos qué se revisa, puedes usar esta información como referencia para decidir si adoptar GeckoFlag.
- Medidas de diseño
- Pruebas en cada versión
- Resultados de la última versión
- Lo que no se revisa
- Reporte de vulnerabilidades
- Verificación de los archivos distribuidos
- Configuración recomendada
Medidas de seguridad en el diseño
GeckoFlag incorpora de forma estándar las siguientes medidas. Todas están activas sin necesidad de configurar nada.
Protección de contraseñas
Las contraseñas no se guardan en texto plano, sino con un hash bcrypt. Los tokens para restablecer la contraseña también se guardan con hash, y el número de solicitudes de restablecimiento está limitado.
Límite de intentos de inicio de sesión
Los intentos fallidos de inicio de sesión se cuentan tanto por cuenta como por dirección IP de origen, y al superar cierto número se restringe temporalmente el inicio de sesión. Esto frena los ataques de fuerza bruta y los ataques dirigidos a muchas cuentas.
Protección contra CSRF
Se verifica un token en cada envío de formulario para evitar que sitios externos realicen operaciones haciéndose pasar por el usuario.
Protección contra XSS
El texto enriquecido de tareas, comentarios, Wiki, notas, etc. se guarda y se muestra con HTML Purifier, que conserva solo las etiquetas permitidas. En los enlaces solo se permiten http y https. El texto generado por IA también pasa por el mismo proceso antes de guardarse.
Protección contra inyección SQL
Las operaciones con la base de datos usan el ORM de CakePHP 5 y sentencias preparadas.
Validación del encabezado Host
Los enlaces incluidos en los correos de restablecimiento de contraseña, invitaciones y notificaciones se generan a partir del dominio registrado, no del encabezado Host de la solicitud. Un encabezado Host malicioso no puede reemplazar los enlaces de los correos por direcciones externas.
Almacenamiento de archivos
Las imágenes de las tareas y los archivos de los proyectos se guardan fuera de la carpeta pública y solo se entregan tras confirmar que quien los ve es miembro del proyecto. No se aceptan archivos con extensiones ejecutables, como PHP.
Cifrado de la clave de API
La clave de API de Claude para las funciones de IA se guarda cifrada en la base de datos.
Tokens de API de la integración con Claude
La integración con Claude está desactivada de forma predeterminada y solo se puede usar si un administrador la activa y la permite para cada usuario. De cada token de API solo se guarda un hash, y se puede fijar una fecha de caducidad. Al cambiar la contraseña, los tokens dejan de ser válidos. La API comprueba los mismos permisos que las pantallas, y un token de solo lectura no puede cambiar nada.
Restricción por dirección IP
Los administradores pueden limitar las direcciones IP desde las que se permite el acceso.
Cierre del instalador
Una vez completada la configuración inicial, ya no se puede acceder a la pantalla del instalador.
Protección de carpetas privadas
En Apache, el acceso directo a carpetas como las de configuración, registros y código fuente se bloquea de forma estándar (en Nginx, consulta la configuración recomendada).
Copia de seguridad automática antes de actualizar
Antes de cada actualización del software se crea automáticamente una copia de seguridad.
Verificación de la firma de los archivos de actualización
Los archivos de actualización oficiales llevan la firma digital del desarrollador (Ed25519). Antes de actualizar se verifican la firma y el contenido de todos los archivos, y no se aplican archivos alterados ni archivos de actualización que no sean oficiales.
Validación de imágenes subidas
Las imágenes como avatares, miniaturas y logotipos se identifican por su contenido real y se guardan con un nombre de archivo aleatorio. Desde las carpetas de imágenes no se entrega ningún archivo que no sea una imagen (en Apache). No se acepta el formato SVG.
Encabezados de seguridad
Se envían Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy y Permissions-Policy para evitar el clickjacking y la filtración de información a sitios externos. Si el sitio funciona con HTTPS, también se envía Strict-Transport-Security para que el navegador se conecte siempre por HTTPS.
Gestión de sesiones
La sesión se regenera en cada inicio de sesión. Los cambios de permisos, la eliminación de cuentas y los cambios de contraseña se aplican de inmediato también en las sesiones abiertas. Para cambiar el correo electrónico o la contraseña es necesario ingresar la contraseña actual.
Pruebas de seguridad en cada versión
Antes de publicar una nueva versión, realizamos las siguientes pruebas. Las pruebas se hacen en un entorno de pruebas con la misma configuración que producción, nunca en servicios en funcionamiento ni en los servidores de los clientes. Lo que se realizó en la última versión se indica en «Resultados de la última versión».
| Categoría | Qué se revisa | Herramientas y criterios | Frecuencia |
|---|---|---|---|
| Bibliotecas de dependencias | Se comprueba que las bibliotecas usadas no tengan vulnerabilidades conocidas y se genera la lista de bibliotecas usadas (SBOM) | composer audit, OSV-Scanner, CycloneDX | En cada versión |
| Análisis estático | Detección en el código fuente de rutas por las que los datos de entrada llegan a operaciones peligrosas (XSS, inyección SQL, etc.) | Psalm (análisis de taint), PHPStan (nivel 5), Semgrep | En cada versión |
| Filtración de secretos | Que no haya contraseñas ni claves de API en el código fuente ni en los archivos distribuidos | gitleaks | En cada versión |
| Escaneo dinámico | Con sesión iniciada como administrador y como usuario normal, se envían solicitudes de ataque reales y se revisa la respuesta | Nuclei | En cada versión |
| Pruebas de permisos | Que no se puedan ver ni manipular tareas, archivos o notas de proyectos de los que no se es miembro cambiando el ID en la URL | Pruebas automatizadas (PHPUnit), revisión manual | En cada versión |
| Subida de archivos | Que se rechacen archivos ejecutables, archivos disfrazados de imágenes, archivos ZIP que manipulan rutas, etc. | Revisión de código, revisión manual | En cada versión |
| XSS | Se introducen cadenas de ataque en descripciones de tareas, comentarios, Wiki y textos generados por IA para comprobar que no se ejecuten scripts | Revisión de código, revisión manual | En cada versión |
| Revisión por configuración de servidor | Que no se pueda acceder directamente a los archivos de configuración ni a los registros en Apache y Nginx, ni con cada forma de ubicar la carpeta pública | Revisión manual | En cada versión |
| Extensión de la integración con Claude | Vulnerabilidades conocidas en las bibliotecas que usa la extensión, manejo del token de la API y restricciones sobre el destino de las solicitudes | npm audit, gitleaks, revisión de código | En cada versión de la extensión |
| Autoevaluación con lista de verificación | Revisión punto por punto de autenticación, sesiones, validación de entradas, manejo de errores, etc. | Con referencia a OWASP ASVS 5.0 nivel 1 e IPA (Japón): «Cómo proteger tu sitio web» | En cada versión mayor |
| Sitio oficial | Configuración HTTPS y encabezados de seguridad de geckoflag.com | SSL Labs, Mozilla Observatory | Una vez al mes |
Si se encuentra un problema de gravedad «alta» o «media», no publicamos la versión hasta corregirlo y volver a probar. Los de gravedad «baja» se revisan y se corrigen, o se deja constancia de por qué no tienen impacto.
Política de actualización de las bibliotecas de dependencias
Revisamos las vulnerabilidades conocidas de las bibliotecas que usa GeckoFlag (como CakePHP) en cada versión. Si se encuentra una vulnerabilidad que afecta a GeckoFlag, publicamos una versión corregida dentro de los siguientes plazos orientativos.
- Gravedad «crítica» o «alta»: dentro de los 14 días posteriores a su divulgación
- Gravedad «media»: dentro de los 30 días posteriores a su divulgación
- Gravedad «baja»: en la siguiente versión (a más tardar, dentro de 90 días)
Aunque una vulnerabilidad no afecte a la forma en que GeckoFlag usa la biblioteca, la actualizamos a una versión corregida en la siguiente versión. Las bibliotecas de desarrollo no se incluyen en los archivos distribuidos.
Resultados de la última versión: v1.11.0
En esta ronda se probaron los cambios desde v1.10.0 (la integración con Claude, los colores de texto y de fondo y los separadores del texto enriquecido, entre otros) y también se corrigieron problemas que ya existían en versiones anteriores. Si usa v1.10.0 o una versión anterior, le recomendamos actualizar a v1.11.0.
| Prueba | Herramientas (versión) | Hallazgos (alta / media / baja) | Medidas tomadas |
|---|---|---|---|
| Bibliotecas de dependencias | GitHub Advisory Database, FriendsOfPHP security-advisories (datos al 2026-10-28; 89 paquetes) | 0 / 0 / 0 | No hay vulnerabilidades conocidas en las bibliotecas incluidas en los archivos de distribución. Las vulnerabilidades conocidas de las bibliotecas de desarrollo se resolvieron actualizándolas en v1.11.0 (las bibliotecas de desarrollo no se incluyen en los archivos de distribución) |
| Análisis estático y revisión de código | Psalm 5.26.1 (análisis taint), PHPStan 2.1.17 (nivel 5), Semgrep 1.182.1, revisión manual del código (cambios desde v1.10.0: API y tokens de la integración con Claude, texto enriquecido, mantener la sesión iniciada, actualizaciones del software; además, la salida de enlaces en todas las pantallas) | 1 / 1 / 3 | Los problemas de gravedad «alta» y «media» y 2 de los de gravedad «baja» se corrigieron en v1.11.0. El problema «bajo» restante solo ocurre por acciones del propio usuario y se confirmó que su impacto es limitado. El problema «alto» ya existía en versiones anteriores |
| Filtración de secretos | gitleaks 8.24.2 | 0 / 0 / 0 | Se revisaron tanto el código fuente como los archivos de distribución. Las 2 detecciones fueron falsos positivos (cadenas de ejemplo en bibliotecas externas, etc.) |
| Verificación de las correcciones | Pruebas de funcionamiento en el entorno de pruebas (PHP 8.3, MariaDB 10.11, Apache 2.4, Nginx 1.24, Chromium) | — | Para cada hallazgo, se confirmó que el problema anterior a la corrección ya no se reproduce |
| Escaneo dinámico | Nuclei v3.11.1 (plantillas v10.5.1), sin sesión iniciada y como administrador y miembro | 0 / 0 / 0 | Sin problemas |
| Pruebas de permisos | PHPUnit 12.5 (454 pruebas automatizadas. Además de lo anterior, se confirmó que la API de la integración con Claude rechaza las solicitudes sin token, con un token de solo lectura, de usuarios sin permiso y con la función desactivada, y que nunca llega a proyectos en los que el usuario no participa) | 0 / 0 / 0 | Sin problemas |
| Revisión por configuración de servidor | Manual (Apache 2.4 y Nginx 1.24, con 2 formas de ubicar la carpeta pública; 39 URL, entre ellas archivos de configuración, registros, sesiones y archivos guardados) | 0 / 0 / 1 | Corregido en v1.11.0: ahora también en Apache se rechaza todo acceso directo a la carpeta de archivos de versiones anteriores (files). Sin otros problemas |
| Lista de verificación | OWASP ASVS 5.0 nivel 1 (70 requisitos) | Se cumplen 50 de los 56 requisitos aplicables | No se revisó en esta ocasión (se mantiene el resultado de v1.10.0) |
| Extensión de la integración con Claude | npm audit, gitleaks 8.24.2, mcpb validate, revisión manual del código (geckoflag-1.0.0.mcpb) | 0 / 0 / 0 | No hay vulnerabilidades conocidas que afecten a las bibliotecas incluidas en el archivo de distribución. Se comprobó el manejo del token de la API y las restricciones sobre el destino de las solicitudes (solo HTTPS, sin seguir redirecciones) |
Los resultados de todas las versiones, incluidas las anteriores, se conservan en «Resultados anteriores».
Lo que no se revisa
Las pruebas anteriores tienen los siguientes límites. Tenlos en cuenta también al evaluar la adopción de GeckoFlag.
- No se han realizado pruebas por parte de terceros. Por ahora no se han hecho revisiones del código fuente ni pruebas de penetración a cargo de especialistas externos.
- El entorno de tu servidor no está incluido en las pruebas. La seguridad varía mucho según la configuración y el estado de actualización del sistema operativo, el servidor web, PHP y la base de datos.
- No se ha comprobado en todos los entornos de hosting. Las configuraciones probadas se limitan a las indicadas en «Resultados de la última versión».
- Los servicios externos no están incluidos. La seguridad de la API de Anthropic que usan las funciones de IA, de la aplicación de escritorio de Claude que usa la integración con Claude, de los servidores de envío de correo, etc., depende de cada proveedor.
- Sobre lo que las herramientas automáticas no detectan. Los tipos de problemas que las herramientas no detectan (como fallas en la lógica de negocio) se complementan con revisiones manuales, pero no es posible cubrirlo todo.
Si encuentras una vulnerabilidad
Si encuentras un problema que creas que es una vulnerabilidad de GeckoFlag, no lo publiques; comunícate directamente a través del canal que se indica a continuación. El desarrollador revisa personalmente todos los reportes.
Canal de reporte: escríbenos mediante el formulario de contacto y selecciona el tipo de consulta «Reporte de vulnerabilidad»
Información que te pedimos incluir
- La versión afectada y la pantalla o función donde ocurre el problema
- Los pasos para reproducirlo (en la medida de lo posible)
- El impacto previsto
- El entorno de tu servidor (PHP, servidor web, etc.)
Te pedimos lo siguiente
- Realiza tus pruebas en un entorno que administres tú mismo y no lleves a cabo acciones ofensivas contra instalaciones de GeckoFlag operadas por otras personas ni contra geckoflag.com.
Si lo deseas, incluiremos tu nombre como agradecimiento en la información de seguridad de la versión corregida.
SHA-256 de los archivos distribuidos
Puedes comprobar si el archivo que descargaste es idéntico al oficial comparándolo con los siguientes valores.
| Archivo | SHA-256 |
|---|---|
| GeckoFlag - 1.11.0.zip | 33354ac588c4cb4de2953c3c26a484953c2bb886f38196ba4bcf4fe629648399 |
| geckoflag-1.0.0.mcpb | 44f2c6dfc9f437856d0680920a327820d757a14116064faa6e46ad8a961d0747 |
Cómo comprobarlo: en Windows, ejecuta Get-FileHash nombre_de_archivo -Algorithm SHA256 en PowerShell; en macOS y Linux, ejecuta shasum -a 256 nombre_de_archivo.
Configuración recomendada para un uso seguro
La seguridad de GeckoFlag también depende de la configuración del servidor donde se instala. Recomendamos la siguiente configuración.
- Completa la instalación justo después de subir los archivos: hasta que termine la instalación, cualquier persona que conozca la URL puede abrir la pantalla de configuración. Después de colocar los archivos, completa la instalación de inmediato.
- Usa HTTPS: la información de inicio de sesión y el contenido de los proyectos se transmiten cifrados. Muchos servicios de hosting ofrecen certificados SSL gratuitos. Ten en cuenta que, una vez que se abre el sitio con HTTPS, el navegador se conectará a esa dirección por HTTPS durante el año siguiente (v1.10.0 o posterior). Tenlo presente si piensas dejar de usar HTTPS.
- Configura webroot como carpeta pública (raíz de documentos): así, los archivos de configuración y los registros quedan en una ubicación no accesible desde la web.
- Si usas Nginx, agrega la configuración necesaria: en Nginx, .htaccess no funciona. Configura por separado el bloqueo del acceso a las carpetas privadas y que no se ejecute PHP en la carpeta de imágenes subidas (webroot/img). Encontrarás un ejemplo de configuración en el manual (Instalación).
- Actualiza a la última versión: las correcciones de seguridad se incluyen en la última versión. Obtén los archivos de actualización en el sitio oficial y comprueba su SHA-256. A partir de v1.10.0, la firma también se verifica automáticamente antes de actualizar.
- Mantén PHP y la base de datos en versiones con soporte: las versiones de PHP cuyo soporte ha finalizado ya no reciben correcciones.
- Protege las cuentas de administrador: usa contraseñas largas y difíciles de adivinar, y otorga permisos de administrador solo a quienes los necesiten.
- Para uso interno, usa la restricción por IP: desde «Configuración» puedes limitar las direcciones IP que pueden acceder.
- Haz copias de seguridad con regularidad: guarda la base de datos y los archivos subidos en un lugar distinto del servidor.