Seguridad

Autoauditoría según OWASP ASVS

La parte del servidor de GameAP se ha auditado según el OWASP Application Security Verification Standard (ASVS), una lista abierta de requisitos de seguridad concretos y verificables: desde cómo se guardan las contraseñas hasta cómo se tratan los archivos subidos.

Agentes de IA revisaron los requisitos uno por uno, y cada conclusión se comprobó después a mano. Cada requisito figura como cumplido, cumplido en parte o no cumplido, con referencias al código y a las pruebas que lo respaldan. Ambos informes son públicos, incluidos los requisitos que aún no se cumplen.

Informe de nivel 1 Informe de nivel 2 Qué es OWASP ASVS

Cómo se protege el panel

Inicio de sesión y contraseñas

  • Las contraseñas se guardan solo como un hash lento e irreversible (bcrypt), nunca en texto legible.
  • Una contraseña necesita al menos 12 caracteres, y se rechazan unas 46 000 contraseñas comunes.
  • Tras 5 intentos fallidos en una cuenta, o 20 desde una misma dirección IP, el inicio de sesión se pausa durante 15 minutos.
  • El formulario responde igual, y en el mismo tiempo, exista o no la cuenta.
  • Puedes añadir un CAPTCHA al formulario: reCAPTCHA o Cloudflare Turnstile.

Autenticación de dos factores

  • Códigos de una app de autenticación (TOTP) y 10 códigos de recuperación de un solo uso.
  • Obligatoria para los administradores: tras un periodo de gracia de 30 días, un administrador sin 2FA solo puede configurarla.
  • El secreto de 2FA se guarda cifrado en la base de datos (AES-256-GCM), y los códigos de recuperación, solo como hash.
  • Un código ya usado se rechaza, y cada inicio de sesión permite 5 intentos. Para desactivar la 2FA hacen falta la contraseña y un código.

Sesiones y tokens de API

  • Los tokens de sesión están cifrados y protegidos contra manipulación (PASETO v4). Caducan a las 24 horas, o a los 7 días con «Recordarme».
  • Al cerrar sesión, el token se revoca en el servidor. Tras cambiar la contraseña, dejan de funcionar las sesiones y los tokens de API emitidos antes.
  • Los tokens de API tienen permisos limitados, se muestran una sola vez, se guardan como hash y se pueden revocar en cualquier momento.
  • Los tokens de larga duración nunca se aceptan en enlaces. Las descargas y la consola en vivo usan tokens de un solo uso válidos 10 segundos como máximo.
  • Las peticiones se autorizan con una cabecera y no con una cookie, lo que protege contra la falsificación de peticiones entre sitios (CSRF).

Permisos

  • Permisos separados para cada acción sobre un servidor: iniciar, detener, consola, archivos, RCON y más.
  • Todo lo que no está permitido de forma explícita queda denegado, y los permisos se comprueban en el servidor en cada petición.
  • Cada usuario solo ve los servidores que tiene asignados. Para cualquier otro, el panel responde como si el servidor no existiera.
  • Las funciones de administración solo están disponibles para los administradores. Un token de API solo accede a ellas si se le concede de forma explícita un permiso de administración.

HTTPS y protección en el navegador

  • Un cliente de Let's Encrypt integrado obtiene los certificados HTTPS y los renueva automáticamente.
  • Solo TLS 1.2 o superior, con cifrados modernos que ofrecen secreto perfecto hacia adelante (forward secrecy).
  • Una política de seguridad de contenido (CSP) estricta bloquea los scripts inyectados en la página, lo que dificulta mucho el cross-site scripting (XSS).
  • Protección contra clickjacking, la detección del tipo de contenido (sniffing) y las fugas por Referer, además de HSTS sobre HTTPS. Las respuestas con datos de la cuenta nunca se guardan en caché.

Gestor de archivos

  • El acceso a los archivos es un permiso aparte para cada servidor y se limita a la carpeta de ese servidor.
  • Se rechazan las rutas con ../ y trucos similares. En la propia máquina, GameAP Daemon además mantiene cada operación con archivos dentro de su directorio de trabajo (Go os.Root).
  • Al extraer archivos comprimidos se bloquean los archivos y enlaces que acabarían fuera de la carpeta de destino (zip slip), y se limitan el tamaño total y el número de archivos.
  • Los archivos se abren en el navegador dentro de un entorno aislado o se descargan, así que un archivo HTML o SVG subido no puede ejecutar scripts en el panel.

Servidores de juegos y consola

  • Los valores de la configuración del servidor entran en el comando de inicio como argumentos separados, así que no pueden inyectar comandos adicionales.
  • Cada servidor de juegos puede ejecutarse con su propio usuario del sistema, o en su propio contenedor Docker o Podman con límites de memoria y CPU.
  • Solo los administradores pueden cambiar el comando de inicio, la carpeta y el usuario del sistema de un servidor.
  • Ver la consola y enviar comandos son permisos distintos, que se comprueban en cada mensaje. La contraseña RCON se oculta en la salida de la consola.

Servidores dedicados y GameAP Daemon

  • GameAP Daemon no abre puertos de red en la máquina: es él quien se conecta al panel.
  • La conexión va cifrada con TLS de forma predeterminada. Tras la configuración, el daemon solo confía en la autoridad de certificación propia del panel.
  • Cada máquina se conecta con una clave de configuración de un solo uso que, por defecto, caduca al cabo de una hora.
  • Cada máquina recibe su propia clave aleatoria. El panel solo guarda su hash y nunca la muestra. También se puede exigir TLS mutuo.

Plugins

  • Los plugins se ejecutan en un entorno aislado de WebAssembly, sin acceso directo a archivos, red ni variables de entorno: solo a las interfaces que ofrece el panel.
  • Cada plugin tiene límites de memoria, tiempo de ejecución y frecuencia de peticiones.
  • Solo los administradores pueden instalar plugins, y los paquetes del catálogo se verifican con un hash SHA-256.
  • Las peticiones HTTP de los plugins usan solo HTTPS por defecto y no pueden llegar a redes locales ni a servicios de metadatos en la nube (protección contra SSRF).

Registro de auditoría y datos

  • Un registro de auditoría de seguridad anota los inicios de sesión y los intentos fallidos, los accesos denegados, los cambios de usuarios, roles y tokens, las operaciones con archivos y la gestión de plugins.
  • Cada entrada incluye el usuario, la dirección IP, la hora y el ID de la petición.
  • Los secretos de la autenticación de dos factores y de los plugins se guardan cifrados (AES-256-GCM).
  • Todas las consultas a la base de datos están parametrizadas, lo que protege contra la inyección SQL.
  • Los errores del servidor devuelven un mensaje genérico; los detalles solo van al registro del servidor.

Seguridad en el desarrollo

Pruebas de seguridad

Un conjunto de pruebas propio, organizado según el OWASP API Security Top 10, comprueba que nadie pueda acceder a servidores ajenos, saltarse el inicio de sesión o elevar sus propios permisos. Se ejecuta con cada cambio.

Análisis estático

Cada cambio pasa por un analizador de código con reglas de seguridad (gosec), y las pruebas se ejecutan contra MySQL, PostgreSQL y Redis reales.

Fuzzing

Cada semana, el inicio de sesión, las comprobaciones de permisos y el manejo de rutas de archivos reciben grandes cantidades de datos aleatorios y malformados.

Revisión de dependencias

Las dependencias se comprueban contra la base de datos de vulnerabilidades de Go (govulncheck) cada semana y con cada cambio en la rama principal. Sus versiones están fijadas con sumas de verificación.

Pruebas de mutación

Cada semana se introducen pequeños errores a propósito en el código de autenticación y de permisos para comprobar que las pruebas los detectan.

Código abierto

El código está en GitHub bajo la licencia MIT. Las versiones incluyen sumas de verificación SHA-256, y la imagen de Docker se ejecuta sin privilegios de root.

Recomendaciones para administradores

  1. 1

    Activa HTTPS

    gameapctl puede obtener un certificado de Let's Encrypt, que después el panel renueva por su cuenta. Redirige también el HTTP sin cifrar a HTTPS.

    TLS_FORCE_HTTPS=true
  2. 2

    Activa ya la autenticación de dos factores

    Los administradores tienen 30 días para configurarla, pero no hay motivo para esperar. Pide a los demás usuarios que también la activen.

  3. 3

    Añade un CAPTCHA al formulario de inicio de sesión

    Sobre todo si el panel está expuesto a internet.

    CAPTCHA_PROVIDER
  4. 4

    Exige certificados a los daemons

    Con TLS mutuo, el panel solo acepta conexiones de daemons que tengan un certificado emitido por él.

    GRPC_REQUIRE_MTLS=true
  5. 5

    No ejecutes servidores de juegos como root

    Usa un usuario del sistema aparte para los servidores de juegos, o ejecútalos en contenedores Docker o Podman.

  6. 6

    Instala plugins solo de fuentes de confianza

    Activa también la aplicación de permisos, para que cada plugin tenga solo el acceso que declara.

    PLUGINS_PERMISSIONS_ENFORCE=true
  7. 7

    Usa tus propias claves secretas

    gameapctl las genera durante la instalación. Con Docker o una instalación manual, define tú mismo valores largos y aleatorios.

    ENCRYPTION_KEYAUTH_SECRET
  8. 8

    Mantente al día

    Las correcciones de seguridad llegan en las versiones habituales. Sigue el repositorio de GameAP en GitHub para recibir los avisos de seguridad.

Reportar una vulnerabilidad

Por favor, no publiques vulnerabilidades en issues públicos. Repórtalas de forma privada en GitHub o por correo. Quienes las reportan aparecen en las notas de la versión y en el aviso de seguridad.

Reporte privado en GitHub security@gameap.com
72 horas
para confirmar la recepción del reporte
14 días
para la evaluación inicial
14 días
para corregir una vulnerabilidad crítica
90 días
hasta la divulgación pública, acordada con quien la reporta
Política de seguridad Avisos publicados