¿Por qué regresar exitosamente a los orígenes no permitidos?

Question

¿Por qué regresar exitosamente a los orígenes no permitidos?

#1 de Steffen Ullrich (2 votos)
#2 de Ajedi32 (1 votos)

2

Tal como lo entiendo, con CORS, en las solicitudes de origen cruzado, el navegador enviará un encabezado Origin , y si el origen no está permitido, el servidor seguirá enviando una respuesta 200 con un no -incluyendo el encabezado Access-Control-Allow-Origin (o una respuesta que simplemente carece de ese encabezado), y lo deja en el navegador web para bloquear la respuesta de la página.

Mi pregunta es, ¿por qué el servidor no sería responsable de detectar el origen no permitido y devolvería una respuesta 403 ? ¿No querrías bloquear el contenido para que no se proporcione más arriba?

Como ejemplo,

var xhr = new XMLHttpRequest() ; 
xhr.open( 'GET' , 'https://www.bing.com' ) ; 
xhr.send() ;

web-browser http cors

pregunta martin 13.04.2018 - 10:45

fuente

2 respuestas

2

CORS no funciona como usted describe. No transfiere datos al cliente que no pueden transferirse sin Javascript . Cada solicitud que no se pueda lograr sin Javascript está sujeta a la política y el navegador verificará la política CORS antes de realizar dichas solicitudes. En detalle:

Para solicitudes simples, se permite cualquier acceso de origen cruzado. Las solicitudes simples son las que también podrían activarse sin Javascript al incluir imágenes en sitios cruzados, enviar un formulario, etc., es decir, se trata de solicitudes XHR sin encabezados ni métodos especiales.
Para cualquier otra solicitud (como XHR con encabezado personalizado, métodos diferentes de GET, HEAD y POST) se realiza una solicitud de verificación previa para obtener la política CORS del servidor. Y solo si esta política permitiría las solicitudes previstas, se ejecutará realmente.

Para obtener más información, consulte Mozilla: Intercambio de recursos entre orígenes (CORS) .

Claro, uno podría argumentar que un navegador modificado podría simplemente ignorar la política CORS y solicitar el contenido de todos modos. Pero, un navegador modificado también puede enviar un encabezado de origen falso para engañar al servidor para que proporcione los datos. En otras palabras: CORS no es un reemplazo de la autenticación . En su lugar, está pensado para permitir solicitudes entre sitios utilizando Javascript sin agregar vectores adicionales para los ataques CSRF . Antes de CORS, el sitio web Javascript XHR estaba prohibido y se utilizaban formas inseguras como JSONP.

respondido por el Steffen Ullrich 13.04.2018 - 12:44

fuente

Lea otras preguntas en las etiquetas web-browser http cors

Firma doble con GPG, solo validar una clave Establezca un canal seguro con autenticación mutua con claves públicas compartidas previamente

score 1 · Accepted Answer

Compatibilidad con versiones anteriores

En los días anteriores a que era posible enviar solicitudes HTTP desde JavaScript, no era necesario que los servidores web comprobaran desde qué sitio se originó la solicitud, por lo que no lo hicieron. Cuando JavaScript obtuvo esta capacidad, se tuvo que implementar de una manera que no rompiera la seguridad de los sitios web existentes. Por lo tanto, los navegadores asumieron la responsabilidad de asegurarse de que los datos de un sitio web no puedan ser accedidos por un sitio diferente. (Las solicitudes AJAX de origen cruzado simplemente no funcionarán).

Más tarde, se decidió que esta política era demasiado restrictiva y, por lo tanto, se creó el estándar CORS (Cross-Origin Resource Sharing). Una vez más, este estándar tenía que ser compatible con los servidores existentes, y esos servidores aún no comprobaban el encabezado Origin . ¿Por qué lo harían? Los navegadores ya impidieron el acceso de origen cruzado a los datos del sitio automáticamente; no había necesidad de un cheque separado. Por lo tanto, CORS tenía que requerir que los sitios optaran explícitamente por el acceso de origen cruzado a una página específica. Requerir una opción de exclusión (mediante el rechazo de la solicitud si el encabezado Origin es incorrecto), nuevamente, rompería la seguridad de los sitios existentes. Así nació el encabezado Access-Control-Allow-Origin .

Sin embargo, incluso aparte de la compatibilidad con versiones anteriores, todavía hay un beneficio significativo al no requerir que los servidores verifiquen el encabezado Origin . Para hacer que el acceso de origen cruzado requiera una opción, se garantiza que los desarrolladores y servidores web no comprometan accidentalmente su propia seguridad al no validar correctamente el encabezado Origin Es seguro por defecto en lugar de "inseguro a menos que se asegure de que este encabezado particular esté configurado en el valor correcto".