¿Por qué los iframes se consideran peligrosos y un riesgo para la seguridad?
125
¿Por qué los iframes se consideran peligrosos y un riesgo para la seguridad? ¿Alguien puede describir un ejemplo de un caso en el que se pueda utilizar de forma maliciosa?
@Samich: no, se trata de las mejores prácticas, no específicamente de problemas de seguridad (y el único problema de seguridad en el que puedo pensar surge de terceros que usan iframes)
Quentin
No es tanto seguridad como no se considera la mejor práctica, consulte: stackoverflow.com/questions/1081315/why-developers-hate-iframes Fueron mucho más populares cuando las personas también diseñaron con tablas, los divs prácticamente eliminan la necesidad de iframes.
RandomUs1r
Curiosamente, apareció un artículo casi una década después que sugiere que poner cualquier cosa que contenga un formulario en un iframe, aislado de todos sus javascript de terceros, etc., es posiblemente necesario para evitar que los formularios sean recolectados. hackernoon.com/…
GordonM
Respuestas:
84
Tan pronto como muestre contenido de otro dominio, básicamente estará confiando en que ese dominio no distribuirá malware.
No hay nada de malo con los iframes per se. Si controlas el contenido del iframe, son perfectamente seguros.
Tan pronto como enlaza a contenido de otro dominio, etc., etc. No hay nada específico de iframe sobre esto.
Quentin
5
Un navegador implementado correctamente (también conocido como agente de usuario) no permitirá que el contenido del iframe se filtre fuera del iframe. Si el documento anfitrión (uno que contiene el <iframe>elemento) tiene un estilo adecuado y sugiere que el iframe contiene contenido que no es de confianza, no hay problema. Modulo de vulnerabilidades reales en el navegador, por supuesto. En resumen, an <iframe>es tan seguro como <a href>.
Mikko Rantalainen
2
¿Qué pasa con un iframe oculto que pertenece al mismo dominio? ¿Es esto totalmente seguro?
Ciaran Gallagher
2
El contenido oculto <iframe>del mismo dominio puede suponer un riesgo para la seguridad si el atacante puede modificar el contenido dentro del iframe oculto. Eso permitirá al atacante extender el ataque XSS dentro de lo oculto <iframe>a cualquier página de su sitio que se refiera a dicho <iframe>contenido. Consulte stackoverflow.com/a/9428051/334451 para obtener más detalles.
Mikko Rantalainen
Curiosamente, un iFrame podría ser una protección útil contra el caso inverso. Si tiene muchos scripts de terceros en su sitio, debe aislar los formularios de ellos. Una forma sugerida de hacerlo era colocar el formulario en su propia página mínima sin javascript de terceros y mostrarlo en un iframe en la página de host. hackernoon.com/…
GordonM
140
El IFRAMEelemento puede ser un riesgo de seguridad si su sitio está incrustado dentro de un IFRAMEsitio hostil . Google "clickjacking" para más detalles. Tenga en cuenta que no importa si lo usa <iframe>o no. La única protección real contra este ataque es agregar un encabezado HTTP X-Frame-Options: DENYy esperar que el navegador sepa su trabajo.
Además, el elemento IFRAME puede representar un riesgo para la seguridad si alguna página de su sitio contiene una vulnerabilidad XSS que se puede aprovechar . En ese caso, el atacante puede expandir el ataque XSS a cualquier página dentro del mismo dominio que pueda ser persuadido para que cargue dentro de una <iframe>página con vulnerabilidad XSS. Esto se debe a que el contenido del mismo origen (mismo dominio) puede acceder al DOM de contenido principal (prácticamente ejecuta JavaScript en el documento "host"). El único método de protección real contra este ataque es agregar un encabezado HTTP X-Frame-Options: DENYy / o codificar siempre correctamente todos los datos enviados por el usuario (es decir, nunca tener una vulnerabilidad XSS en su sitio, es más fácil decirlo que hacerlo).
Ese es el aspecto técnico del problema. Además, está el problema de la interfaz de usuario. Si les enseña a sus usuarios a confiar en que se supone que la barra de URL no cambia cuando hacen clic en los enlaces (por ejemplo, su sitio utiliza un iframe grande con todo el contenido real), los usuarios no notarán nada en el futuro tampoco en el caso de la seguridad real. vulnerabilidad. Por ejemplo, podría tener una vulnerabilidad XSS dentro de su sitio que le permita al atacante cargar contenido de una fuente hostil dentro de su iframe. Nadie podría notar la diferencia porque la barra de URL todavía se ve idéntica al comportamiento anterior (nunca cambia) y el contenido "parece" válido aunque sea de un dominio hostil que solicita credenciales de usuario.
Si alguien afirma que usar un <iframe>elemento en su sitio es peligroso y causa un riesgo de seguridad, no comprende qué <iframe>elemento lo hace, o está hablando de la posibilidad de <iframe>vulnerabilidades relacionadas en los navegadores. La seguridad de la <iframe src="...">etiqueta es igual <img src="..."o <a href="...">siempre que no haya vulnerabilidades en el navegador. Y si hay una vulnerabilidad adecuada, podría ser posible activarla incluso sin usar <iframe>, <img>o <a>elemento, por lo que no vale la pena considerarlo para este problema.
Sin embargo, tenga en cuenta que el contenido de <iframe>puede iniciar la navegación de nivel superior de forma predeterminada . Es decir, el contenido dentro del <iframe>puede abrir automáticamente un enlace sobre la ubicación de la página actual (la nueva ubicación será visible en la barra de direcciones). La única forma de evitarlo es agregar sandboxatributos sin valor allow-top-navigation. Por ejemplo <iframe sandbox="allow-forms allow-scripts" ...>,. Desafortunadamente, sandbox también deshabilita todos los complementos, siempre. Por ejemplo, el contenido de Youtube no se puede guardar en un espacio aislado porque todavía se requiere Flash Player para ver todo el contenido de Youtube. Ningún navegador admite el uso de complementos y no permite la navegación de nivel superior al mismo tiempo.
Tenga en cuenta que X-Frame-Options: DENYtambién protege contra el rendimiento de procesamiento de ataques de canal lateral que pueden leer contenido de origen cruzado (también conocido como " Ataques de sincronización perfecta de píxeles ").
Bien, pero ¿no "This is because content from the same origin (same domain) is allowed to access the parent content DOM (practically execute JavaScript in the "host" document)."debería reformularse en la dirección del documento (padre) que contiene una vulnerabilidad XSS al documento (hijo) en el iframe?
Shuzheng
@Shuzheng, la vulnerabilidad es en ambos sentidos y, si la usa <iframe>en una página, permite extender la vulnerabilidad desde el contenido dentro del iframe al documento anfitrión. La pregunta era sobre <iframe>ser peligroso y si el documento anfitrión tiene vulnerabilidad XSS, realmente no necesita el <iframe>elemento.
Mikko Rantalainen
13
Asumo un iFrame entre dominios, ya que presumiblemente el riesgo sería menor si lo controlara usted mismo.
Clickjacking es un problema si su sitio está incluido como un iframe
Un iFrame comprometido podría mostrar contenido malicioso (imagine que el iFrame muestra un cuadro de inicio de sesión en lugar de un anuncio)
Un iframe incluido puede hacer ciertas llamadas JS como alerta y aviso que podrían molestar a su usuario
Un iframe incluido puede redirigir a través de location.href (vaya, imagina un marco 3p que redirige al cliente de bankofamerica.com a bankofamerica.fake.com)
El malware dentro del marco 3p (java / flash / activeX) podría infectar a su usuario
"Peligroso" y "Riesgo de seguridad" no son las primeras cosas que vienen a la mente cuando las personas mencionan iframes ... pero pueden usarse en ataques de secuestro de clics .
Respuestas:
Tan pronto como muestre contenido de otro dominio, básicamente estará confiando en que ese dominio no distribuirá malware.
No hay nada de malo con los iframes per se. Si controlas el contenido del iframe, son perfectamente seguros.
fuente
<iframe>elemento) tiene un estilo adecuado y sugiere que el iframe contiene contenido que no es de confianza, no hay problema. Modulo de vulnerabilidades reales en el navegador, por supuesto. En resumen, an<iframe>es tan seguro como<a href>.<iframe>del mismo dominio puede suponer un riesgo para la seguridad si el atacante puede modificar el contenido dentro del iframe oculto. Eso permitirá al atacante extender el ataque XSS dentro de lo oculto<iframe>a cualquier página de su sitio que se refiera a dicho<iframe>contenido. Consulte stackoverflow.com/a/9428051/334451 para obtener más detalles.El
IFRAMEelemento puede ser un riesgo de seguridad si su sitio está incrustado dentro de unIFRAMEsitio hostil . Google "clickjacking" para más detalles. Tenga en cuenta que no importa si lo usa<iframe>o no. La única protección real contra este ataque es agregar un encabezado HTTPX-Frame-Options: DENYy esperar que el navegador sepa su trabajo.Además, el elemento IFRAME puede representar un riesgo para la seguridad si alguna página de su sitio contiene una vulnerabilidad XSS que se puede aprovechar . En ese caso, el atacante puede expandir el ataque XSS a cualquier página dentro del mismo dominio que pueda ser persuadido para que cargue dentro de una
<iframe>página con vulnerabilidad XSS. Esto se debe a que el contenido del mismo origen (mismo dominio) puede acceder al DOM de contenido principal (prácticamente ejecuta JavaScript en el documento "host"). El único método de protección real contra este ataque es agregar un encabezado HTTPX-Frame-Options: DENYy / o codificar siempre correctamente todos los datos enviados por el usuario (es decir, nunca tener una vulnerabilidad XSS en su sitio, es más fácil decirlo que hacerlo).Ese es el aspecto técnico del problema. Además, está el problema de la interfaz de usuario. Si les enseña a sus usuarios a confiar en que se supone que la barra de URL no cambia cuando hacen clic en los enlaces (por ejemplo, su sitio utiliza un iframe grande con todo el contenido real), los usuarios no notarán nada en el futuro tampoco en el caso de la seguridad real. vulnerabilidad. Por ejemplo, podría tener una vulnerabilidad XSS dentro de su sitio que le permita al atacante cargar contenido de una fuente hostil dentro de su iframe. Nadie podría notar la diferencia porque la barra de URL todavía se ve idéntica al comportamiento anterior (nunca cambia) y el contenido "parece" válido aunque sea de un dominio hostil que solicita credenciales de usuario.
Si alguien afirma que usar un
<iframe>elemento en su sitio es peligroso y causa un riesgo de seguridad, no comprende qué<iframe>elemento lo hace, o está hablando de la posibilidad de<iframe>vulnerabilidades relacionadas en los navegadores. La seguridad de la<iframe src="...">etiqueta es igual<img src="..."o<a href="...">siempre que no haya vulnerabilidades en el navegador. Y si hay una vulnerabilidad adecuada, podría ser posible activarla incluso sin usar<iframe>,<img>o<a>elemento, por lo que no vale la pena considerarlo para este problema.Sin embargo, tenga en cuenta que el contenido de
<iframe>puede iniciar la navegación de nivel superior de forma predeterminada . Es decir, el contenido dentro del<iframe>puede abrir automáticamente un enlace sobre la ubicación de la página actual (la nueva ubicación será visible en la barra de direcciones). La única forma de evitarlo es agregarsandboxatributos sin valorallow-top-navigation. Por ejemplo<iframe sandbox="allow-forms allow-scripts" ...>,. Desafortunadamente, sandbox también deshabilita todos los complementos, siempre. Por ejemplo, el contenido de Youtube no se puede guardar en un espacio aislado porque todavía se requiere Flash Player para ver todo el contenido de Youtube. Ningún navegador admite el uso de complementos y no permite la navegación de nivel superior al mismo tiempo.Tenga en cuenta que
X-Frame-Options: DENYtambién protege contra el rendimiento de procesamiento de ataques de canal lateral que pueden leer contenido de origen cruzado (también conocido como " Ataques de sincronización perfecta de píxeles ").fuente
"This is because content from the same origin (same domain) is allowed to access the parent content DOM (practically execute JavaScript in the "host" document)."debería reformularse en la dirección del documento (padre) que contiene una vulnerabilidad XSS al documento (hijo) en el iframe?<iframe>en una página, permite extender la vulnerabilidad desde el contenido dentro del iframe al documento anfitrión. La pregunta era sobre<iframe>ser peligroso y si el documento anfitrión tiene vulnerabilidad XSS, realmente no necesita el<iframe>elemento.Asumo un iFrame entre dominios, ya que presumiblemente el riesgo sería menor si lo controlara usted mismo.
fuente
"Peligroso" y "Riesgo de seguridad" no son las primeras cosas que vienen a la mente cuando las personas mencionan iframes ... pero pueden usarse en ataques de secuestro de clics .
fuente
iframe también es vulnerable a Cross Frame Scripting:
fuente