2012-05-30 17 views
8

Dada la simplicidad de escribir un proxy del lado del servidor que obtenga datos entre dominios, no entiendo cuál fue la intención inicial de evitar que el lado del cliente AJAX realice llamadas entre dominios. No estoy pidiendo especulaciones, estoy buscando documentación de los diseñadores de idiomas (o personas cercanas a ellos) por lo que pensaban que estaban haciendo, aparte de simplemente crear un leve inconveniente para los desarrolladores.¿Cuál es la lógica detrás de la seguridad entre dominios AJAX?

TIA

+1

http://msdn.microsoft.com/en-us/library/cc709423(v=vs.85).aspx – user1096188

+1

http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_XMLHttpRequest Todo el libro vale la pena leerlo. – jasssonpet

+0

@jasssonpet ¡Excelente enlace, marcado como favorito! –

Respuesta

6

Es para evitar que un navegador actúe como un proxy inverso. Supongamos que está navegando http://www.evil.com desde una PC en su oficina, y suponga que en esa oficina existe una intranet con información sensible en http://intranet.company.com a la que solo se puede acceder desde la red local. Si la política de dominio cruzado no existe, www.evil.com podría hacer solicitudes ajax al http://intranet.company.com, utilizando su navegador como proxy inverso, y enviar esa información a www.evil.com con otra solicitud de Ajax.

Esta es una de las razones de la restricción, supongo.

+0

Sí, es:) ... muy claro que mi respuesta, perdí el camino – fguillen

+0

que parece * extremadamente exagerado. ¡Su intranet debería tener respondedores AJAX que evil.com debería saber cómo llamar! Si esa es realmente la preocupación, entonces la intranet tampoco puede ejecutar ningún CGI, ¿verdad? –

+0

Como dijo @ GrabrielJürgens, sin una política de dominio cruzado, cualquier URI en su intranet (no solo CGI, no sé qué respuesta AJAX es) está en peligro. El atacante puede conocer el URI específico para llamar o simplemente hacer intentos de fuerza bruta, no importa, es un problema de seguridad real. – fguillen

2

La razón más importante para este límite es un problema de seguridad: debe servir JSON navegador solicitud de marca y aceptar cookies o las credenciales de seguridad con la petición a otro dominio? No es una preocupación con el proxy del lado del servidor, ya que no tiene acceso directo al entorno del cliente. Hubo a proposal for safe sanitized JSON-specific request methods, pero aún no se implementó en ninguna parte.

2

Si usted es el autor de myblog.com y hace un XHR a facebook.com, ¿debería la solicitud enviar sus credenciales de cookies de Facebook? No, eso significaría que podrías solicitar información de Facebook privada de los usuarios desde tu blog.

Si crea un servicio proxy para hacerlo, su proxy no puede acceder a las cookies de Facebook.

También es posible que se pregunte por qué JSONP está bien. El motivo es que está cargando un script que no escribió, de modo que a menos que el script de Facebook decida enviarle la información de su código JS, no tendrá acceso al mismo

+0

Tal vez no estoy tan familiarizado con XHR como debería ser ... ¿Existe una habilidad inherente por parte de XHR para extraer y examinar las cookies? Pensé que las cookies eran un mecanismo diferente, y XHR era específicamente (y exclusivamente) un mecanismo de transferencia de datos para las solicitudes HTTP. –

+0

XHR es una solicitud HTTP. Siempre envía cookies para el dominio al que se está conectando, al igual que cuando solicita una página HTML o una imagen de ese dominio, mira sus encabezados que salen si hace un XHR a su propia página, o solicita una imagen, script , o incluso un iframe de otro servidor –

1

La diferencia entre el acceso directo y un proxy son cookies y otra información de identificación/verificación relevante para la seguridad que están absolutamente restringidas a un origen.

Con ellos, su navegador puede acceder a datos confidenciales. Su proxy no lo hará, ya que no conoce los datos de inicio de sesión del usuario.

Por lo tanto, el proxy solo se aplica a datos públicos; como es CORS.

1

Yo sé que usted está pidiendo respuestas de los expertos, sólo soy un neófito, y esto es mi opinión de por qué el proxy lado del servidor no es una solución final correcta:

  • La construcción de un proxy del lado del servidor no es tan fácil como no construirlo en absoluto.
  • No siempre es posible como en Third Party JS widget. No va a pedirle a su editor que declare un registro DNS para integrar su widget. Y modifique el document.domain de sus páginas con los problemas colaterales.
  • Cuando leo en el libro Third Party Javascript"requiere cargar un archivo de túnel intermediario antes de que pueda realizar solicitudes entre dominios". Al menos pones JSONP en el juego con malabarismos más difíciles.
  • No es compatible con IE8, también del libro anterior: "IE8 tiene un error bastante extraño que impide que un dominio de nivel superior se comunique con su subdominio incluso cuando ambos optan por un espacio de nombres de dominio común".
  • Hay varias cuestiones de seguridad que las personas han explicado en otras respuestas, incluso más que ellos, puede consultar el capítulo 4.3.2 Intercambio de mensajes utilizando los subdominios proxies del libro anterior.

Y lo más importante para mí:

  • Es un hack .. como la solución JSONP, es el momento para un estándar, solución fiable, segura, limpia y confortable.

Pero, después de volver a leer su pregunta, creo que todavía no respondió, por lo Por qué esta seguridad AJAX?, de nuevo, creo, la respuesta es:

Debido a que no quieren cualquier página web que visitas para poder hacer llamadas desde su escritorio a cualquier ordenador o servidor en la intranet de su oficina

+0

como dije antes, esto es un completo heraldo. Si su intranet está configurada para tomar y procesar solicitudes de CGI, es probable que esa página se aproveche de ellas. ¡Esto simplemente no es una preocupación real! –

Cuestiones relacionadas