https login iframe 2014

0

Según las recomendaciones de seguridad actuales y amp; Compatibilidad con el navegador, ¿está bien tener un iframe https en un conjunto de páginas que de otra manera solo http?

¿Esto no es un dupe? Lo es, pero quiero tendencias actuales porque cuando probé hace unos meses, los navegadores me advirtieron sobre contenido mixto, pero ahora cuando hago un iframe de una página de inicio de sesión segura de mi propio dominio, no recibo ninguna advertencia. (La URL es a.com pero apunta a mi propio host local, la url principal nos http://a.com/ , que tiene un iframe que proviene de https://a.com/login )

Supongo que es porque https no tiene la culpa y fue JavaScript lo que condujo a las vulnerabilidades y ahora está solucionado.

Probado en FF 31, Chrome 36, IE 9

Lo vi:

Comprendí que el riesgo es que el usuario podría tener un programa malicioso adicional que cambie la fuente del iframe. Si la computadora del usuario está tan gravemente comprometida, ¿no son todas las apuestas de todos modos?

¿Debemos decirle a nuestro cliente, incluso en 2014, que no haya https login iframe? Si el usuario desea iniciar sesión, actualice la página a la versión https o redirija al usuario a otra página de inicio de sesión y el inicio de sesión posterior puede volver a http en las áreas seguras (no relacionadas con el pago y relacionadas con la cuenta).

Sé que no es una cosa muy computacional, pero por alguna razón, el cliente se fija en la idea de que algunas páginas son mejores http o https (http predeterminado, aunque el usuario puede cambiar a ssl manualmente)

    
pregunta tgkprog 26.08.2014 - 14:47
fuente

2 respuestas

2

enlace no ayudará contra MITM activo .

Es posible que se hayan cerrado las vulnerabilidades de js, pero el problema persiste , ya que el html principal (que se sirve a través de http) aún puede modificarse, incluida la url del iframe. Luego, el MITM puede configurar la página de inicio de sesión a través de http y será cargada por los usuarios específicos. Solo los usuarios que utilizan un administrador de contraseñas notarán el cambio, ya que los administradores de contraseñas tratan los https y http urls como orígenes diferentes. Esto no es nada que los proveedores de navegadores puedan solucionar .

Por ejemplo, en lugar de servir

<iframe src="https://site.example/login.php"name="login_frame">

el atacante MITM puede servir

<iframe src="http://site.example/login.php"name="login_frame">

y sirve una página de inicio de sesión interceptada en la página http.

Y javascript, como se describe en anwser original , todavía puede acceder a los atributos de iframe. Pruébelo usted mismo: enlace

    
respondido por el user10008 26.08.2014 - 15:08
fuente
1

Por lo que sé, los iframe siempre son vulnerables al Clickjacking.

Esta es una razón importante por la que el sitio web no debe iniciar sesión en un iframe y por qué necesita el encabezado X-Frame-Options o ahora antepasados de marcos en tu página de inicio de sesión.

También, como se mencionó en su publicación y que responde , el contenido de la página http puede interceptarse y Cambiado por un hombre en el medio. Dado que MitM puede cambiar la url del iframe, ahora eres vulnerable al ataque de phishing.

    
respondido por el Gudradain 26.08.2014 - 17:44
fuente

Lea otras preguntas en las etiquetas