javascript - origin - peticiones cross domain ajax
¿CORS es una forma segura de hacer solicitudes AJAX entre dominios? (6)
Después de leer sobre CORS (Intercambio de recursos de origen cruzado), no entiendo cómo mejora la seguridad. La comunicación AJAX entre dominios está permitida si se envía el encabezado ORIGIN correcto. Como un ejemplo, si envío
ORIGEN: http://example.com
El servidor verifica si este dominio está en la lista blanca y, si lo es, en el 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 pre-evaluadas, pero la pregunta es la misma).
¿Esto es realmente seguro? Si alguien quiere recibir la información, falsificar un encabezado 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 Access-Control-Allow-Origin no es correcta. Obviamente, si alguien intenta obtener esa información, no usará un navegador estándar para bloquearla.
El objetivo de la misma política de origen no es impedir que las personas accedan al contenido del sitio web en general; si alguien quiere hacer eso, ni siquiera necesitan un navegador. El objetivo es evitar que los scripts de los clientes accedan al contenido de otro dominio sin los derechos de acceso necesarios. Vea la entrada de Wikipedia para la Política de Mismo Origen .
El propósito es prevenir esto -
- Usted va 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 porque se ejecuta como usted en su navegador, tiene permiso para hacerlo.
La idea es que el sitio web de su banco necesita una forma de decirle a su navegador si las secuencias de comandos en el sitio web X deben ser de confianza para acceder a las páginas de su banco.
Llego tarde para responder, pero no creo que ninguna publicación aquí proporcione realmente la respuesta buscada. Lo más importante es que el navegador es el agente que está escribiendo el valor del encabezado de origin . Una secuencia de comandos malvada no puede escribir el valor del encabezado de origin . Cuando el servidor responde con un encabezado Access-Control-Allow-Origin , el navegador intenta asegurarse de que este encabezado contenga el valor de origin enviado anteriormente. De lo contrario, desencadena un error y no devuelve el valor al script solicitante. Las otras respuestas a esta pregunta presentan un buen escenario para cuando quisieras negarle una respuesta al mal guión.
@daniel f también proporciona una buena respuesta a la pregunta
No está diseñado para evitar que las personas obtengan los datos. No puedes exponerlo sin que la gente lo obtenga.
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 con 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 o eliminar datos, ya que sin protección, Charlie podría decirle al navegador de Bob que haga eso detrás de la espalda de Bob.
Si desea impedir que personas no autorizadas vean los datos, debe proteger con contraseñas, certificaciones de clientes SSL u otros medios de autenticación / autorización basados en la identidad.
Solo para agregar la respuesta de @jcoder, todo el punto del encabezado Origin , no es para proteger los recursos solicitados en un servidor, esa tarea depende del servidor, exactamente porque un atacante es capaz de falsificar este encabezado con las herramientas apropiadas.
El punto del encabezado Origin es proteger al usuario. El escenario es el siguiente:
un atacante Marie 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 en realidad admite CORS
B probablemente no tendrá M en su encabezado
Access-Control-Allow-Origin, porque ¿por qué?El punto fundamental es que M no tiene medios para suplantar o sobreescribir el encabezado de
Origin, porque las solicitudes son iniciadas por el navegador de ALICE. Por lo tanto, su navegador configurará el origen (correcto) en M, que no está enAccess-Control-Allow-Originde B, por lo tanto, la solicitud fallará.
Ahora, Alice podría alterar el encabezado de Origin ella misma, pero ¿por qué iba a hacerlo, ya que significaría que se está perjudicando a sí misma?
TL; DR: el encabezado Origin protege al usuario inocente. No asegura recursos. Es atacable por un atacante en su propia máquina, pero no puede ser falsificado en una máquina que no está bajo su control.
Los servidores aún deben proteger sus recursos, ya que el encabezado correspondiente de Origin no significa un acceso autorizado. Sin embargo, un encabezado de Origin que NO coincide, significa un acceso no autorizado.
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 digan a los navegadores cómo deben ser accedidos por dominios externos, y trata de hacerlo de una manera consistente con el modelo de seguridad del navegador que existía antes de CORS (es decir, la Política de Mismo Origen ).
Pero la misma política de origen y CORS tienen un alcance limitado. Específicamente, la especificación CORS en sí misma no tiene mecanismo para rechazar solicitudes. Puede usar encabezados para decirle al navegador que no permita que una página de un dominio extranjero lea una respuesta. Y, en el caso de solicitudes prevuelo, puede solicitar al navegador que no 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 está conectado al sitio A través de una cookie. El usuario carga el sitio malicioso M , que intenta enviar un formulario que hace una POST a A ¿Lo que sucederá? Bien, con o sin CORS, y con o sin M como un dominio permitido, el navegador enviará la solicitud a A con la cookie de autorización del usuario, y el servidor ejecutará la POST maliciosa como si el usuario la iniciara.
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 que las solicitudes cambien datos en nombre de los usuarios.
Ahora, el uso del encabezado Origin puede ser una parte importante de su protección CSRF. De hecho, verificarlo es parte de la recomendación actual para la defensa de múltiples frentes CSRF . Pero ese uso del encabezado Origin queda fuera de la especificación CORS.
En resumen, CORS es una especificación útil para extender el modelo de seguridad existente de la Política de Same Origin a otros dominios aceptados. No agrega seguridad, y los sitios necesitan los mismos tipos de mecanismos de defensa que antes de CORS.