La falsificación de solicitud entre sitios (CSRF) es una de las vulnerabilidades más graves que se puede explotar de varias maneras, desde cambiar la información del usuario sin su conocimiento hasta obtener acceso completo a la cuenta del usuario.
Casi todos los sitios web utilizan cookies hoy en día para mantener la sesión de un usuario. Dado que HTTP es un protocolo «sin estado», no existe una forma integrada de mantener a un usuario autenticado para una serie de requests. Pedir al usuario sus credenciales en cada operación es una muy mala idea en términos de experiencia del usuario, por eso se utilizan cookies. Las cookies son muy eficaces para este propósito y son seguras si poseen suficiente entropía, fuerza criptográfica y se transmiten a través de un canal seguro (mediante HTTPS ).
Sin embargo, hay un problema, los navegadores envían cookies a un sitio web cada vez que se realiza una solicitud a ese sitio web sin verificar el «origen» de la solicitud. Aquí es donde CSRF entra en escena.
El atacante coloca un código en su sitio web que hace una solicitud de apariencia genuina al sitio web de destino. Las cookies del sitio web de destino serán añadidas por el navegador en la solicitud. Esto hará que esa solicitud falsificada sea legal y su acción se llevará a cabo con éxito.
Superficies de ataque:
las superficies de ataque para CSRF son en su mayoría requests HTTP que provocan un cambio en algo relacionado con la víctima, por ejemplo: nombre, dirección de correo electrónico, sitio web e incluso contraseña. A veces también se usa para alterar el estado de autenticación. (Iniciar sesión CSRF, Cerrar sesión CSRF) que son menos graves pero aún pueden ser problemáticos en algunos casos.
Explotación:
considere un sitio web example.com y el sitio web del atacante evil.com. Suponga también que la víctima ha iniciado sesión y su sesión se mantiene mediante cookies. El atacante:
- Descubra qué acción debe realizar en nombre de la víctima y descubra su punto final (por ejemplo, para cambiar la contraseña en target.com, se realiza una solicitud POST al sitio web que contiene la nueva contraseña como parámetro).
- Coloque código HTML en su sitio web evil.com que imitará una solicitud legal a target.com (por ejemplo, un formulario con método como publicación y un campo de entrada oculto que contiene la nueva contraseña).
- Asegúrese de que el formulario se envíe utilizando «autoenviar» o atrayendo a la víctima para que haga clic en un botón de envío.
Cuando la víctima visita evil.com y se envía ese formulario, el navegador de la víctima solicita un cambio de contraseña a target.com. Además, el navegador agrega las cookies con la solicitud. El servidor lo trata como una solicitud genuina y restablece la contraseña de la víctima al valor proporcionado por el atacante. De esta manera, el atacante se hace cargo de la cuenta de la víctima.
Prevención:
- Del lado del usuario:
la prevención del lado del usuario es muy ineficiente en términos de experiencia de navegación, la prevención se puede hacer navegando solo una pestaña a la vez y sin usar la funcionalidad «recordarme». - En el lado del servidor:
hay muchas formas propuestas de implementar la protección CSRF en el lado del servidor, entre las cuales el uso de tokens CSRF es el más popular. Un token CSRF es una string que está vinculada a la sesión de un usuario pero que no se envía automáticamente. Un sitio web continúa solo cuando recibe un token CSRF válido junto con las cookies, ya que no hay forma de que un atacante conozca un token específico del usuario, el atacante no puede realizar acciones en nombre del usuario.
Publicación traducida automáticamente
Artículo escrito por awasthi7xenextt y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA