Si una solicitud CORS no necesita autenticación, ¿por qué no puedo enviarla sin las cookies?

Question

Si una solicitud CORS no necesita autenticación, ¿por qué no puedo enviarla sin las cookies?

#1 de paj28 (3 votos)
#2 de JesseM (1 votos)

7

Muchas veces durante los últimos N años, he necesitado mi propia página (ABC.com) para obtener algunos datos de un origen diferente (XYZ.com) y mostrarlos (todo en JavaScript, sin recuperación del servidor).

Esto no funciona porque XYZ.com no tiene ABC.com en su encabezado Access-Control-Allow-Origin . Si el encabezado incluyera ABC.com, entonces las cookies de mi navegador (a saber, la cookie de autenticación) para XYZ.com se enviarían junto con la solicitud a XYZ.com. Entiendo totalmente por qué el navegador querría impedir que ABC.com realice solicitudes autenticadas a XYZ.com si no tuviera acceso.

Pero en todos mis escenarios, la solicitud realizada a XYZ.com son recursos que están disponibles al público, no se necesitan autenticación / cookies, cualquiera puede obtenerlos. Sé que hay soluciones alternativas para esto (solicite los datos a XYZ.com por el servidor de ABC.com). O XYZ.com puede publicar JSONP. Pero en mis casos, a veces estoy sirviendo mi archivo desde el sistema de archivos local para que no haya ningún servidor. Conseguirlo desde un servidor es un PITA. Y por último, no he tenido el control de XYZ.com y no puedo forzarlo a que también publique JSONP. norte La pregunta es: si ABC.com no está en el encabezado de control de acceso para XYZ.com, ¿por qué el navegador no permite que JavaScript de ABC.com realice una solicitud a XYZ.com, PERO NO envíe ninguna de las de XYZ.com? Las cookies se almacenan en el navegador para ese usuario. Si los fabricantes de navegadores hicieron eso, ¿eso abre al usuario a algún otro tipo de vulnerabilidad? Porque no puedo pensar en nada. ¿Qué me estoy perdiendo? ¿Es solo una cuestión de mano de obra, tomará demasiado tiempo programarlo?

access-control cors

pregunta viggity 21.02.2017 - 22:02

fuente

2 respuestas

Lea otras preguntas en las etiquetas access-control cors

cómo configurar mediawiki con restricción de edición ¿Este archivo es malicioso y cómo se transfiere a través de youtube?

score 3 · Answer 1

Historia

Las implementaciones originales de XMLHttpRequest no tenían el concepto de "permitir credenciales": todas las solicitudes tenían credenciales adjuntas. Por supuesto, esto sería extremadamente peligroso permitir el uso de dominios cruzados, por lo que XMLHttpRequest originalmente solo tenía el mismo origen. Cuando se agregó CORS, querían minimizar los cambios para reducir el riesgo de consecuencias no deseadas, por lo que mantener el comportamiento del mismo origen para los sitios que no son CORS tenía sentido.

Autenticación inesperada

Cuando una solicitud no tiene "permitir credenciales", existe el riesgo de que el navegador incluya de forma inadvertida las credenciales. Un ejemplo que el navegador no puede evitar es las restricciones de red, como un sitio de Internet que accede a un sitio de Intranet. Puede haber otros ejemplos, como certificados de cliente. No me sorprendería si algunos navegadores aún adjuntan un certificado de cliente, incluso en una solicitud sin credenciales.

La seguridad primero

Las razones anteriores no son tan fuertes. CORS podría haber sido diseñado para permitir solicitudes sin credenciales de forma predeterminada. Sin embargo, ese es el diseño más arriesgado. Cuando se desarrolló CORS, los diseñadores de navegadores conocían bien los problemas de seguridad y optaron por implementar el diseño menos riesgoso.

score 1 · Answer 2

Creo que es parte de la defensa en capas en el ecosistema del navegador / servidor para ayudar a combatir la falsificación de solicitudes entre sitios (CSRF)

Referencias:

Wikipedia OWASP

Básicamente, los navegadores no saben qué recursos web, o podrían no necesitar cookies o autenticación antes de solicitarlos. Enviar las cookies a ciegas, por el contrario de ABC.com, significa que el navegador no sabe si el usuario quiere que se autentique en XYZ.com o no. Por lo tanto, se equivoca en el lado de la precaución, si no se indica lo contrario.

Desde tu primer párrafo, ya lo entiendes. Entonces, supongamos que ABC.com alberga un panel de mensajes (por ejemplo) y un usuario malintencionado publica algo de javascript. cuando la víctima lee ese mensaje, su navegador ahora lee y ejecuta "solo javascript" desde ABC.com que ABC y XYZ ni respaldan, ni saben nada sobre. Básicamente, el navegador no puede decir qué es "del" propietario de ABC.com, y qué pudo haber sido inyectado por algún mal actor (quizás a través de una red publicitaria alojada).

En cualquier caso, se pueden realizar solicitudes de dominios cruzados, pero no se deben autenticar automáticamente.

Por ejemplo, imagine que ha iniciado sesión en MyBank.com y visite ABC.com, y BadGuy ha escondido una solicitud de javascript en un anuncio que le ha servido y que básicamente dice "http://MyBank.com/xfer-money -to = BadGuy & cantidad = 100.00 "Si su navegador envía las cookies de autenticación, BadGuy puede hacer que su navegador haga algo que no desea. El ejemplo obviamente se simplificó en exceso, pero entiendes la idea.

[Editar] Además, acabo de encontrar esta respuesta ya existente que, creo, se lee mejor que la mía. Añadiendo como referencia. Intercambio de pila de seguridad