Gaia/Email/Implementation/MessageDisplayAndAttachments: Difference between revisions

← Older edit

Gaia/Email/Implementation/MessageDisplayAndAttachments (view source)

Revision as of 20:43, 13 May 2013

1,223 bytes added , 13 May 2013

no edit summary

Andrew Sutherland

Confirmed users

360

edits

@@ Line 111: / Line 111: @@
 === HTML Security ===
-We use an HTML sanitizer with a white-list to only allow 'safe' HTML through, but are backstopped by an iframe sandbox and our app's CSP (Content Security Policy).  Unfortunately, there is currently no equivalent of gecko's nsIContentPolicy for iframe sandboxes, although there is interest among the security team in trying to standardize such a feature.  We are also limited by our need to meddle with the HTML of the
+We use an HTML sanitizer with a white-list to only allow 'safe' HTML through, but are backstopped by the HTML "iframe" tag sandbox attribute and our app's CSP (Content Security Policy).  Unfortunately, there is currently no equivalent of gecko's nsIContentPolicy for iframe sandboxes to allow us to forbid network access.  (Although there is interest among the security team in trying to standardize such a feature.)
+Because of this, our sanitizer has to render tags/style inert that would otherwise trigger network fetches.  This in turn means that in order for us to later "activate" them, we need to manipulate the DOM or entirely re-write the document from scratch.  The activation technique requires that the page live in our origin so we can manipulate it.  (Unlike Firefox and Thunderbird code which run with chrome privileges, allowing them to manipulate the contents of displayed pages, the e-mail app runs with standard content privileges, so we would be just as privileged as the displayed e-mail or any otherw website.)  This in turn means that the e-mail is affected by our CSP.  Re-writing the document would have layout impact as well as requiring us to have an efficient way to produce both an inert and activated document.  (Store diff hunks?)
 This primarily means that we don't let through:
 * script: No JS!
+And we render inert, possibly by nuking:
+* img tags and style directives that could fetch remote images
+* external resources that aren't standard for HTML e-mails like remote styles, etc.
+* href attributes that might theoretically cause pre-fetches
+See [https://github.com/mozilla-b2g/gaia-email-libs-and-more/blob/master/data/lib/mailapi/htmlchew.js htmlchew.js] for more info.