4 ms·
Not necessarily. JS in addons has to run in a more privileged environment to interact with the browser. However, that makes it possible to write insecure addons
by nathancahill 10y ago
Not necessarily. JS in addons has to run in a more privileged environment to interact with the browser. However, that makes it possible to write insecure addons. In this case, Angular 1.x might contain the insecure code.
For example: arbitrary user input from a web page is passed to the addon. Angular handles it, and does "eval-like things"[0] with it. Now the attacker is running arbitrary code in a privileged environment.
[0] eval-like things is a core part of how Angular works. So the vulnerability doesn't necessarily apply to Angular 1.x in a normal web page. But it wasn't designed to be run with higher privileges.
- secmax 10y agoSo a vulnerability of this kind would not only affect Firefox but also Chrome and others?
- nathancahill 10y agoEvery browsers addon runtime is different. Firefox is working on standardizing things with it's Web Extensions API (modeled after Chromium's API). But potentially, yes.
- AgentME 10y agoMost likely. Angular evals stuff from the DOM. Chrome extensions share the DOM with the webpage like Firefox extensions.
- codedokode 10y agoIn Chrome content scripts (the ones that are injected into a page from an extension) run in some kind of isolated mode: https://developer.chrome.com/extensions/content_scripts https://developer.chrome.com/extensions/content_scripts Yet they have some privileges a normal script doesn't have, for example the ability to post messages to parent extension which can be exploited.
- AgentME 10y agoThey still see the same content in the DOM. The extension just has a separate javascript-wrapper around the DOM. This means that an extension will not be affected if a webpage monkey-patches a DOM method to do something else. But if a webpage places some specific text content inside an HTML element, then the extension will see that same text content! (And Angular running in the extension can still choose to recognize that content as a template and eval it.)
- the_duke 10y agoChromes extension APIs do not provide the level of access that Firefox APIs do.
- bzbarsky 10y agoThe topic of discussion here is Firefox webextensions, which are meant to be API-compatible with Chrome extensions and have the same security model.
- codedokode 10y agoYou can find same kind of "vulnerability" in jQuery: $(element).html(user input); This will evaluate scripts in "user input". Does this mean jQuery is vulnerable? No, it just means you are doing something wrong with it. UPD: I was wrong, jQuery inserts a script tag into DOM instead of directly calling eval() so the code above is not equivalent to eval and is another type of vulnerability.
- bzbarsky 10y agoIt will evaluate scripts with the permissions of the element being manipulated. Which in a normal webpage is the same thing as the script doing the manipulating, which means you have XSS, which is bad, yes. In the context of an extension manipulating a web page, though, the jQuery thing you quote will evaluate the script with the permissions of the web page, not the permissions of the extension. On the other hand, doing eval() with a string from the web page will evaluate things with the permission of the extension. So there is a pretty subtle (and irrelevant in web pages!) but important distinction between the two kinds of script injection here. In a web page they are more or less equivalent in terms of leading to XSS if you have untrusted input. But in an extension, the jQuery one is OK if your input comes from the web page itself, and the eval() version is not. [Disclaimer: I work for Mozilla, but not on extension policy.]
- AgentME 10y agojQuery doesn't do that on its own by default just by the act of loading it though. Angular does.