¿Cuáles son los lugares donde se debe buscar una falla de CSRF? [cerrado]

La falsificación de solicitud entre sitios (CSRF) está realizando una solicitud "falsificada" del sitio del atacante a otro sitio donde la víctima está registrada. Si ese sitio es vulnerable, cualquier acción que el usuario pueda realizar normalmente en el sitio puede ahora Ser realizado por el atacante.

Una acción interesante para realizar a través de CSRF es cambiar la contraseña o la dirección de correo electrónico, ya que esto se traduce en la toma de posesión de la cuenta. Para las contraseñas, esto es a menudo imposible, ya que tiene que completar la contraseña anterior, pero para las direcciones de correo electrónico a veces se olvida.

Otras acciones interesantes dependen en gran medida de cuál sea el propósito del sitio atacado. Aquí, en la sec.se, desencadenaría upvotes en todas mis preguntas y respuestas a través de CSRF.

Se supone que las solicitudes que realizan alguna acción tienen protección CSRF y son interesantes para probar. La mayoría de las veces estas son solicitudes POST, pero no siempre. Algunos sitios tienen protección CSRF en todas las solicitudes POST, pero no en las solicitudes GET. En ese caso, es interesante buscar una solicitud GET que realice alguna acción.

Una solicitud que a menudo se puede falsificar es cerrar la sesión del usuario. En la mayoría de los sitios, simplemente visitar / cerrar sesión o algo así cerrará la sesión del usuario. Esto es técnicamente CSRF, aunque con un impacto bastante mundano.

La protección CSRF se realiza normalmente enviando un token aleatorio junto con cualquier solicitud. El atacante no tendría este token y, por lo tanto, no puede falsificar una solicitud válida.

A veces, el sitio verifica los encabezados del Referer o del Origen para verificar que la solicitud proviene del propio sitio. Esto puede ser seguro, pero es un poco más difícil de corregir. A veces, el sitio comprueba si " enlace " está contenido en el Referer, en cuyo caso puede ser atacado por usando " enlace " como la página de ataque. A veces, la comprobación no se realiza si falta el encabezado del Referer, que el atacante puede activar a través de un política de referencia .

Finalmente, Las cookies del mismo sitio proporcionan la información adecuada. protección contra CSRF, pero solo para los navegadores que los admiten.

La versión corta es, como @AndrolGenhald lo puso, "Literalmente, cualquier solicitud que cambie el estado de la aplicación". Los lugares más comunes para mirar son las etiquetas HTML <form> , ya que todo el objetivo es proporcionar una manera de enviar datos al servidor (generalmente, cambiar el estado de la aplicación web), pero también puede encuentre solicitudes no identificadas (cambio de estado) en otros lugares, como solicitudes XHR o Fetch, o solicitudes GET iniciadas por enlaces o botones que no sean "enviar".

En general, una buena manera de encontrar CSRF es recorrer un sitio web, mientras se procesa todo el tráfico a través de un proxy de intercepción HTTP (Burp Suite es la herramienta estándar para pentesters, pero en un apuro puede usar otros proxies también) . El proxy le mostrará cuál es el tráfico de red real, incluidas las cosas que tal vez ni siquiera sepa que estaban allí. Cada vez que haga algo que cambie el estado de la aplicación, verifique el tráfico de red en el registro de proxy y vea si hay algún tipo de token de protección CSRF. También puede validar que el token se usa correctamente haciendo cosas como reproducir las solicitudes sin el token correcto o sin el token, o comparando dos sesiones de usuario diferentes para asegurarse de que el token sea diferente y que un usuario no pueda predecir el token de otro usuario .

En la mayoría de los casos, a menos que el servidor haya hecho algo muy tonto con su configuración CORS, los tipos de solicitud que no sean GET, HEAD, POST u OPTIONS no se pueden realizar en sitios cruzados, por lo que verbos como PUT, PATCH, etc. multa. Sin embargo, tenga en cuenta que algunos servidores le permitirán usar el verbo "incorrecto" para una solicitud y cumplirlo de todos modos; intente cambiar el método de solicitud y ver si aún pasa. De manera similar, los tipos de contenido distintos a los formularios codificados en URL y el texto sin formato son difíciles de enviar de origen cruzado, pero a veces un servidor que espera que JSON acepte con gusto una solicitud que contenga JSON válido en el cuerpo, pero afirma que el tipo de contenido es text/plain y un atacante CSRF puede enviar eso.