Seguridad del CMS: CSRF, límites, cifrado

AliothPress aplica seguridad por capas a cada instalación: tokens CSRF en todas las peticiones que cambian estado, límites de peticiones con bloqueo automático de fuerza bruta, autenticación de dos factores opcional con recuperación por capas, almacenamiento cifrado de contraseñas SMTP y claves de API, saneamiento de HTML por lista de permitidos, limpieza de SVG en el servidor, cabeceras de seguridad estrictas en cada respuesta y un registro de auditoría persistente de la actividad del panel. Las sesiones se invalidan en el momento en que cambia una contraseña. Todo esto está activo de serie y no requiere configuración.

Tokens CSRF y límites de peticiones

Cada petición POST, PUT y DELETE del panel de administración lleva un token CSRF verificado en el servidor. Una comprobación fallida devuelve un mensaje claro con una vía para reintentar.

Los límites de peticiones se aplican por encima. El endpoint de inicio de sesión acepta 10 intentos por minuto, los envíos de formularios públicos y los endpoints de API tienen sus propios presupuestos por minuto, y las operaciones costosas, como la comprobación de actualizaciones, tienen tope por hora. Superar un límite devuelve una página de error amable.

Bloqueo antifuerza bruta

Los inicios de sesión fallidos se registran por dirección IP y nombre de usuario. Cinco intentos fallidos para el mismo par de IP y usuario, o veinte intentos fallidos desde una IP contra cualquier cuenta, dentro de 15 minutos, bloquean nuevos intentos desde esa IP durante 15 minutos. El contador por pares mantiene el bloqueo preciso: un colega que teclea mal su propia contraseña no deja fuera a toda la oficina, mientras que un atacante que recorre muchas cuentas desde una dirección choca con el techo por IP. Cada intento fallido, cada inicio de sesión correcto y cada bloqueo queda en el registro de auditoría con la IP anotada. Los registros de intentos antiguos se limpian automáticamente.

Autenticación de dos factores opcional

Las cuentas pueden añadir un segundo paso de inicio de sesión con códigos de un solo uso basados en tiempo (TOTP). Sirve cualquier aplicación de autenticación: la implementación sigue la RFC 6238 y usa solo la biblioteca estándar de Python, así que no interviene ningún servicio externo. La función viene desactivada de serie. El propietario la habilita para todo el sitio en los ajustes, y cada usuario la activa después desde su perfil: escanear un código QR y confirmar un código generado en vivo. El secreto se guarda cifrado, por la misma vía que las contraseñas SMTP y las claves de API, y la opción de confiar en el navegador omite el segundo paso en ese dispositivo durante 30 días. Desactivar o restablecer la 2FA invalida de golpe todos los navegadores de confianza.

La recuperación tiene varias capas, así que un teléfono perdido no significa una cuenta perdida. La configuración genera diez códigos de recuperación de un solo uso, guardados como hash y consumidos con el primer uso. Un código de inicio de sesión puede enviarse al correo de la cuenta. El Propietario o un Admin puede restablecer la 2FA de otro usuario desde la página de usuarios, aunque un Admin no puede quitarle el segundo factor al Propietario. Y un propietario único bloqueado del todo puede crear junto a la aplicación un archivo vacío llamado DISABLE_2FA que omite el segundo paso, señalado de forma visible en la interfaz y en el registro de auditoría hasta que el archivo se elimina. La activación, los intentos fallidos del segundo paso, los restablecimientos y las omisiones quedan todos en el registro de auditoría.

Los secretos se guardan cifrados

Las contraseñas SMTP, las claves de API de los proveedores de IA y las claves de licencia se cifran de forma simétrica con Fernet antes de llegar a la base de datos. La clave de cifrado deriva del secreto de la aplicación, que vive en el archivo .env del servidor. Un volcado de la base de datos por sí solo no expone las credenciales.

Saneamiento de contenido

El HTML del editor pasa por un saneador de lista de permitidos: los tags y atributos permitidos sobreviven, todo lo demás se elimina, inyección de scripts incluida. Los archivos SVG subidos se limpian del mismo modo, perdiendo tags de script, manejadores de eventos, URL javascript: y referencias externas antes de guardarse. Las subidas de imágenes se restringen a una lista explícita de extensiones y se recodifican durante el procesamiento.

Cabeceras de seguridad en cada respuesta

Cada respuesta lleva X-Frame-Options: SAMEORIGIN contra el clickjacking, X-Content-Type-Options: nosniff, X-XSS-Protection, una política de referencia strict-origin-when-cross-origin y una Permissions-Policy que desactiva cámara, micrófono y geolocalización. Sobre HTTPS se añade HSTS con vigencia de un año y cobertura de subdominios.

Cambiar la contraseña cierra todas las sesiones

Cada registro de usuario lleva una versión de sesión. Cambiar la contraseña la incrementa, y cada sesión existente de esa cuenta deja de funcionar de inmediato. Una cookie robada muere con la contraseña antigua.

Registro de auditoría

Las acciones significativas del panel quedan registradas: inicios de sesión, fallos, IP bloqueadas, cambios de contenido, creación de copias de seguridad, gestión de usuarios. Cada entrada guarda el usuario, la acción, la dirección IP y un mensaje de detalle que se muestra en el idioma del panel de quien lee el registro. Las entradas antiguas se eliminan según un calendario, así que el registro se mantiene útil sin crecer sin fin.

Acceso basado en roles

Los ajustes, la gestión de usuarios, la configuración de correo y las herramientas de mantenimiento están restringidos a los roles Propietario y Admin. Los editores trabajan solo con contenido. La instalación de plugins y la restauración de plugins desde una copia de seguridad están reservadas al Propietario, porque los archivos de plugin son código ejecutable. El modelo de roles completo se trata en el artículo Usuarios y roles.

Funciones de seguridad clave en AliothPress

Protección CSRF en todos los formularios, límites de peticiones por endpoint, bloqueo automático de 15 minutos tras cinco intentos fallidos por par de IP y usuario (o veinte por IP), autenticación de dos factores TOTP opcional con códigos de recuperación y alternativa por correo, credenciales cifradas con Fernet, saneamiento de HTML y SVG por lista de permitidos, cabeceras de seguridad estrictas con HSTS, invalidación de sesiones al instante al cambiar la contraseña y un registro de auditoría traducible. Cada capa está activa desde la primera petición tras la instalación.

Preguntas frecuentes

¿AliothPress protege contra ataques de fuerza bruta al inicio de sesión?
Sí. Cinco intentos fallidos para un par de IP y usuario, o veinte desde una IP en total, dentro de 15 minutos, activan un bloqueo de 15 minutos, además del límite de 10 intentos por minuto en el endpoint de inicio de sesión. Todos los eventos quedan en el registro de auditoría con la IP.
¿Las contraseñas SMTP y las claves de API se guardan en texto plano?
No. Se cifran con Fernet antes de guardarse, con una clave derivada del secreto de la aplicación en el servidor. La base de datos por sí sola no las revela.
¿Qué pasa con las sesiones activas cuando cambia una contraseña?
Se invalidan de inmediato. Cada sesión lleva un número de versión que deja de coincidir tras el cambio, forzando un nuevo inicio de sesión en todas partes.
¿AliothPress sanea los archivos SVG subidos?
Sí. Los scripts, manejadores de eventos, URL javascript: y referencias externas se eliminan en el servidor antes de guardar el archivo.
¿Existe un registro de la actividad del panel?
Sí. El registro de auditoría anota inicios de sesión, fallos, bloqueos, cambios de contenido, copias de seguridad y gestión de usuarios, cada uno con usuario, acción e IP, mostrado en el idioma del panel de quien lo consulta.
¿AliothPress admite autenticación de dos factores?
Sí, como opción. El propietario la habilita para el sitio y después cada usuario la activa en su perfil con cualquier aplicación de autenticación. La recuperación cubre códigos de un solo uso, códigos de inicio de sesión por correo, el restablecimiento por un administrador desde la página de usuarios y un archivo de emergencia para un propietario único bloqueado.