Confirmed users
360
edits
Gaia/Email/Implementation/MessageDisplayAndAttachments: Difference between revisions
Jump to navigation
Jump to search
Gaia/Email/Implementation/MessageDisplayAndAttachments (view source)
Revision as of 00:25, 11 May 2013
, 11 May 2013no edit summary
No edit summary |
No edit summary |
||
| Line 68: | Line 68: | ||
An e-mail message should never be able to take over your e-mail app or your computer. For traditional native e-mail clients, the original fear was just that a specially crafted e-mail could cause a buffer overflow, allowing the exploitation of the e-mail app and any privileges it might have. Now that mail apps are written using HTML and JS, there is the added risk of a mail message being able to gain access to those privileges. While the compromise of just the e-mail app is not as dramatic as complete compromise of the system it runs on, access to a user's private e-mail, passwords, etc. still constitutes a very serious breach. | An e-mail message should never be able to take over your e-mail app or your computer. For traditional native e-mail clients, the original fear was just that a specially crafted e-mail could cause a buffer overflow, allowing the exploitation of the e-mail app and any privileges it might have. Now that mail apps are written using HTML and JS, there is the added risk of a mail message being able to gain access to those privileges. While the compromise of just the e-mail app is not as dramatic as complete compromise of the system it runs on, access to a user's private e-mail, passwords, etc. still constitutes a very serious breach. | ||
The primary risk from our perspective is inserting attacker-controlled HTML code into our DOM, such as via innerHTML. The usual approaches for dealing with HTML are either to place the HTML in a sandbox where its privileges are limited and/or using some type of white-list based sanitization to only let things through that we know are safe. Capability-based privilege limitation is the preferred form of protection. That's how Thunderbird does it by default; it provides an nsIContentPolicy implementation that prevents messages from fetching remote resources (by default, this can be disabled or specific users white-listed) and forbids execution of JS code. Thunderbird also has some sanitizer logic, but it is only used when the "View..." "Message Body As..." "Simple HTML" option is used. | |||
== Implementation == | == Implementation == | ||
| Line 76: | Line 78: | ||
When rendering the message to the screen, we create separate div blocks for each run of lines of the same type and assign distinct CSS classes to those blocks. | When rendering the message to the screen, we create separate div blocks for each run of lines of the same type and assign distinct CSS classes to those blocks. | ||
Text messages | |||
=== HTML Message Display === | === HTML Message Display === | ||
| Line 104: | Line 108: | ||
This will require better heuristic handling on our part and the implementation of being able to save embedded images. | This will require better heuristic handling on our part and the implementation of being able to save embedded images. | ||
=== 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 | |||
This primarily means that we don't let through: | |||
* script: No JS! | |||