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

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.

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.

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.

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.

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 .

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.

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.