¿Qué propósito tiene Access-Control-Allow-Origin?

4

Tengo un malentendido con respecto al encabezado Access-Control-Allow-Origin de CORS.

Su nombre dice "permitir", y entiendo que si hago una solicitud desde un "Origen" que no está permitido, la solicitud debe fallar.

Pero siempre puedo cambiar /etc/hosts para que el "Origen" apunte a mi dirección IP.

Por ejemplo, para una respuesta que podría contener esto:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://example.com
Access-Control-Expose-Headers: Access-Control-Allow-Origin,Access-Control-Allow-Credentials

Siempre puedo modificar /etc/hosts y tengo:

127.0.0.1   example.com

... y la llamada funcionará.

¿Qué está permitiendo exactamente este encabezado? ¿Puedo usar Access-Control-Allow-Origin: * en lugar de Access-Control-Allow-Origin: http://example.com ? ¿Cuál es la diferencia?

    
pregunta pepe 14.04.2016 - 17:07
fuente

3 respuestas

3
  

Su nombre dice "permitir", y entiendo que si hago una solicitud desde un "Origen" que no está permitido, la solicitud debe fallar.

Eso es correcto (dependiendo de la solicitud). Pero rechazar una solicitud no es propiedad de CORS , se debe a que misma política de origen .

CORS no es realmente un encabezado destinado a asegurar nada, es un encabezado destinado a debilitar la misma política de origen y permitir solicitudes de origen cruzado (que pueden ser necesarias para algunas aplicaciones).

Especialmente no está diseñado para el control de acceso, por lo que el hecho de que pueda acceder a sitios web a través de cambiar la configuración de sus sistemas no afecta su seguridad de ninguna manera.

    
respondido por el tim 14.04.2016 - 17:29
fuente
3

La política CORS limita lo que el código cargado desde el sitio A y ejecutado en su navegador puede hacer con el sitio B, es decir, limita lo que pueden hacer las solicitudes de origen cruzado. No es para restringir lo que se puede hacer con el sitio B en general, es decir, solo se ocupa de las solicitudes de origen cruzado y no proporciona ningún tipo de control de autenticación.

Tiene razón en que, en teoría, podría modificar su sistema para omitir esta política. Pero el atacante en algún servidor web remoto no puede hacerlo. Si el atacante en el sitio B quiere usar una solicitud entre sitios contra el sitio A, pero el sitio A solo permite el sitio G, entonces el atacante tendría que aparecer como sitio G para su navegador. Para hacer eso, el atacante debe tener acceso a su sistema oa la configuración de DNS del sitio G, que no es algo que uno pueda esperar del atacante.

    
respondido por el Steffen Ullrich 14.04.2016 - 17:36
fuente
0

Access-Control-Allow-Origin cambia la protección ofrecida al usuario final con respecto a cómo la Política de Same Origin maneja AJAX respuestas.

Si un usuario está dispuesto a alterar los archivos del host para cambiar esta protección aún más por su cuenta, entonces lo único que están comprometiendo es su propia seguridad.

El encabezado permite que otro origen lea una respuesta AJAX si se envía una solicitud de origen cruzado al origen que genera el encabezado.

  

¿Puedo usar Access-Control-Allow-Origin: * en lugar de   %código%? Cual es el   diferencia?

La diferencia es que la primera opción permite que cualquier origen lea las respuestas AJAX. La segunda opción solo permite que Access-Control-Allow-Origin: http://example.com lea las respuestas AJAX.

Si http://example.com es verdadero, entonces la primera opción no funcionará: CORS no le permitirá abrir su sitio web a solicitudes con credenciales globales. Si lo hizo, y su sitio web contenía información confidencial (por ejemplo, Gmail puede tener una función AJAX que devuelve los mensajes en la bandeja de entrada), cualquier sitio web que visite un usuario podrá leer esta información confidencial de su sitio web en el contexto de sesión del usuario actual.

Si realmente desea que todos los orígenes puedan leerse desde la sesión del usuario actual, entonces puede leer el encabezado de solicitud Access-Control-Allow-Credentials y luego reflejar este origen en el encabezado Origin (cuidando de desinfectar adecuadamente, por supuesto) , eliminando CRLFs y similares). Esto sería efectivamente lo mismo que generar Access-Control-Allow-Origin y permitir solicitudes con credenciales a través de Access-Control-Allow-Origin: * .

    
respondido por el SilverlightFox 15.04.2016 - 10:44
fuente

Lea otras preguntas en las etiquetas