ajax y dominio cruzado

Pantaláimon · #1 (**permalink**) 21/05/2014, 01:15

Buenas,

Estoy un poco confuso con el impedimento de hacer peticiones ajax a dominios cruzados. Creo que no entiendo el concepto porque yo puedo hacer esta petición ajax al dominio api.openweathermap.org siendo mi dominio localhost:

Código HTML:

Ver original<!DOCTYPE html>
<html>
<head>
<title>Hola Mundo con AJAX</title>
 
<script type="text/javascript">
function descargaArchivo() {
  // Obtener la instancia del objeto XMLHttpRequest
  if(window.XMLHttpRequest) {
    peticion_http = new XMLHttpRequest();
  }
  else if(window.ActiveXObject) {
    peticion_http = new ActiveXObject("Microsoft.XMLHTTP");
  }
 
  // Preparar la funcion de respuesta
  peticion_http.onreadystatechange = muestraContenido;
 
  // Realizar peticion HTTP
  peticion_http.open('GET', 'http://api.openweathermap.org/data/2.5/weather?q=London,uk', true);
  peticion_http.send(null);
 
}
 
function muestraContenido() {
  if(this.readyState == 4) {
    if(this.status == 200) {
      var json = JSON.parse(this.responseText);
      alert( json );
    }
  }
}
 
window.onload = descargaArchivo;
 
</script>
 
</head>
<body></body>
</html>

¿Que es lo que se me escapa?

Un saludo!

quimfv · #2 (**permalink**) 21/05/2014, 02:07

La configuración de tu localhost? Que esta lo permita no quiere decir que te lo vaya a permitir otras configuraciones.

Pantaláimon · #3 (**permalink**) 21/05/2014, 04:29

Pensaba que lo de impedir acceder a dominios cruzados era algo implementado por el navegador. De todas maneras como el virtual host es en xampp y en windows así para hacer alguna prueba, no me he preocupado de configurar nada. He creado un virtual host en un servidor ubuntu que tengo externo y la petición ajax sigue funcionando:

http://test.trantor.co.vu/

En todo caso, ¿algún tipo de información que me lo aclare? Pues estoy buscando por otro lado como consumir de un web service SOAP con javascript y mucha de la referencia que encuentro me habla del problema de cross-domain. Por eso me extraña que para este ejemplo que pongo con json no haya ningún problema ni tenga que usar jsonp o otras historias que se cuentan.

Un saludo!

chuidiang · #4 (**permalink**) 21/05/2014, 06:52

Hola:

Es como tú piensas, pero en tu caso se admite porque el servidor al que consultas (openweathermap) devuelve en su cabecera http permisos para ser consultado desde cualquier dominio. La cabecera http de respuesta de openweathermap que puedes ver con las herramientas de debug de google chrome por ejemplo, contiene esto

Access-Control-Allow-Credentials:true
Access-Control-Allow-Methods:GET, POST
Access-Control-Allow-Origin:*

donde Access-Control-Allow-Origin:* indica que se pueden hacer peticiones desde cualquier dominio (localhost en tu caso).

Te cuento un poco el motivo de la restricción de dominios cruzados y porqué es el dominio consultado el que tiene que dar el permiso.

Imagina que yo estoy en mi casa o en el trabajo con mi router y tengo cuatro o cinco PCs en mi red interna con un servidor web activo. Desde un pc navego y cargo una web de internet que tenga mala leche. El código javascript de esa página se ejecuta en mi PC y dentro de mi red, por lo que podría pedir consultas web a otros PCs de mi red interna y enviar información a su servidor. Se agrava el tema si encima por temas de cookies tengo sesión abierta en esos PCs internos, por lo que javascript accedería incluso con mi usuario y mis permisos en las web internas de mis PCs. Este es el motivo por el que existe la restricción de peticiones cruzadas: evitar que un servidor externo por medio de javascript pueda acceder a recursos de mi red interna.

Y es por eso que el permiso para hacer peticiones cruzadas debe darlo el que recibe la petición cruzada (mis PCs de mi red) y no el servidor web con la página original. Si mis PCs no devuelven nada en la cabecera http relativo a permisos de control cruzado, están por defecto no accesibles y el navegador no deja acceder a ellos. Si mis PCs indican que sí se puede acceder, el navegador sí dejará acceder a ellos aunque sea una petición cruzada.

Se bueno.

Pantaláimon · #5 (**permalink**) 23/05/2014, 00:12

Gracias chuidiang.

He leído tu post varias veces y la segunda parte sobretodo me está costando de entender. Así que no he respondido hasta tener un rato para poder analizarlo con detalle.

Cita:

Iniciado por chuidiang

Es como tú piensas, pero en tu caso se admite porque el servidor al que consultas (openweathermap) devuelve en su cabecera http permisos para ser consultado desde cualquier dominio. La cabecera http de respuesta de openweathermap que puedes ver con las herramientas de debug de google chrome por ejemplo, contiene esto

Access-Control-Allow-Credentials:true
Access-Control-Allow-Methods:GET, POST
Access-Control-Allow-Origin:*

donde Access-Control-Allow-Origin:* indica que se pueden hacer peticiones desde cualquier dominio (localhost en tu caso).

Gracias. He probado de crear un web service SOAP en PHP con lo que has dicho. A parte del header:

Access-Control-Allow-Origin:*

He tenido que poner la siguiente linea:

Access-Control-Allow-Headers:Origin, X-Requested-With, Content-Type, Accept
Aún no he investigado por qué, pero sino no podía hacer una petición ajax al web service.

Cita:

Imagina que yo estoy en mi casa o en el trabajo con mi router y tengo cuatro o cinco PCs en mi red interna con un servidor web activo.

Imaginaré que en cualquier sitio tienes una red con 5 PCs y un servidor web activo.

Cita:

Desde un pc navego

¿Un pc de la red u otro externo a la red?

Cita:

y cargo una web de internet que tenga mala leche. El código javascript de esa página se ejecuta en mi PC y dentro de mi red

Ah, de acuerdo. Cargas una página web maliciosa desde un PC que está dentro de la red, he de entender.

Cita:

, por lo que podría pedir consultas web a otros PCs de mi red interna y enviar información a su servidor.

Vale, si me dices que la web maliciosa puede pedir consultas web a otros PCs de tu red, yo entiendo que es porque el mismo dominio apunta diferentes PCs de tu red.
¿Me lo imagino bien?

Cita:

Se agrava el tema si encima por temas de cookies tengo sesión abierta en esos PCs internos, por lo que javascript accedería incluso con mi usuario y mis permisos en las web internas de mis PCs.

No acabo de entender porque tienes sesión abierta en esos PCs? ¿Son PCs servidores o clientes? Yo pensaba que eran servidores por eso de tener un servidor web activo. La verdad es que me ha líado mucho la explicación por no separar cuales son máquinas servidoras de cuales son clientes. Por eso propongo otro escenario a ver si así me aclaro.

Simplifiquemos las cosas. Actores de la historia:
Servidor B: contiene una web bienitencionada(aunque posiblemente corruptible introduciendole algun script): webbuena.com
Servidor M: contiene una web maliciosa: webmala.com
Cliente: usa el navegador para cargar alguna de las páginas de los servidores B o M.

Vamos a suponer que no existe la política del mismo origen en los navegadores y a ver que ocurriría en diferentes casos que voy a exponer:

CASO 1:
La web maliciosa contiene algun script que obtiene y envia datos de webbuena.com

CASO 2:
A la web bienintencionada le introducen algun script que hace que pueda obtener o enviar datos de la web maliciosa.

Me cuesta entender como a través de una petición AJAX la respuesta a dicha petición puede traer consigo las cookies. Pues en teoría devuelve una cadena de texto en formato XML o JSON. Es muy importante para mi entenderlo para luego poder aplicar la seguridad conveniente a través de la directiva Access-Control-Allow-Origin.

Un saludo y gracias.

chuidiang · #6 (**permalink**) 23/05/2014, 01:07

Hola:

Imagina en tu red dos PCs, en uno navegas tú y el otro tiene un servidor web arrancado. Imagina que sus nombres son pc1 (en el que navegas) y el otro es pc2 ( accesible desde pc1 por medio de http://pc2 ) pero que no está accesible desde internet.

Si desde pc1 cargas un sitio web malicioso de internet (por ejemplo http://sitiomalo ), ese sitio malo puede enviarte código javascript que se ejecutará en tu pc1 y que intente hacer consultas a http://pc2 que sí está accesible desde pc1 . Sin protección de crosssitescripting, el código javascript de sitiomalo puede cargar páginas de http://pc2 y enviar su contenido a http://sitiomalo/tomaContenidoPirateado.

Si además http://pc2 está protegido con usuario y password y estás con sesión abierta desde pc1, http://sitiomalo accederá como si estuviera en sesión ya que http://pc2 sabe que tu navegador le está pidiendo cosas desde pc1 y hay un usuario con sesión abierta. El tema de cookies lo maneja el navegador por defecto, si tienes una sesión abierta lo habitual es guardarla en una cookie. Cada vez que el navegador hace una petición a un dominio (sea ajax o normal), envía la cookie de ese dominio si la tiene.

Se bueno.