95 votos

CORS - ¿cuál es la motivación detrás de presentar solicitudes de comprobación?

Cross-origin resource sharing es un mecanismo que permite a una página web para hacer XMLHttpRequests a otro dominio (de la wikipedia), y es bastante importante (de mí :).

He estado jugueteando con el CORS para el último par de días y creo que tengo una buena comprensión de cómo funciona todo.

Así que mi pregunta no es acerca de cómo CORS / comprobaciones de trabajo, se trata de la razón detrás de venir para arriba con preflights como un nuevo tipo de solicitud. No veo ninguna razón por la que Un servidor tiene que enviar un comprobaciones (PR) para el servidor B sólo para averiguar si la petición de verdad (RR) será aceptada o no - sin duda, sería posible para B para aceptar/rechazar RR sin previo PR.

Después de buscar un poco he encontrado esta pieza de información en www.w3.org (7.1.5):

Para proteger los recursos contra las solicitudes de origen cruzado que no pudo originarse a partir de ciertos agentes de usuario antes de esta especificación existía una solicitud de comprobaciones para asegurar que el recurso es consciente de esta especificación.

Creo que esta es la más difícil de comprender frase alguna vez. Mi interpretación (mejor debería llamar 'adivinar') es que se trata de proteger el servidor B en contra de las peticiones de servidor de C que no es consciente de la especificación.

Por favor alguien puede explicar un escenario / mostrar un problema que PR + RR resuelve mejor que RR solo?

98voto

Michael Iles Puntos 636

Pasé algún tiempo de estar confundido en cuanto a la finalidad de la comprobación previa petición, pero creo que la tengo ahora.

La idea clave es que las comprobaciones de las solicitudes no son de seguridad de la cosa. Más bien, son un no-cambiar-el-reglamento de la cosa.

Comprobaciones de las solicitudes no tienen nada que ver con la seguridad, y que no tienen ninguna incidencia en las aplicaciones que se están desarrollando ahora, con una conciencia de CORS. Más bien, el mecanismo de comprobaciones beneficios de los servidores que se han desarrollado sin una conciencia de CORS, y funciona como una comprobación de validez entre el cliente y el servidor en el que ambos son CORS-consciente. Los desarrolladores de CORS sentía que no fueron suficientes los servidores que fueron basarse en la suposición de que nunca iba a recibir, por ejemplo, una cruz de dominio de la solicitud de eliminación que se inventaron las comprobaciones mecanismo para permitir a ambos lados de opt-in. Ellos sentían que la alternativa, que habría sido simplemente habilitar las llamadas entre dominios, habría roto demasiadas aplicaciones existentes.

Hay tres escenarios aquí:

  1. Servidores antiguos, ya no está en desarrollo y desarrollados antes de CORS. Estos servidores pueden hacer suposiciones que nunca voy a recibir, por ejemplo, una cruz de dominio de la solicitud de eliminación. Este escenario es el principal beneficiario de las comprobaciones mecanismo. Sí estos servicios ya podría ser objeto de abuso por parte de un malicioso o no conforme con el agente de usuario (y CORS no hace nada para cambiar esto), pero en un mundo con CORS comprobaciones mecanismo proporciona un extra de 'comprobar' para que los clientes y los servidores no se rompen porque las reglas subyacentes de la web han cambiado.

  2. Los servidores que están todavía en desarrollo, pero que contienen una gran cantidad de código viejo y para los que no es posible/deseable de auditoría de todo el antiguo código para asegurarse de que funciona correctamente en una cruz de dominio mundial. Este escenario permite a los servidores progresivamente opt-in para CORS, por ejemplo, diciendo "Ahora voy a permitir que este particular encabezado de", "Ahora voy a permitir que este particular HTTP verbo", "Ahora voy a permitir cookies/auth envío de información", etc. Este escenario se beneficia de las comprobaciones mecanismo.

  3. Los nuevos servidores que se escriben con una conciencia de CORS. De acuerdo a la norma prácticas de seguridad, el servidor tiene que proteger sus recursos en la cara de cualquier solicitud entrante -- los servidores no pueden confiar en que los clientes no hacer cosas maliciosas. Este escenario no se benefician de las comprobaciones mecanismo: el mecanismo de comprobaciones no trae adicional de seguridad a un servidor que se ha protegido adecuadamente sus recursos.

14voto

monsur Puntos 8340

Considerar el mundo de cross-domain solicitudes antes de CORS. Usted podría hacer un formulario estándar de CORREOS, o el uso de un script o image etiqueta para emitir una solicitud GET. No se podía hacer cualquier otro tipo de solicitud de distinto GET/POST, y no podía emitir ningún encabezados personalizados en estas solicitudes.

Con el advenimiento de CORS, la especificación de los autores se enfrentan con el reto de la introducción de un nuevo cross-domain mecanismo sin romper la existente semántica de la web. Se decidió hacer esta dando a los servidores de un opt-in a cualquier tipo de solicitud. Este opt-in es la comprobación previa solicitud.

Así que GET/POST solicitudes sin ningún encabezados personalizados no necesita una comprobación previa, ya que estas solicitudes ya eran posibles antes de CORS. Pero cualquier solicitud con los encabezados personalizados, o PUT/DELETE peticiones, ¿ necesita una comprobación previa, ya que estos son nuevos en el CORS spec. Si el servidor no sabe nada acerca de CORS, es la respuesta sin ningún tipo de CORS-encabezados específicos, y la solicitud no se hizo.

Sin la comprobación previa solicitud, servidores podrían comenzar a ver inesperado peticiones de los navegadores. Esto podría llevar a un problema de seguridad si los servidores no estaban preparados para estos tipos de solicitudes. El CORS de comprobaciones permite cruz-dominio de las solicitudes para ser introducido en la web de forma segura.

8voto

porneL Puntos 42805

CORS le permite especificar más los encabezados y los tipos de métodos que antes era posible con origen cruzado <img src> o <form action>.

Algunos servidores que podría haber sido (mal) protegido con la suposición de que un navegador no puede hacer, por ejemplo, de origen cruzado DELETE petición o solicitud de origen cruzado con X-Requested-With de encabezado, de modo que tales peticiones son "de confianza".

Para asegurarse de que el servidor realmente-realmente apoya CORS y no sólo pasa a responder a las peticiones aleatorias, las comprobaciones se ejecuta.

2voto

Oliver Weichhold Puntos 4600

Además, para métodos de solicitud HTTP que pueden causar efectos secundarios en los datos de usuario (en particular, para los métodos HTTP que no sean GET o POST uso con ciertos tipos MIME), la especificación de los mandatos que los navegadores "comprobaciones" la solicitud

Fuente

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X