Iframe postmessage fraudes

Question

Iframe postmessage fraudes

#1 de SilverlightFox (1 votos)

1

He revisado algunos materiales aquí y en otros sitios relacionados con el uso seguro de Window.postMessage. Hay un montón de material relacionado con las mejores prácticas, pero una de mis preguntas sigue sin respuesta.

Por lo que pude entender, la información se intercambia entre los iframes mediante las API internas del navegador, sin ninguna comunicación de red. En otras palabras, incluso si los dos iframes que intercambian información entre ellos están alojados en dos servidores diferentes originados en dos dominios diferentes, no veré ningún intercambio de tráfico entre estos dos servidores cuando se publiquen mensajes. Antes de implementar esto en mi sitio web, solo quiero estar seguro - ¿Cómo valida el navegador el origen del mensaje publicado? ¿Hay alguna forma en que un atacante pueda "falsificar" un mensaje y hacer que parezca que se originó en un iframe legítimo? Supongo que la respuesta es no porque eso requeriría una ingeniería inversa del navegador y la exposición de sus API internas, pero solo quiero asegurarme de que mi comprensión es correcta.

Gracias de antemano

web-application appsec crossdomain html-5

pregunta user3074662 21.12.2014 - 21:25

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application appsec crossdomain html-5

ARP - reenviar o soltar con IPtables ¿Pueden las carpetas [solas] tener virus?

score 1 · Accepted Answer

Si se falsificó origin en este contexto, esto se reduciría a una falla en el navegador en particular que había sido explotado. Ha habido fallas en el pasado, como esta en Safari .

Entonces, suponiendo que el usuario utiliza un navegador completamente parcheado y no existen fallas de día cero (!), su método de verificación de origin no se puede falsificar dentro del navegador cuando se reciben postMessage events.

Al final del día, tiene que confiar en que el navegador se comporta como se espera para mantener el extremo del lado del cliente de su seguridad. Sí, un usuario malintencionado podría hacer que su navegador falsifique el origin , sin embargo, si no pueden atacar a otros usuarios o al sistema mismo al hacerlo y solo podrían atacarse a sí mismos, debería estar seguro. Por supuesto, no debe usar el valor origin para verificar las cosas en las que un usuario malintencionado puede obtener una ventaja mediante la suplantación de identidad: solo debe usar este valor para verificar que una sesión de usuario no está siendo atacada, y no como un medio de validación Las acciones del usuario. Esta es la misma razón por la que no debería tener la validación del lado del cliente solo para los formularios web, ya que el propio usuario puede omitirla.

Para resumir, en tu escenario deberías poder confiar en el origin del evento postMessage .