sobre CSRF en el formulario enviar [duplicar]

La razón por la que los sitios pueden hacerse pasar por usuarios que realizan acciones es porque los navegadores enviarán voluntariamente un <form> a cualquier otro dominio especificado usando el atributo action sin importar que los orígenes sean los mismos o cualquier otra restricción provista por el dominio de destino. El dominio original no tiene forma de leer lo que recibió el usuario o si la solicitud fue exitosa. El dominio original es simplemente enviar al usuario al dominio de destino para realizar una acción específica. *

La razón por la que este ataque CSRF no funciona cuando se usa un token es porque el usuario también envía cookies relevantes al dominio de destino con cada solicitud. El dominio original no tiene forma de leerlos porque las cookies no funcionan en varios dominios, excepto en ciertos casos en los que el dominio de destino muestra relación con el otro. Por lo tanto, no debería poder predecir de manera confiable cuál es el token en el dominio de destino.

Todo lo que debe hacer el dominio de destino es verificar que el valor enviado en la solicitud coincida con la cookie enviada.

<sup>* dominio original : dominio que obliga a un usuario a enviar la solicitud POST / GET
* dominio de destino : el dominio recibe la solicitud y "posee" la cookie de token CSRF.</sup>

El dominio original no tiene forma de ver el token porque fallaría cualquier solicitud:

1. Si el dominio original lo solicitó usando PHP, el dominio de destino debería mostrar una cookie totalmente irrelevante para ese "usuario" específico (el servidor de dominio original, no el usuario atacado).
2. Si el dominio original intenta leer la cookie, el navegador solo debería mostrar las cookies relevantes para el dominio original, eliminando la posibilidad de leer una cookie de otro dominio.
3. Si el dominio original solicitó una página con JavaScript, el navegador debería rechazarla porque no se permiten las solicitudes ajax entre dominios (suponiendo que el dominio de destino no lo permita explícitamente).

  

Si el atacante es lo suficientemente bueno como para hacerme enviar un formulario (como se mencionó   por OWASP) lo que le impediría recibir el token antes   enviando?

La única habilidad que debe tener un atacante es la capacidad de escribir HTML y javascript y saber cuál es la solicitud que intentan atacar. Estas son todas cosas que son fácilmente accesibles y no son secretas de ninguna manera.

Entonces, tu suposición de que la capacidad de crear un formulario de alguna manera significa que pueden predecir tokens aleatorios es incorrecta.

Cada token es único para un usuario autenticado y, a menos que exista otra vulnerabilidad, no hay una forma de averiguar qué es ese token.

En función de cómo se formule su pregunta, no estoy seguro de que tenga una idea completa de cómo funciona el CSRF. Esto no pretende ser un insulto, puede ser un concepto difícil de entender inicialmente.

Mi sugerencia sería crear un formulario que sea vulnerable a este tipo de ataque y luego ejecutar un ataque contra él. Esta es una excelente manera de comprender a fondo cómo funciona este ataque. Una vez que hagas esto, sospecho que entenderás mejor esta respuesta.

¡Salud!

ACTUALIZACIÓN:

Parece que podría estar suponiendo que CSRF y XSS son lo mismo. Solo para aclarar, en un sitio con solo una vulnerabilidad CSRF, un usuario malintencionado no puede insertar ningún javascript. Así que no hay manera de usar javascript para obtener el token. Si un sitio tiene una vulnerabilidad XSS, entonces no es necesario ejecutar un ataque CSRF, ya que sería mucho más fácil simplemente inyectar javascript que haga lo que usted quiere. Además, un CSRF es un ataque "de una sola vía", lo que significa que puede enviar una solicitud como alguien, pero no puede leer el resultado. ¿Esto tiene sentido?

ACTUALIZACIÓN 2:

con respecto a tu comentario:

  

Gracias por aclarar, estaba mirando la página de OWASP vinculada en el   pregunta, sección POST escenario, la carga de envío, no es que un CSRF   atacar con javascript inyectable?

Ahh, veo tu confusión. No, el javascript que están mostrando está en el sitio controlado por el atacante. Entonces, si el atacante controla evil.com , el javascript estaría allí, y simplemente se usa para iniciar una solicitud HTTP para targetSite.com usando una sesión existente de los usuarios. CSRF es un ataque a las sesiones existentes que tiene lugar en el nivel de solicitud HTTP. Podría usar javascript para lanzar este ataque, pero el ataque sigue siendo una solicitud HTTP.

No soy un experto en CSRF (por favor comente si tengo ideas erróneas), pero de wikipedia :

  

Bajo la [ política del mismo origen ], un navegador web permite que los scripts contenidos en una primera página web accedan a los datos en una segunda página web, pero solo si ambas páginas web tienen el mismo origen. Un origen se define como una combinación de esquema de URI, nombre de host y número de puerto.

Un ejemplo simplificado es: digamos que tiene 3 pestañas abiertas en su navegador que han cargado scripts de tres fuentes: 1.aaa.com , 2.aaa.com y www.bbb.com . Su navegador, bajo la política del mismo origen (SOP), permitirá que los scripts de 1.aaa.com y 2.aaa.com lean y escriban datos de los demás datos. Así es como Facebook permanece conectado en todas sus pestañas (incluso en páginas que no son de Facebook, ya que los scripts de Facebook incrustados se cargan dinámicamente desde *.facebook.com y, por lo tanto, tienen el mismo origen).

Sin embargo, un navegador que implemente SOP evitará que las secuencias de comandos www.bbb.com puedan leer los datos destinados a las secuencias de comandos *.aaa.com . Esto evita que un script malicioso vea ese token aleatorio que otro script ha asignado. SOP no bloquea las escrituras, por lo que un script malicioso todavía puede enviar solicitudes que dicen ser otro script, pero a menos que pueda adivinar el token aleatorio, esa solicitud se ignorará.

Estoy de acuerdo en que el sistema es un poco torpe, pero funciona.

Sin la comprobación de token, el atacante ni siquiera necesitaría inyectar javascript.

Por ejemplo, crean un formulario en enlace que se envía a una acción en enlace . En lugar de inyectar javascript en el sitio de destino, pueden colocarlo directamente en el sitio que controlan y engañarlo para que lo visite. La solicitud POST seguirá incluyendo las cookies de target.example. Si no comprueba si hay un token, entonces el envío del formulario se aceptará como si hubiera venido directamente de target.example.

Sin embargo, si hay una comprobación de token, evil.example no puede obtener el token debido a la política del mismo origen. Así que necesitarían una vulnerabilidad adicional en el sitio objetivo. Por ejemplo, XSS permitiría al atacante recuperar el token a través de AJAX.