Labs/Ubiquity/Secure Coding Practices

From MozillaWiki
< Labs‎ | Ubiquity
Revision as of 15:32, 13 March 2009 by Varmaa (talk | contribs) (Origination)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Back to Labs/Ubiquity.

For Command Authors

If at all possible, see if you can implement your command using a Locked-Down Feed. Not only does it make it harder for any coding mistakes to accidentally harm the user, but it also makes it easier for the end-user to subscribe to, since they're not presented with a big warning of doom.

If you use a regular feed, we recommend using the CmdUtils.safePreview() function to display any untrusted HTML content to the end-user. If you don't do this and just inject untrusted HTML into the DOM node your preview function is given, then this code will run in a trusted context, which means that malicious or misbehaving code in the HTML can do whatever it wants to your computer.

Even when you inject untrusted text into a trusted context, make sure it's properly escaped with Utils.escapeHtml(), or else the text could be carefully constructed to execute malicious code. Another alternative is to set an element's text contents using jQuery's text() method.

For Core Developers

Check out the Cross-Site Scripting Prevention Cheat Sheet Cross-Site Scripting Prevention Cheat Sheet. Ubiquity's chrome:// pages—even the ones that just look like web pages—run in a trusted context, but they sometimes display untrusted content, such as text metadata for a Locked-Down feed; therefore we need to make sure that we're escaping the data properly. The stakes here are higher than they are for XSS attacks because rather than the attacker gaining control of a user's web experience on a single domain, they gain control of the user's entire computing experience.