¿Los ataques CSRF son realmente ciegos?

La Política del mismo origen hace imposible que JavaScript en A.com lea contenido de B .com. Sin embargo, la Política del mismo origen no impide que JavaScript o HTML en A.com envíen una solicitud arbitraria a B.com. Para evitar esto, necesita un método de CSRF Prevention , como un token secreto que no funcionaría si el sistema no fuera ciego.

El punto de CSRF es que incurre en un efecto secundario útil, como cambiar la contraseña de un usuario o agregar una cuenta administrativa. Incluso si CSRF no fuera ciego (debido a un poco de magia, o quizás un CORS mal configurado o un conjunto de reglas crossdomain.xml) no importaría ya que la respuesta probablemente se descartaría, todo lo que importa es un efecto secundario útil.

Es muy fácil enviar solicitudes GET y POST entre dominios, si una solicitud GET incurre en un efecto secundario, entonces es vulnerable a CSRF. Un buen ejemplo de esto es una aplicación PHP que usa $_REQUEST para todas las entradas.

Sí, son ciegos. La política del mismo origen evita que las páginas alojadas en un dominio que usan un protocolo [y, a veces, también, puerto] hagan solicitudes arbitrarias a un dominio / protocolo diferente. Entonces, un atacante no podría realizar una "solicitud Ajax CSRF" a menos que su servidor admita CORS . Lo que hace que los ataques CSRF sean posibles son las excepciones para la política del mismo origen, es decir, los tipos de solicitud que cualquier sitio web puede realizar a cualquier host.

La mayoría de las excepciones a la política del mismo origen, sin embargo, no le permite hacer nada útil (incluida la lectura) con la respuesta:

• Puede configurar src de una imagen en otro dominio, pero la respuesta se mostrará correctamente como una imagen para que el usuario la vea o no mostrará nada en absoluto;
• Puede establecer un src de un script para otro dominio, pero se ejecutará o causará un error de sintaxis o similar;
• Puede vincularse a una hoja de estilo externa, pero no puede acceder a su contenido mediante programación;
• Puede incluir otra página en frame ou iframe , pero no puede acceder a sus contenidos DOM debido a la política del mismo origen; etc.

Es por eso que, como ya lo han indicado otros, la respuesta no es lo que es interesante para un atacante, sino los efectos secundarios que puede tener la solicitud.

En primer lugar, los ataques CSRF no requieren ningún JavaScript en absoluto. Puede falsificar solicitudes arbitrarias con HTML puro para enviar solicitudes GET o POST a través de imágenes simples o formularios simples.

JavaScript solo sería útil para enviar automáticamente los últimos formularios, ya que no se envían automáticamente como lo haría una solicitud de imagen. Pero también puede aplicar un estilo al botón de envío del formulario para abarcar toda la página y hacerlo transparente para que el usuario no lo vea, pero si hace clic en algún lugar de la página, se enviará el formulario.

En la mayoría de los casos, enviar la solicitud falsificada es suficiente para el atacante, ya que la intención es simplemente desencadenar una acción en nombre de la víctima y en el contexto de la sesión. Para esto es suficiente un simple formulario HTML.

Pero con JavaScript, Política del mismo origen entra en juego, lo que lo hace mucho más difícil. El origin se determina en el URI del documento (es decir, el esquema, el host y el puerto). Solo si el origen de dos documentos o recursos es idéntico, los dos documentos / recursos son del mismo origen. Si no son del mismo origen, la Política del mismo origen básicamente no permite ninguna solicitud XHR o acceso directo a través de DOM (por ejemplo, marcos).

Con la segunda versión de XMLHttpRequest (XHR) , la tecnología utilizada con Ajax, se permitieron las solicitudes de origen cruzado bajo ciertas circunstancias definidas en Intercambio de recursos entre orígenes . Las reglas básicas son que se permiten solicitudes de origen cruzado simples mientras que otras requieren una solicitud de verificación previa a la solicitud real . Esa verificación previa se utiliza para determinar si el servidor aceptaría la solicitud real. Solo si la solicitud de verificación previa se realiza correctamente, la solicitud real se envía.

Sin embargo, incluso si es solo una solicitud simple y la solicitud es exitosa, el servidor todavía puede impedir que el navegador haga que la respuesta esté disponible para JavaScript, nuevamente a través de ciertos campos de encabezado de respuesta definidos en CORS.

En cuanto a los ataques CSRF, especialmente el último tipo de solicitudes de origen cruzado son valiosas ya que contendrían credenciales de usuario como información de autenticación HTTP, cookies, etc., que serían necesarias para desencadenar acciones privilegiadas en el servidor. Pero a menos que el recurso permita este tipo de solicitudes de origen cruzado , el navegador no permitirá que JavaScript envía estos.

Entonces la conclusión es:

• CSRF no requiere JavaScript, sin embargo, facilita mucho la explotación automática.
• La falsificación de solicitudes basada en HTML simple es mucho más prometedora debido a la falta de conformidad con la Política del mismo origen, que requiere JavaScript.
• Leer la respuesta solo es posible con JavaScript, pero requiere que el recurso lo permita, especialmente si se requieren credenciales de usuario.