Siempre me he preguntado cuál es el propósito de las restricciones de dominio cruzado XHR.¿Cuál es el propósito de las restricciones de dominio cruzado XHR?
Parece que la intención es evitar que Javascript inyectado maliciosamente envíe datos privados al atacante. Sin embargo, el envío de datos a cualquier dominio es fácilmente posible con una etiqueta script o img inyectada (o cualquier otro recurso externo para el caso).
Si cualquier sitio web arbitraria podría realizar una llamada de XHR a su sitio web, entonces podría pasar lo siguiente:
Como está, incluso con la política de dominio cruzado, el malvado sitio web de Bob puede, de hecho, POSTAR una solicitud HTTP a su servidor mediante la publicación de un formulario. No podrá ver los resultados, pero si Bob es inteligente, es posible que haya descubierto una URL en su sitio que permite cierta actividad desde un POST incluso si no proviene de un formulario en una de sus páginas. Eso se llama Falsificación de solicitudes entre sitios, y es algo de lo que el navegador no puede protegerte.
Puede crear un sitio web para acceder a algunos sitios web que causan DoS. Es uno de los posibles usos maliciosos de Cross XHR.
Puede hacer lo mismo al incluir cientos de imágenes invisibles del otro sitio web con parámetros de obtención aleatoria. – kassens
Consulte el siguiente artículo de la wiki que podría ayudar.
El artículo enumera formas de eludir la restricción. Estas soluciones son lo que me hace preguntarme el propósito de esta medida de seguridad individual. Parece que una de las ventanas de una casa está bloqueada mientras la puerta y otras ventanas están abiertas. – kassens
política de seguridad del mismo sitio está diseñado de manera que para un atacante sea capaz de inyectar código malicioso en una página web se requiere uno de los siguientes:
Si construye su sitio web para que solo haga referencia a recursos en su propio dominio, y no hace nada estúpido como aceptar javascript (o SQL) incrustado en la URL o usar javascript eval() en el texto de entrada del usuario, está relativamente buena forma para la privacidad de datos en su página web.
Si enlaza con recursos de secuencias de comandos o imágenes que residen en un dominio diferente, la seguridad de su sitio web también depende de la seguridad de ese dominio externo.
La mejor manera de protegerse contra el # 3 anterior (hombre en el ataque medio) es asegurar todas las solicitudes a su servidor (para página, secuencia de comandos e imágenes) utilizando el protocolo https en lugar de http.El hombre en el medio no puede producir un certificado de cifrado válido para el dominio de destino, por lo que el navegador al menos puede advertir al usuario de que hay algo sospechoso en el sitio.
El caso clásico para la seguridad del mismo sitio es envolver una página web objetivo en un iframe en una página alojada por el servidor evil.com del atacante. Si la URL de la página principal y la URL del contenido de iframe están en el mismo dominio, entonces se les permite hablar entre ellos y ver los datos internos, las variables, el DOM, etc. Si los dominios son diferentes, la política de seguridad del mismo dominio indica que el navegador no debe permitir que el iframe vea ninguna variable o información DOM de su elemento principal, ni el elemento principal para ver las variables o DOM del interior del iframe. Esto es para evitar el intercambio involuntario o inapropiado de datos entre los dos dominios.
Si falta la política de seguridad del mismo dominio, sería un asunto muy simple para un atacante ajustar el sitio web de su banco en un iframe, conducirlo con una dirección incorrecta (enlaces con correo electrónico falso enviado) para iniciar sesión en el sitio envuelto, y de forma casual observar toda su actividad bancaria. A partir de ahí, pueden drenar sus cuentas en cuestión de segundos.
Tenga en cuenta también que XHR se agregó al entorno del navegador como una extensión de terceros inicialmente, por lo que la mejor medida era seguir el modelo de seguridad del navegador existente para las solicitudes del cliente. XHR sigue las mismas reglas que usa el navegador para buscar páginas html, secuencias de comandos e imágenes. Si XHR se diseñó en la especificación HTML desde el inicio en lugar de ser añadida posteriormente, las cosas podrían haber sido diferentes para XHR. Vea el HTML5 PostMessage spec como un ejemplo.
+1 - ¿Puedo tener el número de Alice? – jAndy
¿No sería una solución mejor no incluir cookies? Esto evitaría la necesidad de hacks como JSONP. El único problema que pude ver es la 'seguridad' basada en IP (por ejemplo, en los enrutadores domésticos). – kassens
Bloquear cookies de sesión en solicitudes XHR significaría que la página web con un usuario conectado (token de autenticación almacenado en cookie de sesión) no podría hablar con el servidor web a través de XHR, ya que cada solicitud XHR carecería de la información de autorización de token normalmente añadida en la solicitud del navegador como una cookie de sesión. Puede incrustar información de autenticación en la solicitud de XHR sin utilizar cookies, pero debe escribir el código para incrustarlo en el cliente y el código para extraerlo en el servidor. Y además, las cookies son solo una faceta del problema de acceso a sitios cruzados. Ver mi respuesta para más. – dthorpe