En informática , la política del mismo origen ( SOP ) es un concepto 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 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 (DOM) de esa página.
Este mecanismo tiene una importancia particular para las aplicaciones web modernas que dependen en gran medida de las cookies HTTP [1] para mantener sesiones de usuarios autenticados, ya que los servidores actúan basándose en la información de las cookies HTTP para revelar información confidencial o tomar acciones de cambio de 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 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 desde todos 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 no se aplica la misma política de origen a las etiquetas HTML.
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] JavaScript habilitó secuencias de comandos 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.
Todos los navegadores modernos implementan algún tipo 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 .
El algoritmo utilizado para calcular el "origen" de un URI se especifica en RFC 6454, Sección 4. Para 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 RFC 3986, Sección 3.2) o si el URI no es un URI absoluto, entonces se utiliza un identificador único global. Se considera que dos recursos son del mismo origen si y sólo 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 de 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 en su lugar la Zona de Seguridad. [11]
La política del mismo origen protege contra la reutilización de sesiones autenticadas entre orígenes. El siguiente ejemplo ilustra un posible riesgo de seguridad que podría surgir sin la política del mismo origen. Supongamos que un usuario visita el sitio web de un banco y no cierra 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 ha iniciado sesión en el 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 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 del mismo origen se introdujo como un requisito para que los navegadores preocupados por la seguridad denieguen el acceso de lectura a las respuestas de todos los orígenes, con el supuesto de que la mayoría de los usuarios eligen 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.
En algunas circunstancias, la política del mismo origen es demasiado restrictiva, lo que plantea problemas a los sitios web grandes que utilizan varios subdominios . Al principio, se utilizaron varias soluciones, como el uso del identificador de fragmento o la propiedad, para pasar datos entre documentos que residen en diferentes dominios. window.nameLos navegadores modernos admiten múltiples técnicas para relajar la política del mismo origen de forma controlada:
Netscape Navigator contenía brevemente una función de verificación de contaminación . La característica se introdujo experimentalmente en 1997 como parte de Netscape 3. [12] La característica estaba desactivada de forma predeterminada, pero si la habilitaba un usuario permitiría a los sitios web intentar leer propiedades JavaScript de ventanas y marcos que pertenecen a un dominio diferente. A continuación, el navegador preguntará al usuario si desea permitir el acceso en cuestión. [13] [14]
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 cooperativos en documentos cargados desde pedidos.ejemplo.com y catálogo.ejemplo.com podrían establecer sus document.domainpropiedades en "ejemplo.com", haciendo así 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 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. [15]
El document.domainconcepto se introdujo como parte de Netscape Navigator 3, [16] lanzado en 1996. [12]
La otra técnica para relajar la política del mismo origen está estandarizada bajo el nombre de Cross-Origin Resource Sharing (CORS). Este estándar amplía HTTP con un nuevo encabezado de solicitud de Origen y un nuevo encabezado de respuesta Access-Control-Allow-Origin. [17] 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 utilizan este encabezado para permitir 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 guión de una página pase mensajes de texto a un guión de otra página, independientemente de los orígenes del guión. Llamar al método postMessage() en un objeto Window de forma asincrónica activa 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 puede comunicarse de manera 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 omitir 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 constan de una carga útil JSON interna envuelta por una llamada de función predefinida. Cuando el navegador carga el recurso de secuencia de comandos, se invocará la función de devolución de llamada designada para procesar la carga útil JSON empaquetada.
Los navegadores modernos permitirán que un script se conecte a una dirección WebSocket sin aplicar la política del mismo origen. Sin embargo, reconocen cuándo se utiliza un URI de WebSocket e insertan un encabezado Origen: 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 varios casos extremos, como los pseudoprotocolos que no tienen un nombre de host claramente definido o un puerto asociado con sus URL ( archivo:, datos:, etc. .). Históricamente, esto causó una buena cantidad de problemas de seguridad, como la capacidad generalmente indeseable de cualquier archivo HTML almacenado localmente para acceder a todos los demás archivos en el disco o comunicarse con cualquier sitio en Internet.
Por último, ciertos tipos de ataques, como la revinculación de DNS o los proxies del lado del servidor, permiten subvertir parcialmente la verificación del nombre de host y hacen posible que páginas web maliciosas interactúen directamente con sitios a través de direcciones distintas a sus "verdaderas" canónicas. origen. El impacto de tales ataques se limita a escenarios muy específicos, ya que el navegador todavía cree que está interactuando con el sitio del atacante y, por lo tanto, no revela cookies de terceros u otra información confidencial al atacante.
Incluso cuando la política del mismo origen está vigente (sin que el intercambio de recursos entre orígenes la relaje), se pueden realizar ciertos ataques informáticos entre orígenes. WebRTC se puede utilizar para averiguar la dirección IP interna de una víctima. [18] Si se intenta conectarse a un puerto de origen cruzado, las respuestas no se pueden leer frente a la política del mismo origen, pero 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 tenemos un tiempo de espera. Esto brinda oportunidades para el escaneo de puertos entre orígenes. Además, JavaScript puede incluso tomar huellas dactilares de servicios de origen cruzado aprovechando los archivos predeterminados. Por ejemplo, si un JavaScript cargado desde el sitio evil.com intenta abrir el archivo http://127.0.0.1/images/jenkins.png y se activa el evento onload, entonces se puede inferir que la víctima ejecuta Jenkins en su propia computadora. De esta manera, el atacante puede encontrar servicios potencialmente vulnerables, por ejemplo, en la red interna, incluso frente a una política del mismo origen. Si algún servicio es vulnerable a la falsificación de solicitudes entre sitios, incluso puede verse comprometido. [19]
La política del mismo origen establece que un documento de un origen único solo puede cargar recursos del origen desde el cual se cargó el documento. En particular, esto se aplica a las llamadas XMLHttpRequest realizadas desde un documento. Las imágenes, CSS y scripts cargados dinámicamente no están sujetos a la política del mismo origen.
Las fuentes web están sujetas a la misma restricción de dominio (los archivos de fuentes deben estar en el mismo dominio que la página que los utiliza), a menos que se utilicen controles de acceso HTTP para relajar esta restricción.
Navigator versión 2.02 y posteriores impide automáticamente que los scripts de un servidor accedan a las propiedades de documentos de un servidor diferente.