An article I read suggested that hackers will be able to record key
strokes from an IE bug, but surely that means modifications to the
server side code?
Il bug di IE credo che tu ti stia riferendo a menzionato qui .
an attacker may create a web page at evil.com, which the attacker
controls, and include on the evil.com page a visible frame displaying
the login page for example.com. The attacker can hide the frame's
borders and expand the frame to cover the entire page, so that it
looks to the browser user like he or she is actually visiting
example.com The attacker registers some javascript in the main
evil.com page which listens for all key events on the page. Normally,
this listener would be notified of events only from the main evil.com
page -- but because of the browser bug, this listener is notified also
of events from the framed example.com page
Tuttavia, l'utente:
- Utilizzare una versione vulnerabile di Internet Explorer.
- Già fidarti di
evil.com per inserire le loro credenziali per example.com . Cioè, evil.com potrebbe anche mostrare qualcosa che assomiglia alla % pagina di login diexample.com piuttosto che a un IFrame.
I have enabled sandbox mode with sandbox="allow-forms allow-scripts".
Is this secure enough or should a different approach be taken? .
Il rischio principale se l'altro sito Web è dannoso o compromesso, allora può fare ciò che desidera solo nell'IFrame . L'attributo sandbox è ampiamente supportato , tuttavia potresti non voler scrivere l'IFrame per i browser non supportati. Non stai specificando allow-top-navigation in modo che non possano reindirizzare l'utente.
La Stessa politica di origine impedirà alla pagina con cornice di manipolare la tua. Immagino che il rischio principale che stai prendendo è che il sito potrebbe tentare un exploit del browser o un attacco interdominio su un altro sito Web (ad esempio XSS, CSRF) inviando l'utente a un sito che non ha scelto di fidarsi.