Seguridad de la Informacion ¿Cómo funciona un ataque de tipo CSRF?

[pic 1]

 [pic 2]

[pic 3][pic 4][pic 5][pic 6][pic 7]

[pic 8]

Índice

Introducción        2

Ataque CSRF        3

Ejemplo Real        6

¿Cómo funciona un ataque de tipo CSRF?        6

Autenticación: Sesiones y Cookies        6

Videos Explicativos        7

Demostración de un ataque CSRF:        7

Protección contra ataques CSRF:        7

Políticas de CORS:        7

OWASP        8

BSIMM        10

Conclusión        11

Bibliografía        12

Introducción

En los últimos años, la tecnología y la arquitectura de las aplicaciones ha cambiado significativamente. Los microservicios escritos en node.js y Spring Boot reemplazan a las aplicaciones monolíticas tradicionales. Estos microservicios tienen sus propios desafíos de seguridad, incluyendo el establecimiento de confianza entre microservicios, contenedores, gestión de secretos, etc.

El antiguo código, que nunca esperó ser accesible desde Internet, ahora se encuentra detrás de un API o servicio RESTful, pudiendo ser consumido por aplicaciones de una sola página (SPAs) y aplicaciones móviles. Con este acceso a la Web, se abre todo un nuevo abanico de posibles amenazas a los sistemas: los ataques informáticos.

Los ataques informáticos son un intento de exponer, desestabilizar, alterar, destruir o de obtener acceso no autorizado a información sensible. Desde el momento en el que nació la informática como la conocemos hoy en día, siempre hubo personas tratando de encontrar la manera de comprometer a las empresas y a sus sistemas. En este trabajo, nos centraremos en un tipo de ataque en específico: Cross Site Request Forgery (CSRF). Empezaremos hablando de en qué consiste este ataque, cómo surgió y daremos varios ejemplos de cómo ha comprometido a varias de las empresas más importantes del mundo (Netflix, YouTube, bancos). También explicaremos cómo lograr protegerse ante estos ataques.

Para hacer la explicación mucho más clara y llevadera hemos decidido programar un ejemplo de ataque CSRF real, mostrando las fortalezas y debilidades del mismo. Luego indagaremos en qué es OWASP y cómo puede ayudarnos a combatir todo este tipo de amenazas. Además, también veremos brevemente en qué consiste BSIMM y cómo puede ayudarnos.

Como cierre hablaremos de la importancia de programar teniendo en cuenta que existen muchos tipos de ataques, y también de la importancia de las buenas prácticas.

Ataque CSRF

Cross-Site Request Forgery, o CSRF, es un ataque que obliga a un usuario final a ejecutar acciones no deseadas en una aplicación web en la que está autenticado. Con herramientas como el envío de un enlace por correo electrónico o chat, es decir Phishing, un atacante puede engañar a los usuarios de una aplicación web para que ejecuten acciones de su elección. Si la víctima es un usuario normal, un ataque CSRF exitoso puede forzar al usuario a realizar solicitudes de cambio de estado como transferir fondos de su cuenta bancaria, cambiar su dirección de correo electrónico, etc. Si la víctima es una cuenta administrativa, el CSRF puede comprometer toda la aplicación web.

     CSRF es un ataque que engaña a la víctima para que envíe una solicitud maliciosa. Hereda la identidad y los privilegios de la víctima para realizar una función no deseada en su nombre. En la mayoría de los sitios, las solicitudes del navegador incluyen automáticamente cualquier credencial asociada al sitio, como la cookie de sesión del usuario, la dirección IP, las credenciales de dominio de Windows, etc. Por lo tanto, si el usuario está autenticado en el sitio, el sitio no tendrá forma de distinguir entre la solicitud falsificada enviada por la víctima y una solicitud legítima enviada por la víctima.

     Los ataques CSRF se dirigen a funcionalidades que provocan un cambio de estado en el servidor, como cambiar la dirección de correo electrónico o la contraseña de la víctima. Forzar a la víctima a recuperar datos no beneficia al atacante porque éste no recibe la respuesta, sino que la víctima lo recibe. Por lo tanto, los ataques CSRF se dirigen a las solicitudes de cambio de estado.

     A veces es posible almacenar el ataque CSRF en el propio sitio vulnerable. Estas vulnerabilidades se denominan "defectos CSRF almacenados". Esto puede lograrse simplemente almacenando una etiqueta IMG o IFRAME en un campo que acepte HTML, o mediante un ataque de scripting cruzado más complejo. Si el ataque puede almacenar un ataque CSRF en el sitio, la gravedad del ataque se amplifica. En particular, la probabilidad aumenta porque es más probable que la víctima vea la página que contiene el ataque que alguna página al azar en Internet. La probabilidad también aumenta porque es seguro que la víctima ya está autenticada en el sitio.

     Los ataques CSRF también se conocen con otros nombres, como XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery y Hostile Linking. Microsoft se refiere a este tipo de ataque como ataque One-Click en su proceso de modelado de amenazas y en muchos lugares de su documentación en línea.

     Un atacante puede lanzar un ataque CSRF cuando conoce la combinación de parámetros y valores que se utilizan en un formulario. Por lo tanto, si se añade un parámetro adicional con un valor desconocido para el atacante y que pueda ser validado por el servidor, se pueden evitar los ataques CSRF.

     Uno de estos parámetros a utilizar puede ser un token anti-CSRF. Un token anti-CSRF es un tipo de protección CSRF del lado del servidor. Es una cadena aleatoria que sólo conocen el navegador del usuario y la aplicación web. El token anti-CSRF suele almacenarse dentro de una variable de sesión. En una página, suele estar en un campo oculto que se envía con la solicitud. Si los valores de la variable de sesión y del campo oculto del formulario coinciden, la aplicación web acepta la solicitud. Si no coinciden, la solicitud se descarta. En este caso, el atacante no conoce el valor exacto del campo oculto del formulario que se necesita para que la solicitud sea aceptada, por lo que no puede lanzar un ataque CSRF. De hecho, debido a la política de mismo origen, el atacante ni siquiera puede leer la respuesta que contiene el token.

...