¿Por qué los navegadores aplican la política de seguridad del mismo origen en los iframes?

57

Hoy hice una pequeña prueba en Chrome (V37). Creé una pequeña página y la cargué en el navegador:

<!DOCTYPE html>
<html>
<head>
    <title>Untitled Document</title>
</head>
<body>
    <p>Normal page</p>
    <iframe src="https://security.stackexchange.com/"/></body></html>

Alinspeccionarlaconsola,encontréestemensajedeerror:

  

Senegóamostrar' enlace ' en un marco porque configuró 'X-Frame-Options' en 'SAMEORIGIN'.

¿Por qué los navegadores deben aplicar una política del mismo origen en iframe s?

    
pregunta Krumia 22.09.2014 - 06:58
fuente

2 respuestas

39

Revisión: política del mismo origen

Primero, aclaremos que el comportamiento observado aquí (el iframe no se procesa) es mucho más estricto que la política predeterminada del mismo origen. Si ya lo entiende, vaya a " Lo que realmente está pasando ," a continuación.

Para revisar, la política del mismo origen evita que scripts tenga acceso programático al contenido de los recursos de origen cruzado. Considere cómo se aplica la política del mismo origen a varios tipos de recursos:

  • Imágenes: una etiqueta <img> mostrará visualmente una imagen de origen cruzado a un usuario, pero no permitirá que un script lea el contenido de la imagen cuando se carga en un <canvas> (es decir, toDataURL fallará si el lienzo contiene imágenes de origen cruzado)
  • Scripts: los scripts de origen cruzado se ejecutarán cuando se haga referencia en un elemento <script> , pero la página solo puede ejecutar el script, no leer su contenidos.
  • Iframe: Al igual que las imágenes, el contenido de una página de origen cruzado enmarcado aparece visualmente para el usuario, pero los scripts en la página de enmarcado exterior no tienen acceso al contenido de la página enmarcada.

La política del mismo origen se aplica a los iframes por el mismo motivo que se aplica a todos los demás tipos de recursos: la página web que se está enmarcando (o la imagen que se muestra, o el recurso al que se accede a través de Ajax) se obtiene utilizando las credenciales del origen propio del recurso (por ejemplo, la solicitud HTTP para obtener un recurso de google.com incluye el conjunto de cookies de mi navegador para google.com ). La página que emitió la solicitud no debe recibir acceso de lectura a un recurso recuperado con credenciales de un origen diferente.

Lo que realmente está sucediendo: Opciones de X-Frame

Sin embargo, el comportamiento que ve aquí es más estricto que la política del mismo origen: la página enmarcada no se muestra en absoluto . El servidor de origen cruzado que aloja la página enmarcada (posiblemente) solicita este comportamiento de bloqueo enviando un X-Frame-Options encabezado de respuesta , que especifica cómo se puede enmarcar la página.

  
  • NEGAR La página no se puede mostrar en un marco, independientemente del sitio que intente hacerlo.
  •   
  • SAMEORIGIN La página solo se puede mostrar en un marco en el mismo origen que la propia página.
  •   
  • ALLOW-FROM uri La página solo se puede mostrar en un marco en el origen especificado.
  •   

Aquí, el sitio envía X-Frame-Options: SAMEORIGIN , lo que significa que el sitio solo puede ser enmarcado por páginas con el mismo origen que la página enmarcada.

Desde un punto de vista de seguridad, esto se hace para evitar el clickjacking (también denominado ataque de "reparación de la interfaz de usuario") . En un ataque de clickjacking, la página muestra un componente activado por clic de otro sitio dentro de <iframe> y engaña al usuario para que haga clic en él (por lo general colocando el componente objetivo en la parte superior de una característica aparentemente pulsable del sitio de encuadre).

Para un ejemplo trivial, un sitio puede colocar un <iframe> de http://security.stackexchange.com transparente para que el enlace de "cierre de sesión" en el sitio enmarcado esté directamente sobre el botón "Haga clic aquí para reclamar su dinero gratis". Al ver la página de marcos, el usuario intenta reclamar el dinero gratis y, de repente, se desconecta de Stack Exchange. Cuando http://security.stackexchange.com envía un encabezado X-Frame-Options: SAMEORIGIN , la página de origen cruzado malicioso obtiene solo un <iframe> vacío; el usuario no hace clic de forma involuntaria en un enlace de cierre de sesión porque ningún contenido del sitio enmarcado llegó a la página representada.

OWASP tiene una página que detalla defensas contra clickjacking .

    
respondido por el apsillers 22.09.2014 - 15:26
fuente
38

Los administradores de security.stackexchange.com han configurado el sitio para que no quede enmarcado en otros sitios. Esto generalmente se hace para evitar ataques de clickjacking, para evitar que otros integren security.stackexchange.com en una página llena de anuncios, y para guardar tráfico. Puede leer más sobre X-Frame-Options header aquí .

Esta protección está desactivada de forma predeterminada.

    
respondido por el abacabadabacaba 22.09.2014 - 07:06
fuente

Lea otras preguntas en las etiquetas