CORS Mal Configurado

Hay un número significativo de sitios en el alexa 1 millón mal configurado de una manera que permite que los datos del usuario sean robados.

El uso compartido de recursos de origen cruzado (CORS) es un método que permite a los sitios web compartir recursos a través de los encabezados HTTP. El caso promedio sin CORS se ve algo como esto. Example1 solicita la raíz web. El agente de usuario no deja que esta respuesta se complete porque viola la Política de Same Origin.
Si example2.com quisiera compartir con example1.com utilizando CORS, la misma solicitud se vería así. Example1 envía un encabezado de Origen, y Example2 responde con un encabezado de Permitir Origen de Control de Acceso, que permite a example1.com hacer lo que sea con los datos. Esta es una configuración bastante básica y hay muchas cosas adicionales que considerar en el mundo real. Por ejemplo, los métodos de solicitud permitidos, si las credenciales pueden o no ser parte de la solicitud, y más.

La hipótesis

Same Origin Policy es la base de la seguridad de las aplicaciones web. La mala configuración de los encabezados de CORS tiene consecuencias masivas como veremos. Supuse que un número significativo de sitios tenía encabezados CORS configurados incorrectamente, lo que permitía que los datos de los usuarios fueran robados por páginas web maliciosas.
Hay dos requisitos clave para que una configuración incorrecta de CORS permita que una página web maliciosa robe datos de usuarios. Primero, los servicios a las víctimas deben devolver un encabezado de Origen de control de acceso apropiado para el encabezado de solicitud de origen que recibe. Un comodín, "*", no es apropiado para nuestros propósitos porque no permite el envío de credenciales necesarias para robar datos específicos del usuario. En segundo lugar, los servicios a las víctimas deben tener un encabezado de respuesta de Control de acceso-Permitir-Credenciales establecido en verdadero. Con estos dos encabezados de respuesta controlados, un ataque se vería así (en el papel).

El ataque

Escanee el top 1m de alexa con un script de bash y cURL. Especifiqué un encabezado de origen especialmente diseñado.
En lugar de enviar el encabezado Origin de evil.com, envié el encabezado Origin de $ domain.evil.com. Esto resulta en engañar a muchos sitios web para reflejar mi encabezado de origen y darme el encabezado Permitir origen que necesitaba. Muchos sitios web verificaron la aparición de su nombre de dominio en el encabezado de Origen. Esta comprobación no es suficiente.

root@ejjio:/var/www/misconfigured-cors# curl -H "Origin: https://ejj.io.evil.com" https://ejj.io -I HTTP/1.1 200 OK Server: cloudflare-nginx Date: Wed, 24 Feb 2016 06:47:21 GMT Content-Type: text/html Set-Cookie: PHPSESSID=sd7ejaf2lufukhq7se49lmsg76; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Access-Control-Allow-Origin: https://ejj.io.evil.com Access-Control-Allow-Credentials: true Vary: Accept-Encoding view raw trickery.sh hosted with ❤ by GitHub Así es como se veía mi script de shell. #!/bin/sh while read -r domain do # Remember. Account for the fact that some sites don't exist on HTTP # And others don't exist on HTTPS. Prune later. curl -I "https://$domain" --max-time 3 -H "Origin: https://$domain.evil.com" | ./respirator& curl -I "http://$domain" --max-time 3 -H "Origin: http://$domain.evil.com" | ./respirator& done < "top1mdomains" view raw cors-scanner.sh hosted with ❤ by GitHub

Grepping encabezados y registros no es realmente comprensible o comprensible para pasar a los lectores oyu. En lugar de eso, escribí un pequeño programa de Golang , al que se hace referencia anteriormente como respirador, que lee crudamente los encabezados de respuesta HTTP y los convierte en JSON si la respuesta indica que el sitio podría estar mal configurado. De esa manera, al final de mi escaneo, tenía una gran cantidad de sitios que mirar.
Aquí hay una lista de sitios que encontré que devuelven tanto el encabezado de origen reflejado como el encabezado Permitir credenciales de control de acceso a verdadero, desde el top 1 de alexa . Es bueno tener en cuenta que agregué el nombre de dominio a cada entrada JSON de los encabezados de respuesta HTTP como "x-hostname", pero agregué un punto adicional al final que era un error, no una característica.

La Conclusión y Preguntas Abiertas

La conclusión es que muchos sitios pueden tener encabezados de CORS mal configurados, lo que es un desglose completo en la base de la seguridad de la aplicación web, la Política del mismo origen. El RFC para CORS y estos encabezados están disponibles, pero este es un tema intrínsecamente confuso con muchas partes móviles. Incluso no entiendo completamente todas las entradas y salidas de Same Origin Policy y CORS. Hay muchos detalles en los RFC que se eliminan al usar una tecnología.
Este tipo de cosas me hace preguntarme si las personas que escriben RFC deberían pasar a hacer RFC completas para las RFC simples muertas que tienen menos probabilidades de cometer errores por parte de los consumidores de RFC. En cuanto a los RFC más nuevos como HPKP y HSTS, este no es el caso, ya que estos RFC brindan muchas oportunidades para disparar con el pie.
Algunos patrones extraños que noté es que muchos sitios web que posiblemente estaban mal configurados también respondieron con un encabezado "Via: vegur". Aproximadamente el 10% de todos los sitios que pueden estar mal configurados. No investigué esto más allá.
Solo para notar, esta no es la única configuración CORS que es mala. Varias personas con las que hablé sobre esto señalaron que las API internas son a menudo los peores abusadores de CORS. Las API no autenticadas con Control de acceso Permitir origen * significa que un atacante que conoce el nombre de dominio interno a través de una filtración de URL puede utilizar a los empleados de la empresa para pasar a los activos internos. Esto es algo similar a la unidad por ataque de enrutador, con CSRF. Tampoco es necesariamente una mala respuesta responder con los encabezados Permitir origen de control de acceso.
Finalmente, la seguridad es contextual. No todos los sitios en el vertedero están mal configurados, pero es una apuesta segura que muchos de ellos lo están. Los sitios tradicionales que requieren un nombre de usuario y una contraseña con esta configuración casi seguro están mal configurados. Las páginas estáticas que muestran 'páginas de manual' o algo pueden estar mal configuradas, pero eso no importa.