I figured clients like Gmail.com and Outlook.com would put emails into an iframe for extra security, but it turns out they sanitize heavily with something like Caja.

But is there any particular reason they wouldn't use iframes, which would at least help sandbox it a bit?

(Caja, for example, had a vulnerability found just a few months ago - and I think this vulnerability may have been mitigated by placing emails into an iframe)

  • Do you know if open source web mail (e.g. RoundCube) does this? It might be worth asking on the RoundCube developers mailing list - there may be good reasons. My guess is that iframes would cause some usability issues, e.g. the parent page wouldn't get click/select events. I expect they're pretty confident in their sanitiser too. Making loads of effort with the sanitiser on their side, for a minor usability improvement on the user's side is very much in line with Google's approach to development. – paj28 Aug 22 '16 at 15:08

TL;DR iframe cannot replace sanitization completely, but is a great feature to use as security in-depth. Unfortunately, it does get in the way of some user-friendliness features.

I would be interesting in hearing a more informed answer, but I'm going to post some points I'm aware of.

Same Origin Policy works both ways. It's great that it keeps the iframe from seeing the outer document content. Unfortunately, if you select text, the outer document cannot tell what text was selected in the iframe. (thanks @paj28) Once could use postMessage feature by adding script to the inner page to work around this, but it is inconvenient. Furthermore, this will not work if you use iframe sandbox as a way to disable scripts. (which I would highly recommend)

You will want to use Content Security Policy (again, thanks @paj28) to disable beacons within the iframed content; and also to disable scripts and other potential issues.

I'd like to point out that iframe as originally designed is not complete. The sandbox attribute would be must if you have any doubt in your sanitization. Unfortunately, the sandbox feature was only recently implemented. This is of diminishing significance as older browsers start to drop off the charts.

Disabling scripts would get in the way of user-friendliness features anyway such as detecting selected text. (It is possible you could get away with 'disable scripts and treat as same origin' rule of sandbox, but that seems risky.)

Any time you add your own scripts or interactive functionality to the iframe'd document, you will be much safer if you still sanitize that document. While iframe sandbox combined with CSP may cover you completely, there might be something missing from that formula.

So in summary

  • For browsers that don't support sandbox, the iframe mitigates significant security risks, but is unable to protect against many issues. Content Security Policy might be able to isolate the content, to a great extent. But you still need to sanitize to prevent things like <a target="_top".

  • For browsers that do support sandbox, combined with a good Content Security Policy, you might be able to replace sanitization, but it is not advisable because it is hard to know for sure whether you are 100% secure. (sanitization routines on the other hand are older and better vetted)

  • If you have sanitization (which you probably should), and the sanitation is well vetted, then iframes only get in the way of user-friendliness. On the other hand, if a flaw is discovered in your sanitization, then you will be glad you iframed the content, using the sandbox attribute and CSP to reduce the scope of the attack.

Side note: desktop applications have more liberty in sandboxing their webviews, even better than the iframe sandbox attribute. So, for example, the Android apps could benefit.

  • 1
    Thanks for the mention :) You can disable beacons using CSP which is widely supported. – paj28 Aug 22 '16 at 20:16
  • I've updated my answer. I wonder if CSP and iframe sandbox have the potential to eliminate the need for sanitization. Not recommended, but an interesting question. – Bryan Field Aug 22 '16 at 20:39
  • 1
    It can, and CSP has its own iframe sandbox directive. But as you say it's not recommended and the standard says "CSP is best used as defense-in-depth, to reduce the harm caused by content injection attacks" – paj28 Aug 22 '16 at 21:09
  • If you compare sandbox support and CSP support browsers tend to support Sandbox before CSP. I was hoping the answer to the question was "because a CSP was used instead with no inline scripts", but just checking Google's now I see 'unsafe-inline' 'unsafe-eval' for script-src which is slightly worrying. – SilverlightFox Aug 23 '16 at 8:54
  • A far more indepth awnser than I supplied. Well done. – LvB Aug 23 '16 at 9:13

In order to serve any content within an iFrame, Google would need to disable some of the site's existing framebreaker scripts (which Google would have added as a mitigation against clickjacking for older web clients).

I imagine that Google determined that the risk of disabling the framebreaker scripts would be greater than the reward of rendering the content in an iFrame.

  • This is not relevant to the question. If you serve an email in an iframe or not, you still have to disable scripts. Actually serving in an iframe makes security life easier, not harder. – Bryan Field Aug 22 '16 at 19:26
  • I don't think you fully understand my answer. Google will have to disable its own framebreak scripts, i.e. the ones that Google engineers write and add to their web site in order to protect older browsers against clickjacking. I am not talking about scripts in the email itself. – John Wu Aug 22 '16 at 19:37
  • "Google will have to disable its own framebreak scripts" Piece of cake. Do you realize that framebreak scripts are not site-wide, but served on a per-page basis? – Bryan Field Aug 22 '16 at 19:47
  • Yes, I understand it can be done. What I am saying is that maybe they decided it should not be done. Imagine, for example, if a malicious party found a way to display your personal email content within their own iFrame. – John Wu Aug 22 '16 at 19:48
  • For this 'one page' that is iframed; using a CSRF prevention token and/or checking the HTTP Referer (or newer Origin header) would be a better solution than a framebreak script. So I still say piece of cake. – Bryan Field Aug 22 '16 at 20:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.