Cadena de XSS almacenado y CSRF para toma de cuenta de administrador
XSS almacenado en un campo de perfil que se ejecutaba dentro del panel de administración. El endpoint de cambio de email no validaba ningún token anti-CSRF. Encadenados, los dos fallos llevaban a la toma de la cuenta de administrador.
Resumen
El campo «nombre de organización» del perfil de usuario se renderizaba sin sanear en el listado del panel de administración. Cualquier usuario registrado podía almacenar en ese campo una carga útil que se ejecutaba en el navegador del administrador.
La carga útil sustituía la dirección de email del administrador, un cambio que el endpoint aceptaba sin pedir la contraseña actual. Con esa dirección en su poder, el atacante restablecía la contraseña y entraba en la cuenta.
La severidad recoge dos condiciones: una cuenta registrada bastaba para dejar la carga útil en el perfil, y un administrador la ejecutaba al abrir el listado.
Detalles técnicos
Cambio de email sin verificación
El endpoint aceptaba la petición solo con la cookie de sesión, sin token ni confirmación:
POST /api/account/update-email
Cookie: [SESIÓN DEL ADMINISTRADOR]
{ "email": "[EMAIL DEL ATACANTE]" }
-> 200 OK # email actualizado sin verificación adicionalCadena de ataque completa
La carga útil XSS lanzaba una petición fetch() con las cookies del administrador. La cadena quedó así:
1. El atacante registra una cuenta con organización = [carga útil XSS]
2. El administrador visita /admin/users -> la carga útil se ejecuta en su contexto
3. El script cambia el email del administrador vía /api/account/update-email
4. El atacante solicita un restablecimiento de contraseña al email que controla
5. Toma completa de la cuenta de administradorEl equipo verificó la explotación sobre una cuenta de administrador de pruebas creada por el cliente, sin acceder a datos de usuarios reales. El caso se publica anonimizado, con las correcciones aplicadas y comprobadas en el retest.
Impacto
- Toma de cuenta de cualquier administrador
- Acceso al panel de administración y a todos los registros que expone
- Modificación de datos de otros usuarios
- Escalada no verificada a otros sistemas internos alcanzables desde el panel
Remediación
- Saneo de la entrada de usuario. El HTML de los campos de perfil debe escaparse antes de renderizarlo.
- Tokens anti-CSRF. Todo endpoint que modifique estado debe validar un token.
- Confirmación para cambios críticos. El cambio de email debe exigir la contraseña actual y confirmarse desde la dirección anterior.
- Cabeceras de seguridad. Las respuestas deben servir una Content Security Policy estricta, junto a
X-Content-Type-OptionsyX-Frame-Options.
Referencias
Más análisis
Comprueba si esta cadena es posible en tu panel de administración
Dinos qué activos quieres auditar. Respondemos en menos de 24 horas.