ajax - headers - enable cors chrome

¿Cuándo es seguro activar CORS?

Question

Estoy desarrollando una API web JSON / REST, para la cual deseo específicamente que los sitios web de terceros puedan llamar a mi servicio a través de AJAX. Por lo tanto, mi servicio está enviando el famoso encabezado CORS:

Access-Control-Allow-Origin: *

Que permite a los sitios de terceros llamar a mi servicio a través de AJAX. Todo bien hasta ahora.

Sin embargo, una subsección de mi API web no es pública y requiere autenticación (material bastante estándar con OAuth y una cookie access_token). ¿Es seguro habilitar CORS en esta parte de mi sitio también?

Por un lado, sería genial si los sitios web de terceros pudieran tener clientes jajax que también interactúen con esta parte de mi servicio. Sin embargo, la razón de que haya una misma política de origen en primer lugar es que esto podría ser riesgoso. No desea que ningún sitio web que visite después pueda acceder a su contenido privado.

El escenario que temo es que un usuario inicie sesión en mi API web, ya sea en el sitio web o a través de un sitio web en el que confía, y olvida cerrar la sesión. ¿Permitirá esto que cada otro sitio web que visita después tenga acceso a su contenido privado utilizando la sesión existente?

Entonces mis preguntas:

• ¿Es seguro habilitar CORS en contenido no público?
• Si un servidor CORS habilitado establece un session_token a través de una cookie, ¿se guardará esta cookie bajo el dominio del servidor CORS o del servidor principal de la página web?

Answer 1

En respuesta a su segunda pregunta (si un servidor CORS habilitado establece una session_token a través de una cookie ...?), La cookie se guarda bajo el dominio del servidor CORS. El código JS de la página web principal no puede acceder a la cookie, ni siquiera a través de document.cookie . La cookie solo se envía al servidor cuando se establece la propiedad .withCredentials , e incluso entonces, solo se acepta cuando el servidor establece el encabezado Access-Control-Allow-Credentials .

Tu primera pregunta es un poco más abierta. Es bastante seguro, pero hay formas de eludir las cosas. Por ejemplo, un atacante podría usar una técnica de envenenamiento de DNS para hacer que una solicitud de verificación previa llegue al servidor real, pero envíe la solicitud CORS real al servidor no autorizado. Aquí hay algunos recursos más sobre la seguridad CORS:

• http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
• owasp.org CORS CheatSheet

Por último, su preocupación es darle acceso a cualquier sitio web a sus datos CORS. Para protegerse de esto, no debe usar el encabezado Access-Control-Allow-Origin: * . En su lugar, debe repetir el valor de origen del usuario. Por ejemplo:

Access-Control-Allow-Origin: http://www.example.com

Este encabezado solo permitirá que http://www.example.com tenga acceso a los datos de respuesta.

Answer 2

La intención de CORS es permitir solicitudes de origen cruzado para solicitudes de XHR a la vez que otorga al servidor la autoridad para especificar qué origen tiene acceso a cada recurso. En particular, CORS introdujo el campo de encabezado Origen que permite al servidor distinguir entre las solicitudes regulares y posibles de XHR. El usuario no puede establecer o cambiar este campo de encabezado, pero el navegador lo configura para solicitudes XHR.

Por lo tanto, si tiene una API diseñada para ser utilizada solo por XHR, puede (y debe) exigir que la solicitud cumpla con CORS. Especialmente si las solicitudes también pueden modificar el estado en su servidor, ya que de lo contrario sería vulnerable a CSRF.

Tenga en cuenta que los ataques CSRF son posibles independientemente de CORS utilizando otros métodos para forjar solicitudes GET y POST. CORS solo permite acceder a la respuesta del servidor de solicitudes XHR con JavaScript si el servidor lo permite.