7

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.

  1. Is it possible to open it in a completely new browser and still have no security issues?
  2. What are the things we should keep in mind to make sure our site remains secure while using iframes?
makerofthings7
  • 50,488
  • 54
  • 253
  • 542
Mick
  • 71
  • 1
  • 1
  • 2
  • 3
    What are the technical reasons? Why would you leave that out? – rook Apr 01 '12 at 06:24
  • 3
    Please give some more details on your first question. It is rather unclear what you mean. – Hendrik Brummermann Apr 01 '12 at 09:21
  • Welcome secuirty.se, make sure to post enough information for people to actually answer your question. – rook Apr 01 '12 at 16:33
  • @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. – Mick Apr 02 '12 at 03:51

4 Answers4

5

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.

Hendrik Brummermann
  • 27,158
  • 6
  • 80
  • 121
  • Hmm, yeah see mentioning the origin inheritance rules is pretty pretty important, because iframe's can be used as a security measure. Also old browsers are probably hacked to tears anyway. – rook Apr 01 '12 at 16:32
4

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.

Community
  • 1
rook
  • 47,004
  • 10
  • 94
  • 182
4

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).

makerofthings7
  • 50,488
  • 54
  • 253
  • 542
1

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).

vizzdoom
  • 177
  • 4