Estoy desarrollando un JSON/REST API de web, para que específicamente desea sitios web de terceros para poder llamar a mi servicio a través de AJAX. Por lo tanto, mi servicio es el envío de la famosa encabezado CORS:

Access-Control-Allow-Origin: *

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

Sin embargo, en una subsección de mi web api es no-pública y requiere autenticación (algo bastante estándar con OAuth y un access_token cookie). Es seguro para habilitar CORS en esta parte de mi sitio así?

Por un lado, sería genial si los sitios web de terceros podría haber ajax clientes que también interactúan con esta parte de mi servicio. Sin embargo, la razón de que hay un origen mismo de la política, en primer lugar, es que esto podría ser arriesgado. Usted no quiere que cualquier sitio web que usted visita, después, a ser capaz de acceder a su contenido privado.

El escenario que tengo miedo es que un usuario inicia la sesión en mi web api, ya sea en el sitio web o a través de un sitio web que confía en él, y él se olvida de cerrar la sesión. Será esto permite que todos los otros sitios web que él las vistas después de acceder a su contenido mediante la sesión existente?

Así que mis preguntas:

  • Es seguro para habilitar CORS en la no-pública de contenido?
  • Si un CORS habilitado el servidor establece una session_token a través de una cookie, se esta cookie se guarda bajo el dominio de los CORS servidor principal o en la página web del servidor?
  • Tenga en cuenta que sólo se podía enviar el CORS los encabezados de los recursos que desea que los demás para tener acceso desde otros orígenes. Y usted también podría limitar CORS el acceso sólo a los orígenes que espera que el uso de.
  • Idealy, me gustaría que todos los recursos para ser accesible desde cualquier origen, si la seguridad lo permite. Es que el usuario proporcione credenciales válidas. Sólo quiero para asegurarse de que yo no soy de abrir la puerta de cross-site scripting ataques de sitios web maliciosos.
InformationsquelleAutor Jeroen | 2012-03-15

2 Comentarios

  1. 43

    En respuesta a tu segunda pregunta (Si un CORS habilitado el servidor establece una session_token a través de una cookie…?), la cookie se guarda bajo el dominio de los CORS servidor. La principal página web de código JS no pueden acceder a la cookie, incluso a través de document.cookie. La cookie sólo se envía al servidor cuando el .withCredentials se establece la propiedad, e incluso entonces, sólo es aceptado cuando el servidor establece el Access-Control-Allow-Credentials encabezado.

    Su primera pregunta es un poco más abierta. Es bastante seguro, pero hay formas de evadir las cosas. Por ejemplo, un atacante podría utilizar un envenenamiento de DNS técnica para causar una comprobación previa solicitud a golpear el servidor real, pero enviar a la real CORS solicitud para el servidor rogue. Aquí están algunas de las más recursos en CORS de seguridad:

    Por último, su preocupación es sobre dar cualquier sitio web el acceso a su CORS de datos. Con el fin de protegerse contra esto, usted no debe usar la Access-Control-Allow-Origin: * encabezado. En su lugar, usted debe repetir el usuario del valor de Origen. Por ejemplo:

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

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

    • Puede usted aclarar cómo repetir el ‘origen’ de cabecera añade a la seguridad? Yo creo que cualquier sitio web malicioso/script se podría establecer fácilmente este encabezado así? O ¿te refieres a mantener algún tipo de lista blanca?
    • Sí, el mantenimiento de una lista blanca de aceptable orígenes es una solución. Otro es atar una sesión de usuario id a un origen en particular. De esa manera, si un origen diferente de alguna manera reproduce la solicitud con las credenciales del usuario, se producirá un error.
    • Creo que te refieres al decir que un atacante podría interceptar las comprobaciones, no de la solicitud. También se nota que Obtiene no son pre-sinfín.
    • Se presenta puede ser preflighted si contienen no simple encabezados de solicitud.
    • Es un error pensar que cualquier sitio web malicioso/script puede establecer el Origen de encabezado, como el encabezado es un «prohibido» encabezado, según el CORS especificaciones: fetch.spec.whatwg.org/#forbidden-header-name
  2. 23

    La intención de CORS es para permitir la procedencia de las solicitudes de peticiones XHR mientras que el servidor de la autoridad para especificar qué origen tiene acceso a qué recursos. En particular, CORS introdujo el Origen campo de encabezado que permite que el servidor de decirle a regular y las posibles peticiones XHR aparte. Este campo de encabezado no puede ser establecido o modificado por el usuario, sino que se establece por el navegador para peticiones XHR.

    Así que si usted tiene una API que está diseñado para ser utilizado solamente por XHR, usted puede (y debe) exigir que la solicitud cumpla con CORS. Especialmente si las solicitudes también pueden modificar el estado en el servidor ya que de lo contrario serían vulnerables a CSRF.

    Nota los ataques CSRF son posibles, independientemente de CORS uso de otros métodos para forjar GET y POST de las solicitudes. CORS, no sólo permiten el acceso de la respuesta del servidor de peticiones XHR con JavaScript, si el servidor lo permite.

Dejar respuesta

Please enter your comment!
Please enter your name here