¿Es seguro proporcionar mis datos a través de un iframe, si la página en el iframe está protegida con SSL? [duplicar]

Es un mal diseño y la página completa debe usar HTTPS, ya que esto capacita a los usuarios en la práctica insegura de confiar y enviar información privada a través de HTTP. Sería trivial para un atacante hombre-en-el medio alterar la página HTTP externa para no usar el iframe HTTPS correcto, sino un iframe controlado por el atacante (posiblemente HTTPS para un dominio controlado por el atacante).

Por lo tanto, debe verificar el código fuente del iframe cada vez que envíe datos privados (ya que no hay garantías de que la primera vez que lo inspeccionó estuvo bien, pero la próxima vez fue modificado por un manipulador de HTTP).

Además, a medida que la página se carga a través de HTTP, un atacante MITM podría insertar y ejecutar cualquier javascript que desee en la página externa (y ocultar estas modificaciones en un script confuso que se carga externamente). Podrían dejar el iframe original con la URL https correcta si hiciera clic en la fuente de vista de la página HTML, pero en javascript podrían ocultar o reemplazar ese iframe con elementos DOM maliciosos que parecen idénticos (pero filtrar sus detalles al atacante). Este es un problema menor con un inspector de DOM interactivo en las herramientas de desarrollo modernas (que muestra el DOM tal como existe actualmente, por lo que debería ser capaz de inspeccionar el iframe), pero nuevamente esto requiere mucho trabajo de verificación para cada usuario que quiera para enviar datos de forma segura.

Dado que el iframe está sobre HTTPS pero la página web principal es HTTP; este sería un contenido mixto, pero los navegadores solo darían una advertencia si el contenido HTTP está incrustado en una página protegida con SSL, y no al revés, como sucede en este caso.

Todavía es una combinación insegura, ya que la página principal podría comunicarse con el contenido del iframe a través de la llamada a la API HTML postMessage. En este escenario de dominios cruzados, esto solo funciona si el documento en el iframe acepta y responde a estas consultas basadas en mensajes desde la página principal. Consulte este ejemplo . Aquí hay otro ejemplo que muestra a los desarrolladores cómo evitar este cruce. seguridad del dominio incorporando iframes de la página principal dentro del propio iframe, por lo que es un hack que puede no durar mucho tiempo, ya que los navegadores se actualizan con el tiempo y solucionan estos vacíos.

El único problema que veo aquí es que si se intercambian datos entre la página HTTP principal (no segura) y la página de pago seguro HTTPS, entonces ¿qué tan sensible es y qué tan bien está protegida cuando se transfiere al dominio HTTP no seguro? .

Pero, de nuevo, este tipo de problema es válido en cualquier lugar en que una aplicación web pasa la sesión / transacción del usuario a otra aplicación web, independientemente de si los iframes están involucrados o no. Como usuarios finales, no sabemos el tipo de comunicación que ocurre entre bambalinas entre diferentes proveedores de servicios al completar una transacción. Estos son el tipo de comprobaciones que PCI-DSS y otros deben validar.

Le sugiero que confíe en ellos si ambos servidores pertenecientes a las páginas HTTP y HTTPS pertenecen a la misma compañía de servicios de transmisión por secuencias.

No, no es seguro.

Si la página principal no está protegida con https, no hay garantía de que el usuario verá la URL de iframe de https correcta.

Un atacante puede realizar un ataque de hombre en el medio en la página principal y hacer que muestre un iframe en el sitio web del atacante. Dado que los navegadores no indican el estado de la URL o https de iframes, el usuario no sería más sabio si se comunican con alguien fraudulento.