Labs/Ubiquity/Secure Coding Practices

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.

Escaping Text

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. For example:

CmdUtils.CreateCommand({
  ...
  preview: function preview(pblock, dobj) {
    // SECURITY RISK: Unescaped, untrusted text content.
    pblock.innerHTML = "<i>Your</i> direct object is " + dobj.text;
  }
  ...
});

Instead, use Utils.escapeHtml() on the text, like so:

CmdUtils.CreateCommand({
  ...
  preview: function preview(pblock, dobj) {
    // SECURITY RISK: Unescaped, untrusted text content.
    pblock.innerHTML = ("<i>Your</i> direct object is " +
                        Utils.escapeHtml(dobj.text));
  }
  ...
});

Another alternative is to set an element's text contents using jQuery's text() method.

Even though preview areas are now contained in their own content-space IFRAME element, this is still useful (and it also allows users to use symbols like '<' and '>' in their selections!).

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.