Pregunta:
¿Por qué es necesario el encabezado Access-Control-Allow-Origin?
Mark Amery
2013-10-10 22:11:40 UTC
view on stackexchange narkive permalink

Entiendo el propósito del encabezado Access-Control-Allow-Credentials , pero no veo el problema del Access-Control-Allow-Origin el encabezado resuelve.

Más precisamente, es fácil ver cómo, si las solicitudes AJAX entre dominios con credenciales estaban permitidas de forma predeterminada, o si algún servidor escupía Access-Control-Allow-Credentials en cada solicitud, los ataques CSRF serían posibles que de otra manera no podrían realizarse. El método de ataque en este escenario sería simple:

  1. Atraer a un usuario desprevenido a mi página maliciosa.
  2. JavaScript en mi página maliciosa envía una solicitud AJAX - con cookies: a alguna página de un sitio de destino.
  3. JavaScript en mi página maliciosa analiza la respuesta a la solicitud AJAX y extrae el token CSRF de ella.
  4. JavaScript en mi página maliciosa utiliza cualquier medio, ya sea AJAX o un recipiente tradicional para una solicitud CSRF, como un formulario POST, para realizar acciones utilizando la combinación de las cookies del usuario y su token CSRF robado.

Sin embargo, lo que no puedo ver es cuál es el propósito de no permitir solicitudes AJAX entre dominios sin credencial sin un Access-Control-Allow-Origin encabezado. Supongamos que creara un navegador que se comportara como si cada respuesta HTTP que alguna vez recibió contuviera

  Access-Control-Allow-Origin: *  

pero aún así requiere un encabezado Access-Control-Allow-Credentials apropiado antes de enviar cookies con solicitudes AJAX entre dominios.

Dado que los tokens CSRF deben estar vinculados a usuarios individuales (es decir, a sesiones individuales cookies), la respuesta a una solicitud AJAX sin credencial no expondría ningún token CSRF. Entonces, ¿a qué método de ataque, si corresponde, al que el navegador hipotético descrito anteriormente expondría a sus usuarios?

Si la página utiliza comprobaciones de dirección IP, ACAO: * es un riesgo en sí mismo
Dos respuestas:
SilverlightFox
2013-10-18 20:00:05 UTC
view on stackexchange narkive permalink

Si le entiendo correctamente, ¿está diciendo por qué el navegador bloquea el acceso a un recurso que se puede obtener libremente a través de Internet si las cookies no están involucradas? Consideremos este escenario:

www.evil.com - contiene un código de script malicioso que busca explotar vulnerabilidades CSRF.

www.privatesite.com : este es su sitio externo, pero en lugar de bloquearlo con credenciales, lo configuró para que no tenga cookies y solo permita el acceso desde la IP estática de su enrutador doméstico.

mynas (192.168.1.1) : este es su servidor doméstico, solo accesible desde la red wifi de su hogar. Dado que usted es el único al que le permite conectarse a la red wifi de su hogar, este servidor no está protegido por credenciales y permite un acceso anónimo sin cookies.

Ambos www.privatesite.com y mynas generan tokens en campos de formulario ocultos para protección contra CSRF, pero dado que ha desactivado la autenticación, estos tokens no están vinculados a ninguna sesión de usuario.

Ahora, si visita accidentalmente www.evil.com este dominio podría estar realizando solicitudes a www.privatesite.com/turn_off_ip_lockdown pasando el token obtenido por la solicitud entre dominios, o incluso a mynas / format_drive usando el mismo método.

Es poco probable que lo sé, pero supongo que el estándar está escrito para ser lo más robusto posible y no tiene sentido eliminar Access- Control-Allow-Origin ya que agrega beneficios en escenarios como este.

Entonces, si puedo resumir: un cliente de navegador podría actuar como intermediario para ayudar a un servidor malicioso a llegar a algún recurso de destino "R", normalmente accesible solo para usted. Normalmente, consideramos el caso en el que "R" está protegido por un sistema de token de autenticación basado en cookies, pero usted presenta una situación en la que "R" está protegido por la topología de red. El navegador imaginado del OP (que siempre asume que `A-C-A-O: *`) violaría la protección basada en topología de red.
@apsillers Sí, eso resume muy bien mi respuesta.
También hay otros servicios que utilizan rangos de direcciones IP para restringir el acceso (como los editores académicos que controlan el acceso al contenido utilizando rangos de direcciones IP de universidades). Si se permitieran solicitudes anónimas entre dominios en todas partes, cualquier página web podría recuperar y leer ese contenido si el cliente se encuentra dentro del rango de direcciones IP permitidas.
Puede leer sobre [Clickjacking] (https://www.owasp.org/index.php/Clickjacking) para comprender una posibilidad diferente de explotación. :)
o.v.
2013-11-19 03:50:23 UTC
view on stackexchange narkive permalink

Lo que inicialmente me molestó con las políticas de CORS fue su aplicación indiscriminada independientemente del recurso / tipo, creo que ese sentimiento resuena bastante bien con su pregunta. La especificación W3 en realidad advierte que:

Un recurso de acceso público, sin controles de control de acceso, siempre puede devolver de forma segura un encabezado Access-Control-Allow-Origin cuyo el valor es "*"

Entonces, si bien el escenario en la respuesta de @ SilverlightFox es posible, en mi humilde opinión era poco probable que se considerara al escribir la especificación. En cambio, W3 parece estar impulsado por una mentalidad de "todo lo que no está permitido explícitamente debe restringirse" en este caso, lo que resulta contraproducente cuando los encabezados correctos no están configurados o los navegadores individuales carecen de soporte:

  • Aplicaciones enriquecidas del lado del cliente que utilizan API RESTful de terceros donde la autenticación, si existe, se envía con cada solicitud para que no haya "sesión" para secuestrar (eso es sin estado para usted !). Aún así, las respuestas .json están sujetas a CORS, por lo que ahora debe convencer al tercero de que implemente jsonp o un encabezado Access-Control-Allow-Origin adecuado, o renunciar y configurar un túnel hasta su punto final (adivina cuál usaré).

  • Las fuentes web están sujetas a CORS, aunque afaik solo Firefox implementó este borrador de especificaciones. Esto significa que si está utilizando una CDN para las fuentes (o un subdominio para todo el contenido estático), lo mejor es *-enabled !

  • Puntos de bonificación herp derp para CDN que no responden con un encabezado * sino que repiten el valor del encabezado Origin de la solicitud en su lugar: si se almacena en caché un proxy con un ...- Allow-Origin: domainA , sus usuarios de otros dominios no podrán acceder a él sin cachebusting (que es una especie de revés en términos de beneficios de rendimiento de CDN).

  • También hay algunos escenarios marginales como usar imágenes / videos externos con lienzo .

Estos inconvenientes al acceder a * -recursos adecuados podrían simplemente considerarse aceptables ya que al menos CORS está en juego por defecto cuando más importa .

2c: la mayoría de las personas (especialmente al principio) escriben sitios asumiendo que un usuario de un navegador está utilizando el servicio.No han considerado el caso de que el sitio malicioso de terceros evil.com esté probando su API.Devolver un * sorta significa que ha considerado esto.Aunque no si solo configura su servidor para que responda con un *, y su sitio en particular puede no haber considerado esto ... Sigo pensando que la especificación es engorrosa y parece demasiado centrada en el servidor.
Esta es la respuesta correcta.Si tengo una aplicación nativa, puedo realizar las solicitudes sin cookies entre sitios que desee, pero en el navegador, eso no está permitido.:(


Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...