¿Es Cors una forma segura de hacer solicitudes de AJAX de dominio cruzado?

Question

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

ORIGEN: http://example.com

El servidor verifica si este dominio está en la lista blanca y, si es así, encabezado:

Access-Control-Allow-Origin: [recibió URL aquí

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

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

Answer 1

No puede fingir un encabezado de origen con JavaScript en un navegador web. Cors está diseñado para prevenir eso.

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

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 dirige 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 comentarios de publicaciones, eliminar datos o ver datos que son no Disponible para el público en general, ya que sin protección, JS de Charlie podría decirle al navegador de Bob que lo hiciera a espaldas de Bob (y luego enviar los resultados a Charlie).

Si desea evitar que las personas no autorizadas vean los datos, debe protegerlo con contraseñas, certificaciones de clientes SSL o algún otro medio de autenticación/autorización basada en la identidad.

Answer 2

El propósito es evitar esto -

• Vas al sitio web x
• El autor del sitio web X ha escrito un guión 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 porque se está ejecutando como tu En su navegador tiene permiso para hacerlo.

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

Answer 3

Solo para agregar la respuesta de @JCoder, el punto completo del Origin El encabezado no es para proteger los recursos solicitados en un servidor. Esa tarea depende del servidor en sí mismo a través de otros medios exactamente porque un atacante es capaz de falsificar este encabezado con las herramientas apropiadas.

El punto de la Origin El encabezado es para proteger al usuario. El escenario es el siguiente:

• Un atacante crea un sitio web malicioso m

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

• B probablemente no tendrá m en su Access-Control-Allow-Origin encabezado, porque ¿por qué lo haría?

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

Alice podría alterar el Origin Demandada misma, pero ¿por qué ella, ya que significaría que se está dañando a sí misma?

Tl; dr: el Origin El encabezado protege al usuario inocente. No asegura recursos en un servidor. Es suplantable por un atacante en su propia máquina, pero no puede ser falsificada en una máquina que no esté bajo su control.

Los servidores aún deben proteger sus recursos, como un coincidencia Origin El encabezado no significa un acceso autorizado. Sin embargo, un Origin El encabezado que no coincide significa un acceso no autorizado.

Answer 4

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 necesitan un navegador. El punto es parar Scripts de clientes Acceder al contenido en otro dominio sin los derechos de acceso necesarios. Ver la entrada de Wikipedia para Política de origen de la misma.

Answer 5

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 les digan a los navegadores cómo deben acceder a los dominios extranjeros, y trata de hacerlo de una manera que sea consistente con el modelo de seguridad del navegador que existía antes de Cors (a saber, el Política de origen de la misma).

Pero la misma política de origen y CORS tienen un alcance limitado. Específicamente, el Especificación CORS en sí mismo no tiene mecanismo para rechazar las solicitudes. Puede usar encabezados para decirle al navegador que no deje que una página de un dominio extranjero lea una respuesta. Y, en el caso de las solicitudes de prevergir, puede pedirle al navegador que no lo envíe ciertas solicitudes desde un dominio extranjero. Pero CORS no especifica ningún medio para que el servidor rechace (es decir, no ejecute) una solicitud real.

Tomemos un ejemplo. Un usuario inicia sesión en el sitio A a través de una galleta. El usuario carga el sitio malicioso M, que intenta enviar un formulario que realiza un POST a A. ¿Lo que sucederá? Bueno, con o sin Cors, y con o sin M Siendo un dominio permitido, el navegador enviará la solicitud a A con la cookie de autorización del usuario, y el servidor ejecutará el malicioso POST como si el usuario lo iniciara.

Este ataque se llama Falsificación de solicitud de sitio cruzado, y Cors no hace nada para mitigarlo. Es por eso que las protecciones de CSRF son tan importantes si permite que las solicitudes cambien los datos en nombre de los usuarios.

Ahora, el uso del Origin El encabezado puede ser una parte importante de su protección CSRF. De hecho, verificarlo es parte del Recomendación actual para la defensa CSRF multiproceso. Pero ese uso del Origin El encabezado cae fuera de la especificación CORS.

En resumen, CORS es una especificación útil para extender el modelo de seguridad de política de origen existente a otros dominios aceptados. No agrega seguridad, y los sitios necesitan los mismos tipos de mecanismos de defensa que hicieron antes de Cors.

Answer 6

Llego tarde a responder, pero no creo que ninguna publicación aquí realmente proporcione la respuesta solicitada. La conclusión más grande debería ser que el navegador es el agente que está escribiendo el origin Valor del encabezado. Un guión malvado no puede escribir el origin Valor del encabezado. Cuando el servidor responde con un Access-Control-Allow-Origin encabezado, el navegador intenta asegurarse de que este encabezado contenga el origin valor enviado anteriormente. Si no, desencadena un error y no devuelve el valor al script solicitante. Las otras respuestas a esta pregunta presentan un buen escenario para cuándo desea negar una respuesta al malvado guión.

@Daniel F también proporciona una buena respuesta a la pregunta