Política de mismo origen en términos de Layman

Question

¿Alguien me puede ayudar a comprender mejor la Política de mismo origen. He visto varios sitios web describiéndolo pero estoy buscando una explicación mucho más simple, ¿cómo le describirías a un niño?

Este link parece hacer el mejor trabajo que he encontrado. ¿Alguien puede expandirse? ¿Alguien puede explicar por qué existe esta política?

Answer 1

Se necesita la misma política de origen para evitar CSRF. Imagine este escenario:

1. El gerente del banco Joe Fatcat tiene una cuenta en el backend administrativo de su banco. Esta cuenta le permite acceder a información confidencial de la cuenta para cualquier persona que realice operaciones bancarias en TBtF Bank. Incluso puede restablecer el número de pin de alguien, transferir fondos, cambiar la propiedad de la cuenta, etc.
2. Ahora, TBtF Bank establece Jack the IT Guy. Ahora él es Jack the Digruntled Ex-IT-Guy, y quiere vengarse de su antiguo empleador. Jack no tiene acceso al backend administrativo del banco, pero sabe que Joe sí.
3. Así que Jack envía a su jefe un correo electrónico con un enlace a la página que Jack creó. En la página, hay un poco de JavaScript como:

var xhr = new XMLHttpRequest(), 
    data = "from="+victimAccount 
      + "&to="+jacksAccount 
      + "&amt=a+gazillion+dollars"; 
xhr.open("POST", "http://tbtfbank.tld/accounts/wiretransfer.aspx", true); 
xhr.send(data); 

3. Al día siguiente, Joe llega a su oficina e inicia sesión en su cuenta administrativa como siempre hace y deja la pestaña abierta en el fondo.
4. Joe ve un correo electrónico que contiene enlaces a imágenes de Natalie Portman cubiertas de granos calientes. Entonces, naturalmente, hace clic en él y abre la página web maliciosa.
5. El navegador ejecuta JavaScript en la página y realiza una solicitud POST AJAX al sitio administrativo backend de TBtF Bank. Debido a que Joe ya inició sesión en el sitio y tiene una sesión activa, la aplicación del banco acepta el comando y transfiere miles de millones de dólares a la cuenta bancaria extraterritorial de Jack.

Y Jack podría haber usado la misma técnica para cosechar miles de números de cuenta y pines o cualquier otra información a la que tenga acceso el administrador del banco a través de su cuenta.

Afortunadamente, la misma política de origen nos protege de este tipo de ataques la mayor parte del tiempo, ya que la página maliciosa de Jack está alojada en un dominio diferente de la aplicación bancaria, no está permitido hacer XHR en la aplicación bancaria.Aunque la página maliciosa podría contener una imagen que realiza una solicitud GET a la aplicación bancaria, es importante que las acciones con efectos secundarios no se inicien a través de solicitudes GET y que las aplicaciones verifiquen el encabezado de referencia de las solicitudes que reciben y aprovechen las ventajas Fichas de CSRF.

Answer 2

Básicamente significa que solo los scripts que se sirven desde el mismo dominio pueden acceder a los objetos y propiedades de los demás sin restricciones (por lo que si tiene un archivo .js definido con funciones nombradas, puede llamarlo desde cualquier otro archivo alojado en el mismo dominio).

lo tanto, si usted está sirviendo una secuencia de comandos desde una restricción de dominio diferente hacer se aplican.

Esta política existe porque es demasiado fácil insertar un enlace a un archivo javascript (digamos un código JavaScript que inyecta un enlace a dicho archivo) que está en un dominio diferente. Este es un riesgo de seguridad: en realidad solo quiere código que proviene del sitio en el que se encuentra ejecutado y no solo cualquier código que esté disponible.