Solución:
los IFRAME elemento puede ser un riesgo de seguridad si su sitio está incrustado dentro de un IFRAME en sitio hostil. Google “clickjacking” para obtener más detalles. Tenga en cuenta que no importa si usted usar <iframe> o no. La única protección real contra este ataque es agregar un encabezado HTTP X-Frame-Options: DENY y espero que el navegador sepa su trabajo.
Además, El elemento IFRAME puede ser un riesgo para la seguridad si alguna página de su sitio contiene una vulnerabilidad XSS que puede explotarse. 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 un <iframe> en la 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 ejecutar JavaScript en el documento “host”). El único método de protección real contra este ataque es agregar un encabezado HTTP X-Frame-Options: DENY y / o codifique siempre correctamente todos los datos enviados por el usuario (es decir, nunca tenga 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 usa un iframe grande con todo el contenido real), entonces 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 pudo 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 a pesar de que proviene de un dominio hostil que solicita credenciales de usuario.
Si alguien afirma que usando 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. Seguridad de <iframe src="https://foroayuda.es/..."> la etiqueta es igual a <img src="https://foroayuda.es/..." o <a href="https://foroayuda.es/..."> siempre que no haya vulnerabilidades en el navegador. Y si hay una vulnerabilidad adecuada, es posible activarla incluso sin usar <iframe>, <img> o <a> elemento, por lo que no vale la pena considerarlo para este problema.
Sin embargo, ser advertido de que el contenido de <iframe> puede iniciar la navegación de nivel superior de forma predeterminada. Es decir, contenido dentro del <iframe> tiene permitido 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 sandbox atributo 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 la zona de pruebas 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: DENY también protege del ataque de canal lateral de rendimiento de renderizado que puede leer contenido de origen cruzado (también conocido como “Ataques de sincronización perfecta de píxeles”).
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.
Supongo que el 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 de 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