Examinemos cada caso desde la perspectiva de un activo atacante Malroy y un pasivo atacante Eve

Caso 1: una página insegura que carga un iframe seguro para transmitir datos confidenciales

Pasivo: Usted está seguro contra ataques pasivos mientras usa el iframe seguro. Sin embargo, en el caso de los iframes de inicio de sesión, si su token de sesión se envía de forma clara, Eve puede hacerse pasar por usted. (Todavía considero que la suplantación es "pasiva", ya que Eve no está manipulando su conexión de forma activa; solo está haciendo sus propias conexiones con la nueva información que aprendió).

Activo: Si la página HTML en sí misma es insegura, ya has perdido por completo. Puede hacer que cada sub-recurso en la página se transmita de manera segura, pero no importa: Malroy ya ha reescrito su página para usar recursos totalmente diferentes.

Caso 2: una página segura que carga una página insegura a través de un iframe

Pasivo: problema importante evidente aquí: cualquier cosa que haga en el iframe está a la vista. Sin embargo, Eve no puede ver lo que haces en la página segura de nivel superior. Aún así, el usuario se queda confundido acerca de qué elementos de la página pueden interactuar de forma segura y cuáles no.

Activo: Malroy puede hacer que cualquier cosa aparezca en el iframe; Espero que no lo estés usando para nada importante. No creo que Malroy pueda romper el iframe y leer o modificar su página externa segura, ya que los navegadores ya asumen que los iframes de origen cruzado no son confiables. Si hubiera una manera de romper el iframe, creo que se consideraría un error de seguridad grave en su navegador (lo que no quiere decir que no existan, pero eso es un problema de implementación, no un problema teórico con problemas mixtos). contenido).

Caso 3: una página segura que enlaza con JS inseguro

Pasivo: Eve puede aprender qué sitio HTTPS está viendo, según los recursos HTTP que cargue. (Concedido, ella podría ser capaz de hacer esto a través de una conexión segura, según la dirección IP de destino y el tamaño / patrón de los recursos cifrados que obtenga. En cualquier caso, HTTP solo le facilita las cosas).

Activo: Tal como lo has adivinado, Malroy puede hacer que tu página HTTPS se vuelva a escribir completamente y le envíe un script modificado.

Caso 4: una página segura que enlaza con fuentes inseguras como imágenes, CSS

Pasivo: igual que en el caso 3, arriba.

Activo: CSS es bastante poderoso. Si Malroy pudiera reescribir un recurso CSS, podría hacer una manipulación de presentación bastante pesada. Como ejemplo, quizás Malroy cambia el estilo de los campos de entrada de la página "Crear nuevo hilo" de un foro para que se vea como una página de inicio de sesión. Esto hace que el usuario piense que su sesión ha caducado, y él, sin saberlo, envía sus credenciales como una nueva publicación pública.

Un atacante activo también podría usar CSS para solicitar a un cliente que participe en un ataque CSRF, por ejemplo, utilizando background-image: url(http://www.bigbank.com/transfer?amt=1000000&to=malroy) .

Esta página tiene una excelente explicación y demostración: enlace

Si asume que el atacante puede cambiar las partes no encriptadas de una página, entonces podrá cambiarlas para que incluyan su propio formulario de inicio de sesión malicioso, en lugar del formulario de inicio de sesión seguro.

Una posibilidad que me viene a la mente es el secuestro de sesiones. Si la cookie de sesión, por ejemplo, se transfiere de una manera no segura, entonces esto podría tener un alto jacked.