En informática móvil, la política de mismo origen ( SOP ) es un concepto del modelo de seguridad de aplicaciones web-app. 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 (DOM) de esa página.
Este mecanismo tiene una importancia particular 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 tomar medidas que modifican el estado. Se debe mantener una estricta separación entre el contenido proporcionado por sitios no relacionados en el lado del cliente para evitar la pérdida de confidencialidad o integridad de los datos.
La política del 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 a través de los orígenes a través de las etiquetas HTML correspondientes (las fuentes son una notable excepción). Los ataques aprovechan el hecho de que la política del mismo origen no se aplica a las etiquetas HTML.
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 creación de scripts en páginas web y, en particular, el acceso programático al Modelo de objetos de documento (DOM).
La política fue diseñada 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 política del mismo origen, ya que es una piedra angular de seguridad importante. [4] No es necesario que las políticas coincidan 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 un URI se especifica en la RFC 6454, Sección 4. Para los URI absolutos, el origen es el triple {esquema, host, puerto}. Si el URI no utiliza un elemento jerárquico como autoridad de denominación (consulte la RFC 3986, Sección 3.2) o si el URI no es un URI absoluto, se utiliza 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 realizadas en 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, utilizando la Zona de Seguridad en su lugar. [8]
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. Supongamos que un usuario visita 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 haga 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 World Wide Web, se requiere que los navegadores incluyan detalles de autenticación, como cookies de sesión y tipos de nivel de plataforma del encabezado de solicitud de autorización, en el sitio bancario según el dominio del sitio bancario.
Los propietarios de sitios bancarios 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 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 bancario con la cookie de sesión del sitio bancario. La política de mismo origen se introdujo como un requisito para que los navegadores preocupados por la seguridad denegaran el acceso de lectura a las respuestas de todos los orígenes, con la suposición de que la mayoría de los usuarios eligen usar navegadores compatibles. La política no deniega las escrituras. Contrarrestar el abuso del permiso de escritura requiere protecciones CSRF adicionales por parte de los sitios de destino.
En algunas circunstancias, la política del mismo origen es demasiado restrictiva, lo que plantea problemas para los sitios web de gran tamaño que utilizan varios subdominios . Al principio, se utilizaron varias soluciones alternativas, 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 varias técnicas para relajar la política del mismo origen de forma controlada:
Netscape Navigator incluyó durante un breve período una función de comprobación de defectos . Esta función se introdujo de forma experimental en 1997 como parte de Netscape 3. [9] La función estaba desactivada de forma predeterminada, pero si un usuario la habilitaba, permitía a los sitios web intentar leer las propiedades de JavaScript de ventanas y marcos pertenecientes a un dominio diferente. El navegador preguntaba entonces al usuario si permitía el acceso en cuestión. [10] [11]
Si dos ventanas (o marcos) contienen secuencias de comandos que asignan el mismo valor a domain, la política de origen idéntico se relaja para estas dos ventanas y cada ventana puede interactuar con la otra. Por ejemplo, las secuencias de comandos que cooperan en documentos cargados desde orders.example.com y catalog.example.com pueden asignar sus document.domainpropiedades a “example.com”, lo que hace que parezca que los documentos tienen el mismo origen y permite que cada documento lea las propiedades del otro. Al asignar esta propiedad, se asigna implícitamente el puerto a null, lo que la mayoría de los navegadores interpretarán de forma diferente al puerto 80 o incluso a un puerto no especificado. Para garantizar que el navegador permita el acceso, configure 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 relajar la política de origen común está estandarizada bajo el nombre de Cross-Origin Resource Sharing (CORS). Este estándar extiende HTTP con un nuevo encabezado de solicitud Origin y un nuevo encabezado de respuesta Access-Control-Allow-Origin. [14] Permite a los servidores utilizar un encabezado para enumerar explícitamente los orígenes que pueden solicitar un archivo o utilizar 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 común con XMLHttpRequest que de otro modo habrían estado prohibidas por la política de origen común.
Otra técnica, la mensajería entre documentos, permite que un script de una página pase mensajes de texto a un script de otra página, independientemente del origen del script. Al llamar al método postMessage() en un objeto Window, se activa de forma asincrónica un evento "onmessage" en esa ventana, lo que activa cualquier controlador de eventos definido por el usuario. Un script de una página no puede acceder directamente a los métodos o variables de la otra página, pero pueden comunicarse de forma segura a través de esta técnica de paso de mensajes.
Dado que los elementos HTML <script>pueden recuperar y ejecutar contenido de otros dominios, una página puede eludir la política del 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 de función predefinida. Cuando el navegador carga el recurso de script, se invocará 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 de mismo origen. Sin embargo, reconocen cuando se utiliza una URI de 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 comparar los datos del encabezado con una lista de orígenes permitidos para recibir una respuesta.
El comportamiento de las comprobaciones del mismo origen y los mecanismos relacionados no está bien definido en una serie de casos especiales, como por ejemplo en el caso de pseudoprotocolos que no tienen un nombre de host o un puerto claramente definidos asociados a sus URL ( file:, data:, etc.). Esto históricamente ha causado una buena cantidad de problemas de seguridad, como la capacidad generalmente indeseable de cualquier archivo HTML almacenado localmente de acceder a todos los demás archivos del disco o comunicarse con cualquier sitio de Internet.
Por último, ciertos tipos de ataques, como la revinculación de DNS o los proxies del lado del servidor, permiten subvertir parcialmente la comprobación del nombre de host y hacen posible que las páginas web maliciosas interactúen directamente con sitios a través de direcciones distintas a su origen "verdadero" y canónico. El impacto de estos ataques se limita a escenarios muy específicos, ya que el navegador sigue creyendo que está interactuando 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 origen idéntico está en vigor (sin que se relaje con el uso compartido de recursos de origen cruzado), se pueden realizar ciertos ataques de origen cruzado. Se puede utilizar WebRTC para averiguar la dirección IP interna de una víctima. Si se intenta conectarse a un puerto de origen cruzado, no se pueden leer las respuestas frente a la política de origen idéntico, pero un JavaScript aún puede hacer inferencias sobre si el puerto está abierto o cerrado al verificar si se activa el evento onload/onerror o si obtenemos un tiempo de espera. Esto brinda oportunidades para el escaneo de puertos de origen cruzado . Además, los fragmentos de JavaScript pueden usar técnicas como fugas de sitios cruzados para explotar fugas de información de larga data en el navegador para inferir información sobre el origen cruzado.
La versión 2.02 y posteriores de Navigator impiden automáticamente que los scripts de un servidor accedan a las propiedades de los documentos de un servidor diferente.