¿Cómo son los iframes vulnerables a los ataques?

1

He estado investigando mientras estoy buscando implementar un formulario en otro sitio web utilizando un iframe. Entiendo que un atacante puede cambiar el código fuente de un iframe para apuntar a un script, pero ¿cómo afectará esto a todos los demás? Seguro que es del lado del cliente y no del servidor.

Un artículo que leí sugería que los piratas informáticos podrían registrar golpes de tecla desde un error de IE, pero ¿eso significa modificaciones en el código del lado del servidor?

He habilitado el modo sandbox con sandbox="allow-forms allow-scripts" . ¿Es esto lo suficientemente seguro o debería adoptarse un enfoque diferente? .

    
pregunta bish 10.08.2016 - 11:46
fuente

2 respuestas

2
  

Un artículo que leí sugiere que los piratas informáticos podrán grabar la clave   trazos de un error de IE, pero seguramente eso significa modificaciones al   código del lado del servidor?

El error de IE al que creo que te refieres es mencionado aquí .

  

un atacante puede crear una página web en evil.com, que el atacante   controles, e incluir en la página de evil.com un marco visible que muestra   la página de inicio de sesión para example.com. El atacante puede ocultar el marco de   bordes y expanda el marco para cubrir toda la página, de modo que   mira al usuario del navegador como si él o ella realmente estuviera visitando   example.com El atacante registra algunos javascript en la principal   La página de evil.com que escucha todos los eventos clave de la página. Normalmente,   este oyente sería notificado de eventos solo desde el principal evil.com   página - pero debido a un error en el navegador, este oyente también recibe una notificación   de eventos de la página example.com de framed

Sin embargo, el usuario:

  1. Deben estar utilizando una versión vulnerable de Internet Explorer.
  2. Ya confíe en evil.com para ingresar sus credenciales para example.com . Es decir, evil.com podría estar mostrando algo que se parece a se parece a a la página de inicio de sesión de example.com en lugar de a un IFrame.
  

He habilitado el modo sandbox con sandbox="allow-forms allow-scripts".   ¿Es esto lo suficientemente seguro o debería adoptarse un enfoque diferente? .

El principal riesgo si el otro sitio web es malicioso o está comprometido, puede hacer lo que quiera solo dentro de IFrame . El atributo sandbox es ampliamente admitido , sin embargo, es posible que no desee escribir el IFrame en absoluto para los navegadores no compatibles. No está especificando allow-top-navigation por lo que no pueden redirigir al usuario.

La Same Origin Policy evitará que la página enmarcada manipule la suya. Supongo que el principal riesgo que está asumiendo es que el sitio podría intentar un exploit del navegador o un ataque entre dominios en otro sitio web (por ejemplo, XSS, CSRF) si envía al usuario a un sitio en el que no ha elegido confiar.

    
respondido por el SilverlightFox 11.08.2016 - 13:45
fuente
-1

No, esto no es lo suficientemente seguro.

  • Si no ha configurado el encabezado X-Frame-Options: SAMEORIGIN , su sitio puede mostrarse en un iframe. El hacker puede usar clickjacking: puede poner un iframe en el iframe y con una mezcla sutil de CSS y HTML , haga que el usuario haga clic en un botón que en realidad es un enlace del iframe de su sitio para ejecutar una acción con CSRF token en su sitio web.
  • Usando el hackeo de iframe, el hacker puede cambiar el tamaño del iframe para llenar toda la página. Puede insertar contenidos falsos, como una página de inicio de sesión falsa. El usuario pensará en una simple desconexión y un nuevo registro, dando sus registros al atacante.
respondido por el Xavier59 10.08.2016 - 12:07
fuente

Lea otras preguntas en las etiquetas