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?
The IE bug I believe you are referring to is mentioned here.
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
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
However, the user would:
- Have to be using a vulnerable version of Internet Explorer.
- Already be trusting
evil.com to enter their credentials for
example.com. That is,
evil.com could just as well be displaying something which looks like
example.com's login page rather than an IFrame.
I have enabled sandbox mode with sandbox="allow-forms allow-scripts".
Is this secure enough or should a different approach be taken? .
The main risk if the other website is malicious or compromised, then it can do what it wants within the IFrame only. The sandbox attribute is widely supported, however you may wish to not write the IFrame at all for unsupported browsers. You are not specifying
allow-top-navigation so they cannot redirect the user away.
The Same Origin Policy will prevent the framed page from manipulating yours. I guess the main risk you're taking is that the site could attempt a browser exploit or a cross-domain attack on another website (e.g. XSS, CSRF) by you sending the user to a site that they have not chosen to trust.