Labs/Ubiquity/Secure Coding Practices: Difference between revisions

Jump to navigation Jump to search

Labs/Ubiquity/Secure Coding Practices (view source)

Revision as of 00:16, 19 March 2009

1,238 bytes removed ,  19 March 2009
Removed section on untrusted HTML since it's no longer relevant
(added code examples)
(Removed section on untrusted HTML since it's no longer relevant)
 
Line 4: Line 4:


If at all possible, see if you can implement your command using a [[Labs/Ubiquity/Locked-Down_Feed_Tutorial|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 [[Media:Warning.PNG|warning of doom]].
If at all possible, see if you can implement your command using a [[Labs/Ubiquity/Locked-Down_Feed_Tutorial|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 [[Media:Warning.PNG|warning of doom]].
=== Untrusted HTML ===
If you use a regular feed, we recommend using the <tt>[https://ubiquity.mozilla.com/hg/ubiquity-firefox/raw-file/tip/ubiquity/index.html#feed-parts/header/cmdutils.js CmdUtils.safePreview()]</tt> 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.  For instance:
<pre>
CmdUtils.CreateCommand({
  ...
  preview: function preview(pblock) {
    Utils.previewGet(
      pblock,
      "http://www.example.com/somehtml",
      null,
      // SECURITY RISK: code injection vulnerability
      function(html) { pblock.innerHTML = html; },
      "html"
    );
  },
  ...
});
</pre>
The above code is bad because <code>pblock</code> is a trusted DOM node that's having untrusted HTML injected into it.  Wrapping the <code>preview</code> function in <code>CmdUtils.safePreview()</code> resolves the problem:
<pre>
CmdUtils.CreateCommand({
  ...
  preview: CmdUtils.safePreview(function(pblock) {
    Utils.previewGet(
      pblock,
      "http://www.example.com/somehtml",
      null,
      // pblock is now an untrusted DOM element, so
      // this is okay.
      function(html) { pblock.innerHTML = html; },
      "html"
    );
  }),
  ...
});
</pre>


=== Escaping Text ===
=== Escaping Text ===
Line 76: Line 35:


Another alternative is to set an element's text contents using jQuery's <tt>text()</tt> method.
Another alternative is to set an element's text contents using jQuery's <tt>text()</tt> 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 '&lt;' and '&gt;' in their selections!).


== For Core Developers ==
== For Core Developers ==


Check out the [https://www.owasp.org/index.php?title=XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#You_Need_a_Security_Encoding_Library Cross-Site Scripting Prevention Cheat Sheet Cross-Site Scripting Prevention Cheat Sheet].  Ubiquity's <tt>chrome://</tt> pages&mdash;even the ones that just look like web pages&mdash;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.
Check out the [https://www.owasp.org/index.php?title=XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#You_Need_a_Security_Encoding_Library Cross-Site Scripting Prevention Cheat Sheet Cross-Site Scripting Prevention Cheat Sheet].  Ubiquity's <tt>chrome://</tt> pages&mdash;even the ones that just look like web pages&mdash;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.
Varmaa
874

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/134783"

Navigation menu