¿Por qué las API del navegador restringen las solicitudes entre dominios?

Question

XMLHttpRequest s requieren CORS para trabajar entre dominios. De forma similar para fuentes web, texturas WebGL y algunas otras cosas. En general, todas las nuevas API parecen tener esta restricción.

¿Por qué?

Es tan fácil de eludir: todo lo que se necesita es un simple proxy del lado del servidor. En otras palabras, el código del lado del servidor no tiene prohibido hacer solicitudes entre dominios; ¿Por qué es el código del lado del cliente? ¿Cómo le da esto seguridad a alguien?

Y es tan inconsistente: No puedo XMLHttpRequest, pero no puedo <script src> o <link rel> o <img src> o . ¿Qué significa restringir XHR, etc. incluso lograr?

Answer 1

Si vuelvo a visitar un sitio web malicioso, quiero estar seguro de que:

1. No puede leer mis datos personales de otros sitios web que uso. Think Attacker.com leyendo gmail.com
2. No puede realizar acciones en mi nombre en otros sitios web que utilizo. Piensa en attacker.com transfiriendo fondos desde mi cuenta en bank.com

La política Same Origin resuelve el primer problema. El segundo problema se llama falsificación de solicitudes entre sitios, y no se puede resolver con las restricciones de dominio cruzado actualmente vigentes.

La política del mismo origen es, en general, en consonancia con las siguientes reglas -

• Regla 1: No deje de leer cualquier cosa, desde un dominio diferente
• Regla 2: Permite escribir lo que quieras un dominio diferente, pero la regla n. ° 1 no le permitirá leer la respuesta.
• Regla 3: Usted puede hacer libremente peticiones GET entre dominios y las peticiones POST, pero no se puede controlar las cabeceras HTTP

vamos a ver cómo las diferentes cosas que usted ha enumerado los conductos hasta que las reglas anteriores:

1. <img> etiquetas le permiten hacer una solicitud de HTTP, pero no hay forma de leer el contenido de la imagen más que simplemente mostrarla. Por ejemplo, si hago esto <img src="http://bank.com/get/latest/funds"/>, la solicitud se procesará (regla 2). Pero no hay forma de que el atacante vea mi saldo (regla 1).

2. <script> etiquetas funcionan principalmente como <img>. Si haces algo como <script src="http://bank.com/get/latest/funds">, la solicitud se procesará. El navegador también intentará analizar la respuesta como JavaScript y fallará.

3. Existe un conocido abuso de las etiquetas <script> llamadas JSONP, donde se pone en colusión con el servidor de dominios cruzados para que pueda 'leer' entre dominios. Pero sin la participación explícita del servidor de dominios cruzados, no se puede leer la respuesta a través de la etiqueta <script>

4. <link> de hojas de estilo en su mayoría trabajan como <script> etiquetas, salvo la respuesta se evalúa como CSS. En general, no puede leer la respuesta, a menos que la respuesta de alguna manera sea CSS bien formada.

5. es esencialmente una nueva ventana del navegador. No puede leer el HTML de un iframe entre dominios. Por cierto, puede cambiar la URL de un iframe entre dominios, pero no puede leer la URL. Observe cómo sigue las dos reglas que mencioné anteriormente.

6. XMLHttpRequest es el método más versátil para realizar solicitudes HTTP. Esto está completamente en el control de los desarrolladores; el navegador no hace nada con la respuesta. Por ejemplo, en el caso de <img>, <script> o <link>, el navegador asume un formato particular y en general lo validará adecuadamente. Pero en XHR, no hay un formato de respuesta prescrito. Por lo tanto, los navegadores aplican la misma política de origen e impiden que lea la respuesta a menos que el sitio web de dominio cruzado lo permita explícitamente.

7. Las fuentes a través de font-face son una anomalía. AFAIK, solo Firefox requiere el comportamiento opt-in; otros navegadores te permiten usar fuentes como si usaras imágenes.

En resumen, la misma política de origen es coherente. Si encuentra una forma de hacer una solicitud entre dominios y, lea la respuesta sin el permiso explícito del sitio web multidominio: usted será noticia en todo el mundo.

EDIT: ¿Por qué no puedo evitar todo esto con un proxy del lado del servidor?

Para que gmail muestre datos personalizados, necesita las cookies de su navegador. Algunos sitios usan autenticación básica HTTP, en la que las credenciales se almacenan en el navegador.

Un proxy del lado del servidor no puede obtener acceso a las cookies ni a las credenciales de autenticación básicas. Y así, aunque puede hacer una solicitud, el servidor no devolverá datos específicos del usuario.

Answer 2

consideran este escenario ...

1. vas a mi sitio web malicioso.
2. Mi sitio hace un XHR a su sitio web bancario y solicita el formulario para la transferencia bancaria.
3. El XHR lee el token que impide los formularios CSRF y POST junto con el token de seguridad y transfiere una suma de dinero a mi cuenta.
4. (I) Profit !!!

Sin la misma política de origen, aún podría enviar ese formulario, pero no podría solicitar el token CSRF que impide los CSRF.

El código del lado del servidor no se ejecuta en la computadora del cliente.

Answer 3

El principal problema con XHR es que no pueden simplemente enviar una solicitud, sino que también pueden leer la respuesta. El envío de solicitudes casi arbitrarias ya era posible. Pero leer sus respuestas no fue así. Es por eso que el XHR original no permitió ninguna solicitud de origen cruzado.

Más tarde, cuando surgió la demanda de solicitudes de origen cruzado con XHR, el CORS se estableció para permitir solicitudes de origen cruzado bajo condiciones específicas. Una condición es que los métodos de solicitud particulares, los campos de encabezado de solicitud y las solicitudes que contendrían credenciales de usuario requieren una llamada solicitud de verificación previa con la que el cliente puede verificar si el servidor permitiría la solicitud. Con esto, el servidor tiene la capacidad de restringir el acceso solo a orígenes específicos, ya que de lo contrario cualquier origen podría enviar solicitudes.