Encontré una gran cantidad de sitios populares que no tienen el token crsf en el encabezado de la cookie, ¿significa que todos estos sitios son vulnerables?
Intenté aprender más sobre eso y descubrí que hay algo llamado CORS que lo protege, pero no puedo entender qué es.
Si es posible, comparta su metodología, por ejemplo, ¿para qué probará si no encuentra un sitio con el token crsf? ¿Cómo comprobarás si tiene uno o no?
La respuesta simple es "no". Los tokens de falsificación de solicitudes entre sitios (CSRF, por sus siglas en inglés) son una defensa generalizada contra CSRF, pero otras condiciones deben estar en juego para ser vulnerables. Por ejemplo, el atacante debe poder realizar de manera predecible una solicitud válida al sitio. También hay otros factores de diseño que se pueden usar para mitigar la amenaza de CSRF.
Las cookies de autenticación / sesión tienden a hacer que los ataques sean más fáciles porque se envían con cualquier solicitud al dominio, independientemente de que la solicitud provenga del mismo sitio de origen. El Intercambio de recursos de origen cruzado (CORS) ayuda a evitar esto al bloquear las solicitudes de origen cruzado a menos que el sitio en el que se realiza la solicitud permita explícitamente las solicitudes de origen cruzado. Sin embargo, las solicitudes GET generalmente se permiten siempre que no se realicen a través de JavaScript, por lo que a veces un ataque CSRF puede colarse solicitando contenido usando una etiqueta de imagen.
Relacionado con las cookies de autenticación ... otra mitigación contra CSRF podría ser enviar el token de autenticación como encabezado, en lugar de una cookie. Esto requiere que sus solicitudes tengan el token agregado explícitamente con cada solicitud, lo que mitiga el riesgo de que el navegador agregue automáticamente la autorización a las solicitudes no realizadas por su propio código. Por lo general, el token se almacena en el Almacenamiento local, al que solo se puede acceder desde el código que se carga desde el mismo dominio que el código que lo guardó.
Como se mencionó anteriormente, para ser vulnerable, el código malicioso debe poder predecir cómo debe interactuar con el sitio para obtener una respuesta útil. Por ejemplo, si el sitio atacado era un banco, el código malicioso debe poder determinar los detalles completos de una solicitud de transferencia de dinero para poder hacerlo. Si la solicitud de transferencia de dinero supone una cuenta de origen predeterminada, es mucho más fácil para el atacante, ya que no tendrá que adivinar esa información porque el servidor asumió el contexto del usuario de forma predeterminada.
Dicho esto, en la mayoría de los casos, el atacante puede acceder bastante al usuario desde su sitio si tiene tiempo suficiente para jugar desde su propia cuenta. Por lo tanto, asumir que el atacante no puede hacer algo porque una solicitud entre sitios no tendría éxito en un solo paso sería una locura. En el ejemplo anterior, solo tendrían que hacer una solicitud para obtener una lista de las cuentas de los usuarios antes de que puedan hacer una solicitud para transferir dinero.
La declaración, "todo sitio sin un token CSRF es vulnerable a un ataque CSRF", no es exacto. Ciertamente, no se aplica a los sitios web estáticos que no tienen funcionalidad del lado del servidor, donde CSRF ni siquiera es aplicable / posible. Además, el
Agregando tokens CSRF, una cookie de doble envío y valor, token encriptado, u otra defensa que implique cambiar la interfaz de usuario puede ser frecuentemente Complejos o de otro modo problemáticos. Una defensa alternativa que es particularmente adecuado para los puntos finales AJAX es el uso de un personalizado encabezado de solicitud Esta defensa se basa en la política del mismo origen (SOP) restricción de que solo se puede usar JavaScript para agregar un encabezado personalizado, Y solo dentro de su origen. Por defecto, los navegadores no permiten JavaScript para realizar solicitudes de origen cruzado.
Un encabezado personalizado y un valor particularmente atractivo para usar es:
X-Requested-With: XMLHttpRequest
o
A veces es más fácil o más apropiado involucrar al usuario en la transacción para evitar transacciones no autorizadas (falsificadas u otras).
Los siguientes son algunos ejemplos de opciones de desafío-respuesta:
- Re-autenticación (contraseña o más fuerte)
- Token de una sola vez
- CAPTCHA
De lo contrario, cualquier aplicación web que no implemente ninguno de estos mecanismos y tenga solicitudes GET o POST de HTTP que inicien acciones puede ser vulnerable.
CSRF y CORS son conceptos bastante separados, aunque existe cierta similitud, al menos en la raíz de todo.
CORS, o Cross-Origin-Resource-Sharing permite a un servidor definir una política de la cual los orígenes (otros dominios) pueden recuperar información de él. Aunque la política predeterminada impide que otro origen lea datos, no impide que un ataque CSRF tenga éxito.
Por favor, comparta su metodología si es posible, por ejemplo, ¿para qué analizará? Si no encuentras un sitio con crsf token? ¿Cómo vas a comprobar si tiene uno o no?
Puede buscar un token CSRF examinando las cookies, el cuerpo de la solicitud y el HTML, aunque puede depender del sistema específico utilizado.
Puede probar las vulnerabilidades de CSRF creando una página HTML de prueba que intente realizar solicitudes confidenciales hacia el sitio web en cuestión.