¿Es CORS una forma segura de realizar solicitudes AJAX entre dominios?

81

Después de leer sobre CORS (Intercambio de recursos de origen cruzado), no entiendo cómo mejora la seguridad. Se permite la comunicación AJAX entre dominios si se envía el encabezado ORIGIN correcto. Como ejemplo, si envío

ORIGEN: http://example.com

El servidor comprueba si este dominio está en la lista blanca y, si lo está, encabezado:

Access-Control-Allow-Origin: [URL recibida aquí]

se envía de vuelta, junto con la respuesta (este es el caso simple, también hay solicitudes prefijadas, pero la pregunta es la misma).

¿Es esto realmente seguro? Si alguien quiere recibir la información, falsificar los encabezados de ORIGIN parece una tarea realmente trivial. Además, el estándar dice que la política se aplica en el navegador, bloqueando la respuesta si Access-Control-Allow-Origin no es correcto. Obviamente, si alguien está tratando de obtener esa información, no usará un navegador estándar para bloquearla.

Gibarian2001
fuente
Lea esta respuesta si alguien no tiene claro qué política del mismo origen y CORS son y por qué existen: stackoverflow.com/a/27294846/3340994
nishantbhardwaj2002

Respuestas:

52

No puede falsificar un encabezado de Origin con JavaScript en un navegador web. CORS está diseñado para evitar eso.

Fuera de un navegador web, no importa. No está diseñado para evitar que las personas obtengan datos que están disponibles para el público. No puede exponerlo al público sin que el público lo entienda.

Está diseñado para que dado:

  • Alice, una persona que proporciona una API diseñada para acceder a través de Ajax
  • Bob, una persona con un navegador web
  • Charlie, un tercero que administra su propio sitio web

Si Bob visita el sitio web de Charlie, entonces Charlie no puede enviar JS al navegador de Bob para que obtenga datos del sitio web de Alice y se los envíe a Charlie.

La situación anterior se vuelve más importante si Bob tiene una cuenta de usuario en el sitio web de Alice que le permite hacer cosas como publicar comentarios, eliminar datos o ver datos que no están disponibles para el público en general, ya que sin protección, el JS de Charlie podría decirle al navegador de Bob para hacer eso a espaldas de Bob (y luego enviar los resultados a Charlie).

Si desea evitar que personas no autorizadas vean los datos, entonces debe protegerlos con contraseñas, certificados de cliente SSL o algún otro medio de autenticación / autorización basada en identidad.

Quentin
fuente
1
Básicamente, CORS o el intercambio de recursos entre orígenes y la autorización son dos cosas separadas. Como sugiere el acrónimo, en realidad PERMITIR el intercambio de origen cruzado. Si un cliente está REALMENTE autorizado para hacer esto, lo determinará su lógica de autorización.
reaper_unique
149

El propósito es prevenir esto:

  • Vas al sitio web X
  • El autor del sitio web X ha escrito un script malvado que se envía a su navegador.
  • ese script que se ejecuta en su navegador inicia sesión en el sitio web de su banco y hace cosas malvadas y, debido a que se ejecuta como usted en su navegador, tiene permiso para hacerlo.

La idea es que el sitio web de su banco necesita alguna forma de decirle a su navegador si se debe confiar en los scripts del sitio web X para acceder a las páginas de su banco.

jcoder
fuente
9
Tu respuesta también fue muy clara, gracias. No podría votar porque requiere 15 reputación.
Gibarian2001
Entonces, CORS no está protegiendo la integridad de la aplicación en el sitio web X, ¿está protegiendo la integridad del BANCO que dice que se debe confiar en web X para realizar las llamadas API al BANCO?
luigi7up
7
@ luigi7up: No, CORS no protege nada, de hecho, "debilita" la seguridad al definir excepciones a SOP. El Access-Control-Allow-Originencabezado especifica qué orígenes (especificados en el Originencabezado) pueden acceder al recurso. Normalmente, solo las solicitudes con el mismo origen podrían hacerlo. La parte más importante aquí es: permitir / denegar es impuesto por el NAVEGADOR, no por el servidor. Esto significa que Access-Control-Allow-Originprotege su navegador, no el recurso en el servidor o el servidor en sí.
daniel f.
¿Qué impide al autor del sitio web X iniciar sesión en el banco a través del backend de su sitio, que luego se usaría como proxy? Es solo una capa adicional que tendría que crear, pero supongo que evitaría por completo el problema de CORS que tendría en el navegador. Así que esto parece una protección solo para el navegador que me parece bastante insignificante si puedes evitarlo. de una manera muy simple ..
pootzko
1
@pootzko: en su escenario, el sitio web malicioso X no tendría una sesión válida para el sitio web bancario. Incluso si la víctima ha iniciado sesión en su banco (por ejemplo, en otra pestaña), el sitio malicioso X no tendría acceso a esa sesión, debido a la política de cookies impuesta por el navegador: el navegador nunca enviaría la cookie de sesión del banco al sitio web X.
daniel f.
64

Solo para agregar la respuesta de @jcoder, el objetivo del Originencabezado no es proteger los recursos solicitados en un servidor. Esa tarea depende del servidor mismo a través de otros medios, exactamente porque un atacante puede falsificar este encabezado con las herramientas adecuadas.

El objetivo del Originencabezado es proteger al usuario. El escenario es el siguiente:

  • un atacante crea un sitio web malicioso M

  • un usuario Alice es engañado para conectarse a M, que contiene un script que intenta realizar algunas acciones a través de CORS en un servidor B que realmente es compatible con CORS

  • B probablemente no tendrá M en su Access-Control-Allow-Originencabezado, porque ¿por qué?

  • El punto fundamental es que M no tiene medios para falsificar o sobrescribir el Originencabezado, porque las solicitudes son iniciadas por el navegador de Alice. Entonces su navegador establecerá el (correcto) Originen M, que no está en el Access-Control-Allow-Originde B, por lo tanto, la solicitud fallará.

Alice podría alterar el Originencabezado ella misma, pero ¿por qué lo haría, ya que significaría que se está haciendo daño a sí misma?

TL; DR: El Originencabezado protege al usuario inocente. No protege los recursos en un servidor. Un atacante puede falsificarlo en su propia máquina, pero no puede falsificarlo en una máquina que no esté bajo su control.

Los servidores aún deben proteger sus recursos, ya que un Originencabezado coincidente no significa un acceso autorizado. Sin embargo, un Originencabezado que NO coincide significa un acceso no autorizado.

daniel f.
fuente
11
Muy buena respuesta. El mejor en general en mi humilde opinión.
petersaints
¿Por qué esta no fue la respuesta elegida? Este es claramente el mejor. El cuarto punto mencionado en esta respuesta es lo que realmente pide el cartel.
alaboudi
mejor respuesta Daniel. Este es el punto central de CORS: "El punto fundamental es que M no tiene medios para falsificar o sobrescribir el encabezado Origin, porque las solicitudes son iniciadas por el navegador de ALICE. Por lo tanto, su navegador establecerá el origen (correcto) en M, que no está en Access-Control-Allow-Origin de B, por lo tanto, la solicitud fallará ".
Lukas Lukac
14

El propósito de la misma política de origen no es evitar que las personas accedan al contenido del sitio web en general; si alguien quiere hacer eso, ni siquiera necesita un navegador. El punto es evitar que los scripts de cliente accedan al contenido de otro dominio sin los derechos de acceso necesarios. Consulte la entrada de Wikipedia para la política del mismo origen .

Andy E
fuente
2
"El punto es evitar que los scripts del cliente accedan al contenido de otro dominio", esto se resolvió con la Política de Mismo Origen. ¿No? Quiero decir que mi sitio web le envía algo de JS y su navegador no permitirá llamadas ajax a algún otro dominio. esa es la misma política de origen. CORS está haciendo todo lo contrario: permite que mi ajax acceda al otro dominio. Me falta algo enorme aquí :)
luigi7up
a @ luigi7up: Sí, CORS hace lo contrario. Permite al propietario de un sitio web otorgar acceso a sus servicios desde más de un dominio confiable.
SergeyT
6

Después de leer sobre CORS, no entiendo cómo mejora la seguridad.

CORS no mejora la seguridad. CORS proporciona un mecanismo para que los servidores le digan a los navegadores cómo deben acceder los dominios extranjeros, e intenta hacerlo de una manera que sea consistente con el modelo de seguridad del navegador que existía antes de CORS (es decir, la Política del Mismo Origen ).

Pero la Política de Mismo Origen y CORS tienen un alcance limitado. Específicamente, la especificación CORS en sí no tiene ningún mecanismo para rechazar solicitudes. Puede usar encabezados para decirle al navegador que no permita que una página de un dominio externo lea una respuesta. Y, en el caso de las solicitudes de verificación previa, puede pedirle al navegador que no le envíe ciertas solicitudes de un dominio extranjero. Pero CORS no especifica ningún medio para que el servidor rechace (es decir, no ejecute) una solicitud real.

Pongamos un ejemplo. Un usuario inicia sesión en el sitio a Através de una cookie. El usuario carga un sitio malicioso M, que intenta enviar un formulario que hace un POSTa A. ¿Lo que sucederá? Bueno, con o sin CORS, y con o sin Mser un dominio permitido, el navegador enviará la solicitud a Acon la cookie de autorización del usuario, y el servidor ejecutará el malicioso POSTcomo si el usuario lo hubiera iniciado.

Este ataque se denomina Falsificación de solicitudes entre sitios y CORS no hace nada para mitigarlo. Es por eso que las protecciones CSRF son tan importantes si permite solicitudes para cambiar datos en nombre de los usuarios.

Ahora, el uso del Originencabezado puede ser una parte importante de su protección CSRF. De hecho, verificarlo es parte de la recomendación actual para la defensa CSRF de múltiples frentes . Pero ese uso del Originencabezado queda fuera de la especificación CORS.

En resumen, CORS es una especificación útil para extender el modelo de seguridad de la Política del Mismo Origen existente a otros dominios aceptados. No agrega seguridad y los sitios necesitan los mismos tipos de mecanismos de defensa que tenían antes de CORS.

Kevin Christopher Henry
fuente
1

Llego tarde para responder, pero no creo que ninguna publicación aquí proporcione realmente la respuesta buscada. La conclusión más importante debería ser que el navegador es el agente que escribe el originvalor del encabezado. Un guión malvado no puede escribir el originvalor del encabezado. Cuando el servidor responde con un Access-Control-Allow-Originencabezado, el navegador intenta asegurarse de que este encabezado contenga el originvalor enviado anteriormente. De lo contrario, desencadena un error y no devuelve el valor al script que lo solicita. Las otras respuestas a esta pregunta presentan un buen escenario para cuando le gustaría negar una respuesta al guión malvado.

@daniel f también proporciona una buena respuesta a la pregunta.

alaboudi
fuente