Política de mismo origen

En informática, la política de mismo origen ( SOP ) es un concepto del modelo de seguridad de aplicaciones web . Según esta política, un navegador web permite que los scripts de una primera página web accedan a los datos de una segunda página, pero solo si ambas páginas 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 impide que un script malicioso de una página acceda a datos confidenciales de otra página web a través del Modelo de Objetos del Documento (DOM) de dicha página.

Este mecanismo cobra especial relevancia para las aplicaciones web modernas que dependen en gran medida de las cookies HTTPS para mantener sesiones de usuario autenticadas, ya que los servidores actúan en función de la información de las cookies HTTP para revelar información confidencial o realizar acciones que modifiquen el estado. Es fundamental mantener una estricta separación entre el contenido proporcionado por sitios web no relacionados en el lado del cliente para evitar la pérdida de confidencialidad o integridad de los datos.

La política de mismo origen se aplica únicamente a los scripts. Esto significa que se puede acceder a recursos como imágenes, CSS y scripts cargados dinámicamente desde diferentes orígenes mediante las etiquetas HTML correspondientes (con la excepción de las fuentes). Los ataques se aprovechan de que la política de mismo origen no se aplica a las etiquetas HTML.

Existen algunos mecanismos disponibles para flexibilizar el SOP; uno de ellos es el intercambio de recursos de origen cruzado (CORS, por sus siglas en inglés).

El concepto de política del mismo origen fue introducido por Netscape Navigator 2.02 en 1995, ^{[ 1 ]} poco después de la introducción de JavaScript en Netscape 2.0. ^{[ 2 ] [ 3 ]} JavaScript permitió la ejecución de scripts en páginas web y, en particular, el acceso programático al 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.

Todos los navegadores modernos implementan alguna forma de la política del mismo origen, ya que es una piedra angular de seguridad importante. ^{[ 4 ]} Las políticas no tienen que coincidir con una especificación exacta ^{[ 5 ]} pero a menudo se extienden 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 de la manipulación directa del DOM, como XMLHttpRequest .

El algoritmo utilizado para calcular el origen de una URI se especifica en la RFC 6454, Sección 4. Para las URI absolutas, el origen es la tripleta {esquema, host, puerto}. Si la URI no utiliza un elemento jerárquico como autoridad de nomenclatura (véase la RFC 3986 , Sección 3.2) o si no es una URI absoluta, se utiliza un identificador único global. Dos recursos se consideran del mismo origen si y solo si todos estos valores son exactamente iguales.

A modo de ejemplo, la siguiente tabla ofrece una visión general de los resultados típicos de las comprobaciones realizadas con la URL " http://www.example.com/dir/page.html ".

A diferencia de otros navegadores, Internet Explorer no incluye el puerto en el cálculo del origen, sino que utiliza la Zona de Seguridad en su lugar. ^{[ 8 ]}

La política de mismo origen protege contra la reutilización de sesiones autenticadas en distintos orígenes. El siguiente ejemplo ilustra un riesgo potencial de seguridad que podría surgir sin esta política. Supongamos que un usuario visita un sitio web bancario y no cierra sesión. A continuación, accede a otro sitio que contiene código JavaScript malicioso que solicita datos al sitio bancario. Dado que el usuario sigue conectado al sitio bancario, el código malicioso podría realizar cualquier acción que el usuario pudiera realizar en dicho sitio. 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 diseño original de la World Wide Web, los navegadores deben enviar detalles de autenticación, como cookies de sesión y encabezados de solicitud de autorización específicos de la plataforma, al sitio bancario, según el dominio de este.

Los propietarios del sitio web del banco esperarían que los navegadores habituales de los usuarios que visitan el sitio malicioso no permitan que el código cargado desde dicho sitio acceda a la cookie de sesión bancaria ni a 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 web del banco utilizando dicha cookie. La Política del Mismo Origen se introdujo como un requisito para que los navegadores con enfoque en la seguridad denieguen el acceso de lectura a las respuestas de diferentes orígenes, partiendo de la premisa de que la mayoría de los usuarios optan por utilizar navegadores compatibles. Esta política no deniega los permisos de escritura. Para contrarrestar el abuso del permiso de escritura, los sitios web objetivo requieren protecciones CSRF adicionales.

En algunos casos, la política del mismo origen resulta demasiado restrictiva, lo que plantea problemas para sitios web grandes que utilizan múltiples subdominios . Inicialmente, se recurría a diversas soluciones alternativas, como el uso del identificador de fragmento o la window.namepropiedad, para transferir datos entre documentos ubicados en diferentes dominios. Los navegadores modernos admiten múltiples técnicas para flexibilizar la política del mismo origen de forma controlada.

Netscape Navigator incluyó brevemente una función de comprobación de contaminación . Esta función se introdujo experimentalmente en 1997 como parte de Netscape 3. ^{[ 9 ]} La función estaba desactivada por defecto, pero si un usuario la activaba, permitía que los sitios web intentaran leer las propiedades JavaScript de ventanas y marcos pertenecientes a un dominio diferente. El navegador preguntaba entonces al usuario si permitía dicho acceso. ^{[ 10 ] [ 11 ]}

Si dos ventanas (o marcos) contienen scripts que establecen el dominio al mismo valor, la política de 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 podrían 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, lo que la mayoría de los navegadores interpretarán de forma diferente al puerto 80 o incluso a un puerto no especificado. Para asegurar que el navegador permita el acceso, establezca la propiedad document.domain de ambas páginas. ^{[ 12 ]}

El document.domainconcepto se introdujo como parte de Netscape Navigator 3, ^{[ 13 ]} lanzado en 1996. ^{[ 9 ]}

La otra técnica para flexibilizar la política del mismo origen está estandarizada bajo el nombre de intercambio de recursos de origen cruzado (CORS). Este estándar extiende HTTP con un nuevo Originencabezado de solicitud y un nuevo Access-Control-Allow-Originencabezado de respuesta. ^{[ 14 ]} 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. Navegadores como Firefox 3.5, Safari 4 e Internet Explorer 10 usan este encabezado para permitir las solicitudes HTTP de origen cruzado con XMLHttpRequest que de otro modo habrían estado prohibidas por la política del mismo origen.

Otra técnica, la mensajería entre documentos , permite que un script de una página envíe mensajes de texto a otro script de otra página, independientemente de su origen. Al llamar al método `postMessage()` en un objeto `Window`, se activa de forma asíncrona un evento `onmessage` en esa ventana, lo que desencadena cualquier controlador de eventos definido por el usuario. Si bien un script de una página no puede acceder directamente a los métodos o variables de la otra página, pueden comunicarse de forma segura mediante esta técnica de intercambio de mensajes.

Dado que los elementos HTML <script>pueden recuperar y ejecutar contenido de otros dominios, una página puede eludir la política de mismo origen y recibir datos JSON de un dominio diferente cargando un recurso que devuelve una carga útil JSONP. Las cargas útiles JSONP consisten en una carga útil JSON interna envuelta por una llamada a una función predefinida. Cuando el navegador carga el recurso de script, se invoca la función de devolución de llamada designada para procesar la carga útil JSON envuelta.

Los navegadores modernos permiten que un script se conecte a una dirección WebSocket sin aplicar la política del mismo origen. Sin embargo, reconocen cuando se utiliza una URI WebSocket e insertan un encabezado Origin: en la solicitud que indica el origen del script que solicita la conexión. Para garantizar la seguridad entre sitios, el servidor WebSocket debe verificar que ese origen tenga permiso para recibir una respuesta.

El comportamiento de las comprobaciones de mismo origen y mecanismos relacionados no está bien definido en varios casos excepcionales, como en el caso de los pseudoprotocolos que no tienen un nombre de host o puerto claramente definido asociado a sus URL ( archivo:, datos:, etc.). Históricamente, esto ha provocado numerosos problemas de seguridad, como la capacidad, generalmente indeseable, de cualquier archivo HTML almacenado localmente para acceder a todos los demás archivos del disco o comunicarse con cualquier sitio web de Internet.

Por último, ciertos tipos de ataques, como la modificación de DNS o los proxies del lado del servidor, permiten eludir parcialmente la verificación del nombre de host y posibilitan que páginas web maliciosas interactúen directamente con sitios a través de direcciones distintas a su origen canónico "verdadero". El impacto de estos ataques se limita a escenarios muy específicos, ya que el navegador sigue creyendo que interactúa con el sitio del atacante y, por lo tanto, no revela cookies de terceros ni otra información confidencial al atacante.

Incluso cuando la política de mismo origen está en vigor (sin ser relajada por el Intercambio de Recursos de Origen Cruzado), se pueden realizar ciertos ataques de origen cruzado. WebRTC se puede utilizar para averiguar la dirección IP interna de una víctima. ^{[ 15 ]} Si se intenta conectar a un puerto de origen cruzado, las respuestas no se pueden leer frente a la política de mismo origen, pero un JavaScript aún puede hacer inferencias sobre si el puerto está abierto o cerrado comprobando si se dispara el evento onload/onerror, o si se produce un tiempo de espera. Esto ofrece oportunidades para el escaneo de puertos de origen cruzado .

Además, los fragmentos de JavaScript pueden usar técnicas como fugas entre sitios ^{[ 16 ]} para explotar fugas de información de larga data en el navegador e inferir información de origen cruzado. Estos ataques pueden contrarrestarse implementando un encabezado de Política de Recursos de Origen Cruzado (CORP), que permite al propietario de un sitio web bloquear recursos de origen cruzado o entre sitios, como imágenes, videos y hojas de estilo. CORP también puede bloquear fetchsolicitudes iniciadas por JavaScript, pero solo si se envían con el modo de solicitud no-cors^{[ 17 ]} . ^{[ 18 ]}

La política de mismo origen no impide que el navegador realice solicitudes GET, POST, OPTIONS y TRACE; solo impide que el código del usuario lea las respuestas. Por lo tanto, si un punto final utiliza uno de estos métodos de solicitud "seguros" para escribir información o realizar una acción en nombre de un usuario, puede ser explotado por atacantes.

Cabe señalar que la política del mismo origen no se aplica a las cookies por razones históricas. ^{[ 19 ]} Si se implementan varios sitios maliciosos en el mismo nombre de host con diferentes números de puerto, en contra de la política del mismo origen, todas las cookies establecidas por cualquiera de los sitios se comparten. Esto puede utilizarse para filtrar los tokens de sesión de los usuarios y robar información de las cuentas. Por lo tanto, los servicios web deben separarse diferenciando los subdominios en lugar de los números de puerto.

• Intercambio de recursos entre diferentes orígenes
• Secuencias de comandos entre sitios
• Falsificación de solicitudes entre sitios
• Política de seguridad de contenido

• La política de mismo origen en 500 líneas o menos .

• Una comparación detallada de varias variantes de políticas de mismo origen.
• Revisión de las deficiencias en las políticas de mismo origen y sus implicaciones para la seguridad web en Wayback Machine (archivado el 11 de febrero de 2007).
• Especificación de política de mismo origen proporcionada por el proveedor (ejemplo)
• La definición de origen en la especificación HTML5
• Artículo del W3C sobre la política del mismo origen.
• RFC 6454 sobre el concepto de origen web