Security issues using iframes
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.
- Is it possible to open it in a completely new browser and still have no security issues?
- What are the things we should keep in mind to make sure our site remains secure while using iframes?
Please give some more details on your first question. It is rather unclear what you mean.
Welcome secuirty.se, make sure to post enough information for people to actually answer your question.
@Rook and Hendrick - Currently we are using BHO/Extensions to connect to sharepoint and other SaaS application outside of our firewall. Its a homegrown system but to maintain the BHO/Ext is getting too much of a task. We were thinking iFrame would be a good alternative but are a bit vary of the security.
Assuming the iframes have the same origin so that you do not have to remove the
X-Frame-Options: sameoriginheader, 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
If this is enabled, iFrames could phish for information, pose as a login form for your website etc.
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.
This right allows the iFrame to act as the embedded site or or phish the users credentials.
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
openerobject and discover properties about the source page.
Finally, there is a propose MIME type called
text/html-sandboxedfor 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).
- Source(s) The Tangled Web
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
if (_top == _self)is BAD Framebusting code!
Look here, there are many framebusting examples (OWASP Video).