We are looking to move to iframes due to technical challenges. By moving to iframes it will be easier to manage the technical issues. But we are not totally sure of security implications of iframes.
Our website is rendered through SSL and the user may need to click on the links also on SSL from our site.
Assuming the iframes have the same origin so that you do not have to remove the X-Frame-Options: sameorigin header, or that Clickjacking is not an issue in them. (There is a allow-from token specified, but older browsers don't support it).
The main remaining issue with using frame is, that you might end up displaying untrusted content, while the user still sees your domain in the address bar. For example there may be a link that is missing the target="_top" attribute or you might want to display foreign content intentionally.
This foreign content may for example display a form "Your session has expired, please login again" with your layout. The address bar will show your domain.
A common security concern with iframes is clickjacking. This issue is commonly mitigated using the x-frame-options http response header. It is important to limit what pages can be iframe'ed. Pages that allow the user to change their password, modify settings should be limited have an x-frame-option of "deny".
There are major security befits from using an iframe. For example Google+ buttons rely upon the origin inheritance rules for iframe's for security.
iFrames can introduce many security issues depending on how they are implemented and where the content is being served.
Here are some details on iFrame options mentioned by Rook
allow-forms
If this is enabled, iFrames could phish for information, pose as a login form for your website etc.
allow-scripts If allow scripts is enabled, then there is no point in setting allow-forms, since a form can be created in the DOM by Javascript
If you allow scripts in an iFrame it could potentially perform DoS attacks, open browser dialogs, or perform automation on the page that could expose information to others (referer attribute) or load external objects.
allow-top-navigation
This right allows the iFrame to act as the embedded site or or phish the users credentials.
allow-same-origin
This attribute is intended to display raw HTML documents (HTML email for example) unaltered from the source. The issue is that if the URL is predictable and the attacker can get the user to view the iFrame directly then the properties of the sandbox are lost. Worse still the opened web page might traverse the opener object and discover properties about the source page.
Finally, there is a propose MIME type called text/html-sandboxed for content that should always be viewed in a sandboxed environment, but many browsers misinterpret this and will display the data in unusual ways (usually a bad thing).
You should implement two things to secure that application:
1) Add X-frame-Option Headers ie in apache:
echo "Header always append X-Frame-Options SAMEORIGIN" >> /etc/apache2/httpd.conf && a2enmod headers && service apache2 restart
2) Add Framebusting Javascript code for old browsers.
Caution! if (_top == _self) is BAD Framebusting code!
Look here, there are many framebusting examples (OWASP Video).
