¿Existen diferencias sustanciales en la forma en que los navegadores implementan la misma política de origen?

Question

Tengo un formulario en mi página de inicio que está configurado para enviarlo a través de XHR POST a la URL https://mydomain.com/send_sms.

Cuando visito la versión no SSL de la página de inicio en Internet Explorer (http://mydomain.com) & envíe el formulario, no pasa nada. En la consola Webkit, recibo un error que indica útiles Origin http://mydomain.com is not allowed by Access-Control-Allow-Origin.

En Firefox 13 Sin embargo, la petición alega claramente & unas declaraciones de un 200 OK, aunque el cuerpo de la respuesta está en blanco. Además, la acción del lado del servidor (enviar un SMS) de hecho es activada por la solicitud de Firefox pero no por los otros navegadores.

Siempre pensé que la misma política de origen denegaba incluso el envío de la solicitud, pero tal vez es el navegador que recibe los datos de la respuesta que no se permite?

¿Alguien sabe si esta es una diferencia deliberada en la implementación (o posiblemente incluso un descuido) de Mozilla?

Answer 1

En primer lugar, http://example.com y https://example.com son de diferentes orígenes. Para XHR Level 1, esto significa que no se permiten solicitudes de origen cruzado.

Pero para la corriente XHR (Level 2), que apoya las solicitudes de origen cruzado cuando se apoya CORS (por el servidor y el cliente!), Una solicitud de origen cruzado puede ser o bien

• un simple cross-orgin request, si

  • el método de solicitud es GET, HEAD, o POST, y
  • ninguno de la solicitud heade campos R es uno que no sea Accept, Accept-Language, Content-Language, o Content-Type, y
  • la bandera de verificación previa no se establece

  o

• un cross-origin request that requires a preflight, de lo contrario.

Para solicitudes simples de origen cruzado, el navegador puede enviar la solicitud. Pero cuando se recibe la respuesta, necesita check whether the server allows to share the resource. Aquí es donde se marcan el campo de encabezado Access-Control-Allow-Origin y otros campos de encabezado de respuesta Access-Control-*. Y solo si se pasa esta comprobación, el navegador permite que el script lea la respuesta.

Para otras solicitudes de origen cruzado, se requiere una verificación previa para negociar con el servidor qué información se permite enviar en la solicitud real. Esta solicitud de verificación previa es básicamente una solicitud OPTIONS que le dice al servidor qué contendrá la solicitud real (método de solicitud y campos de encabezado). Entonces el servidor puede decidir si permite tal solicitud o no.

En su caso, el comportamiento observado puede tener varias razones. Supongo que su script send_sms simplemente no hace support the server side part for CORS.

Answer 2

El envío de datos debe prohibirse tanto como recibir, p. ¿Y si hubiera algún JS malicioso en esta página y estuviera enviando cada tecla a un servidor aleatorio? En este caso, el envío es más nefasto que la recepción (como un lado, esto puede lograrse al solicitar recursos como imágenes o scripts, con una cadena de consulta, ya que no están sujetos a la misma política de origen).

He encontrado ligeras diferencias en el pasado, pero eso ha sido generalmente con IE heredado.

Para mí, la discrepancia de Firefox es un error (siempre que una instalación de vanilla tenga este rasgo). Un protocolo diferente (HTTP vs HTTPS) es equivalente a un origen diferente, incluso los subdominios en el mismo protocolo se consideran de origen diferente, por lo que FF13 definitivamente no debería realizar la solicitud AJAX.

¿No tiene configurado CORS (Intercambio de recursos de origen cruzado) y FF13 es el único navegador que ha probado para admitirlo?