En informática , la política del mismo origen (a veces abreviada como SOP ) es un concepto importante en el modelo de seguridad de aplicaciones web . Según la política, un navegador web permite que los scripts contenidos en una primera página web accedan a los datos de una segunda página web, pero solo si ambas páginas web tienen el mismo origen . Un origen se define como una combinación de esquema URI , nombre de host y número de puerto . Esta política evita que un script malicioso en una página obtenga acceso a datos confidenciales en otra página web a través del Modelo de objetos de documento de esa página .
Este mecanismo tiene un significado particular para las aplicaciones web modernas que dependen en gran medida de las cookies HTTP [1] para mantener sesiones de usuario autenticadas, ya que los servidores actúan basándose en la información de las cookies HTTP para revelar información confidencial o tomar acciones que cambien el estado. Se debe mantener una separación estricta entre el contenido proporcionado por sitios no relacionados en el lado del cliente para evitar la pérdida de la confidencialidad o integridad de los datos.
Es muy importante recordar que la política del mismo origen se aplica solo a los scripts. Esto significa que se puede acceder a recursos como imágenes, CSS y scripts cargados dinámicamente a través de los orígenes a través de las etiquetas HTML correspondientes [2] (siendo las fuentes una excepción notable [3] ). Los ataques aprovechan el hecho de que la misma política de origen no se aplica a las etiquetas HTML.
Historia
El concepto de política del mismo origen fue introducido por Netscape Navigator 2.02 en 1995, [4] poco después de la introducción de JavaScript en Netscape 2.0. [5] [6] Scripting habilitado para JavaScript en páginas web, y en particular acceso programático al Modelo de Objetos de Documento (DOM).
La política se diseñó originalmente para proteger el acceso al DOM, pero desde entonces se ha ampliado para proteger partes sensibles del objeto JavaScript global.
Implementación
Todos los navegadores modernos implementan alguna forma de política del mismo origen, ya que es una piedra angular de seguridad importante. [7] No es necesario que las políticas coincidan con una especificación exacta [8], pero a menudo se amplían para definir límites de seguridad aproximadamente compatibles para otras tecnologías web, como Microsoft Silverlight , Adobe Flash o Adobe Acrobat , o para mecanismos distintos del DOM directo. manipulación, como XMLHttpRequest .
Reglas de determinación de origen
El algoritmo utilizado para calcular el "origen" de un URI se especifica en RFC 6454, Sección 4. Para los URI absolutos, el origen es el triple {esquema, host, puerto}. Si el URI no usa un elemento jerárquico como autoridad de nomenclatura (ver RFC 3986 , Sección 3.2) o si el URI no es un URI absoluto, entonces se usa un identificador único global. Se considera que dos recursos tienen el mismo origen si y solo si todos estos valores son exactamente iguales.
A modo de ilustración, la siguiente tabla ofrece una descripción general de los resultados típicos de las comprobaciones con la URL " http://www.example.com/dir/page.html ".
| URL comparada | Salir | Razón |
|---|---|---|
| http://www.example.com /dir/page2.html | Éxito | Mismo esquema, host y puerto |
| http://www.example.com /dir2/other.html | Éxito | Mismo esquema, host y puerto |
| http: // nombre de usuario: contraseña @ www.example.com /dir2/other.html | Éxito | Mismo esquema, host y puerto |
| http://www.example.com: 81 /dir/other.html | Falla | Mismo esquema y host pero puerto diferente |
| https : //www.example.com/dir/other.html | Falla | Esquema diferente |
| http: // en.example.com /dir/other.html | Falla | Anfitrión diferente |
| http: // example.com /dir/other.html | Falla | Anfitrión diferente (se requiere coincidencia exacta) |
| http: // v2.www.example.com /dir/other.html | Falla | Anfitrión diferente (se requiere coincidencia exacta) |
| http://www.example.com: 80 /dir/other.html | Depende | Puerto explícito. Depende de la implementación en el navegador. |
A diferencia de otros navegadores, Internet Explorer no incluye el puerto en el cálculo del origen, utilizando la Zona de seguridad en su lugar. [9]
Acceso de lectura a respuestas confidenciales de origen cruzado mediante autenticación reutilizable
La política del mismo origen protege contra la reutilización de sesiones autenticadas en distintos orígenes. El siguiente ejemplo ilustra un riesgo de seguridad potencial que podría surgir sin la política del mismo origen. Suponga que un usuario está visitando un sitio web bancario y no cierra la sesión. Luego, el usuario va a otro sitio que tiene un código JavaScript malicioso que solicita datos del sitio bancario. Debido a que el usuario todavía está conectado al sitio bancario, el código malicioso podría hacer cualquier cosa que el usuario pudiera hacer en el sitio bancario. Por ejemplo, podría obtener una lista de las últimas transacciones del usuario, crear una nueva transacción, etc. Esto se debe a que, en el espíritu original de una red mundial, los navegadores deben etiquetar los detalles de autenticación, como las cookies de sesión y la plataforma. tipos de nivel del encabezado de solicitud de autorización al sitio bancario según el dominio del sitio bancario.
Los propietarios del sitio bancario esperarían que los navegadores habituales de los usuarios que visitan el sitio malicioso no permitan que el código cargado desde el sitio malicioso acceda a la cookie de sesión bancaria o la autorización a nivel de plataforma. Si bien es cierto que JavaScript no tiene acceso directo a la cookie de sesión bancaria, aún podría enviar y recibir solicitudes al sitio bancario con la cookie de sesión del sitio bancario. La Política del mismo origen se introdujo como un requisito para que los navegadores con mentalidad de seguridad deneguen el acceso de lectura a las respuestas de todos los orígenes, con el supuesto de que la mayoría de los usuarios optan por utilizar navegadores compatibles. La política no niega escrituras. Contrarrestar el abuso del permiso de escritura requiere protecciones CSRF adicionales por parte de los sitios de destino.
Relajar la política del mismo origen
En algunas circunstancias, la política del mismo origen es demasiado restrictiva, lo que plantea problemas para los sitios web grandes que utilizan varios subdominios . Al principio, se utilizaron una serie de soluciones, como el uso del identificador de fragmento o la window.namepropiedad, para pasar datos entre documentos que residen en diferentes dominios. Los navegadores modernos admiten múltiples técnicas para relajar la política del mismo origen de manera controlada:
Contaminación de datos
Netscape Navigator incluyó brevemente una función de verificación de corrupción . La función se introdujo experimentalmente en 1997 como parte de Netscape 3. [10] La función estaba desactivada de forma predeterminada, pero si la habilitaba un usuario, permitiría a los sitios web intentar leer las propiedades de JavaScript de ventanas y marcos pertenecientes a un dominio diferente. El navegador le preguntará al usuario si permite el acceso en cuestión. [11] [12]
propiedad document.domain
Si dos ventanas (o marcos) contienen scripts que establecen el dominio en el mismo valor, la política del mismo origen se relaja para estas dos ventanas y cada ventana puede interactuar con la otra. Por ejemplo, los scripts que cooperan en documentos cargados desde orders.example.com y catalog.example.com pueden establecer sus document.domainpropiedades en "example.com", haciendo que los documentos parezcan tener el mismo origen y permitiendo que cada documento lea las propiedades del otro. Establecer esta propiedad establece implícitamente el puerto en nulo, que la mayoría de los navegadores interpretarán de manera diferente al puerto 80 o incluso a un puerto no especificado. Para asegurarse de que el navegador permita el acceso, establezca la propiedad document.domain de ambas páginas. [13]
El document.domainconcepto se introdujo como parte de Netscape Navigator 3, [14] lanzado en 1996. [10]
Uso compartido de recursos de origen cruzado
La otra técnica para relajar la política del mismo origen está estandarizada con el nombre de Intercambio de recursos de origen cruzado . Este estándar extiende HTTP con un nuevo encabezado de solicitud Origin y un nuevo encabezado de respuesta Access-Control-Allow-Origin. [15] Permite a los servidores usar un encabezado para enumerar explícitamente los orígenes que pueden solicitar un archivo o usar un comodín y permitir que cualquier sitio solicite un archivo. Los navegadores como Firefox 3.5, Safari 4 e Internet Explorer 10 utilizan este encabezado para permitir las solicitudes HTTP de origen cruzado con XMLHttpRequest que, de otro modo, estarían prohibidas por la política del mismo origen.
Mensajería entre documentos
Otra técnica, la mensajería entre documentos permite que un guión de una página pase mensajes de texto a un guión en otra página, independientemente de los orígenes del guión. Llamar al método postMessage () en un objeto Window de forma asincrónica dispara un evento "onmessage" en esa ventana, activando cualquier controlador de eventos definido por el usuario. Un script en una página aún no puede acceder directamente a métodos o variables en la otra página, pero pueden comunicarse de manera segura a través de esta técnica de transmisión de mensajes.
JSONP
Dado que los elementos HTML 