security - validate - html form without csrf protection
Comprender CSRF (4)
No entiendo cómo el uso de un ''token de desafío'' agregaría cualquier tipo de prevención: ¿qué valor debería compararse con qué?
De OWASP :
En general, los desarrolladores solo necesitan generar este token una vez para la sesión actual. Después de la generación inicial de este token, el valor se almacena en la sesión y se utiliza para cada solicitud posterior hasta que caduque la sesión.
Si entiendo el proceso correctamente, esto es lo que sucede.
Me conecto en http://example.com y se crea una sesión / cookie que contiene este token aleatorio. Luego, cada formulario incluye una entrada oculta que también contiene este valor aleatorio de la sesión que se compara con la sesión / cookie al enviar el formulario.
Pero, ¿qué logra eso? ¿No estás tomando datos de sesión, colocándolos en la página y luego comparándolos con los mismos datos de sesión? Parece un razonamiento circular. Estos artículos siguen hablando de seguir la "política del mismo origen", pero eso no tiene sentido, porque todos los ataques CSRF SON del mismo origen que el usuario, simplemente engaña al usuario para que realice acciones que no tenía intención de realizar.
¿Hay alguna otra alternativa que no sea agregar el token a cada URL como una cadena de consulta? Parece muy feo e impráctico, y hace que los marcadores sean más difíciles para el usuario.
¿Hay alguna otra alternativa que no sea agregar el token a cada URL como una cadena de consulta? Parece muy feo e impráctico, y hace que los marcadores sean más difíciles para el usuario.
No hay ninguna razón para agregar el token a cada URL en su sitio, siempre y cuando se asegure de que todas las solicitudes GET en su sitio sean de solo lectura. Si está utilizando una solicitud GET para modificar los datos en el servidor, debe protegerlo utilizando un token CSRF.
La parte divertida de CSRF es que, aunque un atacante puede realizar cualquier solicitud HTTP a su sitio, no puede leer la respuesta.
Si tiene URLs GET sin un token aleatorio, el atacante podrá realizar una solicitud, pero no podrá volver a leer la respuesta. Si esa url cambió algún estado en el servidor, el trabajo de los atacantes ya está hecho. Pero si acaba de generar algunos html, el atacante no ha ganado nada y no ha perdido nada.
Explicación CSRF con una analogía - Ejemplo:
Imagina que vuelves a casa y abres la puerta con una llave: tu llave. nadie más tiene tu llave Abre la puerta, pero antes de entrar, su vecino lo llama desde el otro lado de la calle y ambos tienen una conversación muy amistosa sobre el clima o quizás los últimos tweets de 3.45 a.m. del presidente Trump, etc. Mientras está teniendo esta conversación, sin saberlo usted, alguien más lo ve afuera, y decide hacerse pasar por su misma ropa y peinado y decide ir a su propia casa haciéndose pasar por usted!
Nadie dentro de tu casa nota nada diferente, tu esposa dice, ''oh crud *, él está en casa''.
El imitador se ayuda a sí mismo con todo su dinero, y quizás juegue algo de Xbox en el camino de salida y nadie lo sepa.
CSRF básicamente se basa en el hecho de que usted abrió la puerta de su casa y luego la dejó abierta, permitiendo que otra persona simplemente camine y finja ser usted.
¿Cuál es la forma de resolver este problema?
Cuando abre la puerta de su casa por primera vez, se le entrega un papel con un número largo y muy aleatorio escrito por su hombre de la puerta:
"ASDFLJWERLI2343234"
Ahora, si quieres entrar a tu propia casa, debes presentar esa hoja de papel al hombre de la puerta para que se meta.
Entonces, cuando el imitador intente entrar a su casa, el hombre de la puerta pregunta:
"¿Cuál es el número aleatorio escrito en el papel?"
Si el imitador no tiene el número correcto, entonces no podrá entrar. O eso o debe adivinar el número aleatorio correctamente, lo cual es una tarea muy difícil. Lo que es peor es que el número aleatorio es válido por solo 20 minutos (por ejemplo). Entonces, sepa que el imitador debe adivinar correctamente, y no solo eso, solo tiene 20 minutos para obtener la respuesta correcta. ¡Eso es demasiado esfuerzo! Entonces él se da por vencido.
Por supuesto, la analogía es un poco tensa, pero espero que sea útil para ti.
** crud = (Crear, Leer, Eliminar Actualizado)
El atacante no tiene forma de obtener el token. Por lo tanto, las solicitudes no tendrán ningún efecto.
Recomiendo esta publicación de Gnucitizen. Tiene una explicación CSRF bastante decente: http://www.gnucitizen.org/blog/csrf-demystified/
Necesitas seguir investigando este tema por ti mismo, pero supongo que es por eso que estás publicando en SO :). CSRF es un tipo de vulnerabilidad muy serio y extendido que todos los desarrolladores de aplicaciones web deberían conocer.
En primer lugar, hay más de una misma política de origen . Pero la parte más importante es que un script alojado en http://whatever.com no puede leer datos desde http://victom.com , pero puede ENVIAR datos a través de POST y GET. Si la solicitud solo contiene información conocida por el atacante, el atacante puede falsificar una solicitud en el navegador de victom y enviarla a cualquier parte . Aquí hay 3 exploits XSRF que están creando solicitudes que no contienen un token aleatorio.
Si el sitio contiene un token aleatorio, debe usar XSS para eludir la protección que brinda la Política de mismo origen. Usando XSS puedes forzar javascript a "originar" desde otro dominio, luego puede usar XmlHttpRequest para leer el token y falsificar la solicitud. Aquí hay un exploit que escribí que hace exactamente eso.