¿Cómo la vulnerabilidad originada en Facebook Origin de Access-Control-Allow-Origin: null permitió el acceso de origen cruzado?

Soy Ysrael y soy el investigador que encontró esta vulnerabilidad.

Dividamos tu pregunta en 2 partes: A. ¿Cómo se convirtió el origen del navegador en null ? B. ¿Cómo afecta null Origin a los servidores de Facebook?

Empecemos con A. El origen es parte del mecanismo CORS y está destinado a indicar al servidor de dónde proviene la solicitud. Cuando el servidor recibe la solicitud, el servidor puede decidir permitir que este Origen reciba la respuesta. Una de las formas de omitir esta protección fue encontrar un Open-Redirect dentro de una de las páginas, y luego dirigir al usuario al esquema dataURI. En el pasado, dataURI recibió el Origen anterior porque no había otro Origen que darle. Como una mejora de seguridad, el navegador moderno establece el Origen en null para que las solicitudes XHR de esta página dataURI no tengan el Origen adecuado. En Chrome, esta es la situación en cualquier caso, y en Firefox sucede solo cuando la página se actualiza mediante una etiqueta meta a dataURI.

Así es como el origen se convirtió en null .

El ataque 'Originull' utiliza este comportamiento para omitir las comprobaciones de seguridad basadas en el Origin, porque la mayoría de las veces, los programadores no considerarán a null como el valor en este campo.

Ahora vamos a la parte B. Cómo esto afectó a Facebook.

Facebook usa Access-Control-Allow-Origin en sus servidores de Messenger, porque usan un subdominio diferente.

Lo más probable es que el subdominio de Messenger tenga un filtro de seguridad en la entrada, y luego las solicitudes se pasan al servidor interno que responde a los usuarios. Cuando el servidor quería responder, tomó el valor del origen de la solicitud y lo devolvió en el encabezado Access-Control-Allow-Origin . Este diseño de desarrollo permite a Facebook mantener los Orígenes permitidos en un solo lugar.

El subdominio de messenger también permite solicitudes GET regulares. Las solicitudes GET regulares no tenían ningún encabezado de Origen. En muchos lenguajes de desarrollo, un encabezado no existente devuelve el valor null .

Entonces, el filtro tiene una condición que permite que null pase (para que las solicitudes GET se pasen correctamente), y el servidor toma el valor que recibe en el encabezado de origen de la solicitud ( null ) y lo devuelve a el cliente en el encabezado Access-Control-Allow-Origin .

Simple, ¿verdad? ;)

Puede encontrar los detalles técnicos y las capturas de pantalla en el documento de divulgación completa en el sitio web de BusSec en: enlace

Es posible explotar Access-Control-Allow-Origin: null porque los recursos cargados sobre elementos como URI de datos y iframes de espacio aislado utilizan el origen null . Un PDF que documenta el exploit confirma que Originull usó un documento URI de datos para explotar este encabezado para lograr acceso de origen cruzado .

Por esta razón, el W3C recomienda evitar devolver este valor para el encabezado.

  

7.4. Evite devolver Access-Control-Allow-Origin: "null"

     

Puede parecer seguro devolver Access-Control-Allow-Origin: "null" , pero la serialización del Origen de cualquier recurso que usa un esquema no jerárquico (como data: o file: ) y los documentos de espacio aislado se definen como "nulos" . Muchos Agentes de usuario otorgarán a dichos documentos acceso a una respuesta con un encabezado Access-Control-Allow-Origin: "null" , y cualquier origen puede crear un documento hostil con un Origen "nulo". Por lo tanto, debe evitarse el valor "nulo" para el encabezado ACAO.

     

    

La simple comparación de cadenas de CORS aplicada a "null" es controvertida. Algunos creen que "nulo" debe tratarse como un token de palabra clave que indica la falta de un origen, que, cuando se prueba, nunca debe compararse con otro origen "nulo". (Como es el caso con los valores de null en SQL, por ejemplo). No es aconsejable construir sistemas que se basen en la comparación "nula" es igual a "nula" ya que este comportamiento puede cambiar en el futuro.

  

Resulta que un valor de null actualmente no significa nada especial. No es lo mismo que * , es solo un origen no tan especial que actualmente puede coincidir con los recursos sin origen.

Entonces, si devuelves este encabezado (incluso por accidente):

Access-Control-Allow-Origin: null

Sus recursos serán actualmente accesibles de origen cruzado.