¿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 que 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 me da miedo es que un usuario inicie sesión en mi API web, ya sea en el sitio web oa través de un sitio web en el que confía, y se olvida de 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?

Así que mis preguntas:

• ¿Alguna vez es segura para permitir CORS sobre el contenido no pública?
• Si un servidor CORS habilitado establece un session_token a través de una cookie, ¿se guardará esta cookie en 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 un 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 del 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.

Su 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í están algunos recursos más para la seguridad CORS:

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

Por último, su preocupación es por ahí dando cualquier acceso 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 

Esta cabecera sólo permitirá http://www.example.com acceder a los datos de respuesta.

Answer 2

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

Así que si tiene una API que está diseñada para ser utilizada solo por XHR, puede (y debe) requerir que la solicitud se ajuste a 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 falsificar solicitudes GET y POST. CORS solo permite acceder a la respuesta del servidor de solicitudes XHR con JavaScript si el servidor lo permite.