Live data from Hacker News

Angular 1.x Banned from Firefox Addons

github.com

141–150 of 222 posts

Re: Angular 1.x Banned from Firefox Addons

#141

Earlier quoted context omitted.

It's not the "some sort of vulnerability", it's a critical vulnerability in the design of the Angular v1, a long known vulnerability in fact.

This "vulnerability" can be only exploited in specific cases when Angular is used in an unintended way - for example, injected in a web page from extension context in Firefox (which is wrong anyway because it would conflict with scripts on the page). I tried to understand whether the same is possible in Chrome - injected scripts there have less privileges and use some form of isolation - but the manual [1] doesn't gi…

I was writing about problem in general, not relatively to the Firefox extensions. Someone may name that not a vulnerability, but Angular v1 makes it very easy to shoot yourself in your foot doing string based values evaluating as expressions.

Imagine a case when some front-end developer gets JSON data from the remote data source by REST, having no idea about data source origin. Then for example there is a need to apply $watch for some fields of the received JSON object. Lets assume some of the fields contain JS code (for now it would be a sandbox bypassing snippet, but since v1.6 seems it can be plain JS with no obfuscations). As a result XSS happens. They would better disable string based expressions evaluating for the listed methods https://docs.angularjs.org/guide/security and allow only passing function as an argument, then it would be clear for developers that data sanitizing is up to developer and it's supposed to be implemented in the custom functions. But design issue would still exist.

Re: Angular 1.x Banned from Firefox Addons

#142

Earlier quoted context omitted.

Chrome has many many extensions which run on and modify the page DOM just like Firefox! I think it might even be reasonable to guess that around half of extensions do this.

Modifying DOM is not enough to cause a vulnerability. In Chrome content scripts (the ones that are injected into a page from an extension) have limited privileges though there still can be the ways to exploit them.

Chrome content scripts can have permissions to make AJAX requests to any origin. Sure, it's not a straight-ticket to getting code native execution and installing malware on your machine, but it means an exploit against an extension with wide enough permissions could harvest your email and bank info.

Re: Angular 1.x Banned from Firefox Addons

#143

Earlier quoted context omitted.

Curious, do you use a password wallet/manager application, and if so how do you get passwords out of it and into the browser? I'd like to know if there's a better solution. (I use a browser extension.)

I think his point is that running the entire Angular 1.x framework to power a browser extension gives a large attack surface.

Yes. And to answer nchelluri's question: Auto-typing, though I believe that's available only on desktop operating systems.

Re: Angular 1.x Banned from Firefox Addons

#144

Can someone explain me: If angular can do it, so can just plain javascript? Then it's a problem with their extension architecture? As much as I hate bundling big libraries everywhere, why ban angular? Also, is it possible the researcher wants to get money from Google and didn't want the vulnerability to be shared?

I have no information one way or the other, but maybe the issue isn't that angular can do it, but that angular does do it. So any extension using angular is vulnerable by default.

Re: Angular 1.x Banned from Firefox Addons

#145
Isn't any "vulnerability" in a JS framework a vulnerability in the browser's own handling of securing it? Like, there is nothing angular is doing that someone else couldn't do, intentionally, to create said issue, right? Wouldn't the correct handling of this to be to secure the damned interpreter thats running the code to prevent it from having the effect they are trying to mitigate?

This feels like a lazy shifting of blame

Re: Angular 1.x Banned from Firefox Addons

#146

Earlier quoted context omitted.

In other words, the vulnerability is with Firefox instead of Angular?

Firefox wasn't designed to run Angular in an extension on webpage DOM. Angular wasn't designed to run in Firefox extensions on webpage DOM. Nether has a vulnerability, when used as designed. It's not safe for a 3 year old to drive a car, even if there's nothing wrong with the baby or the car.

And this isn't specific to Firefox: Angular 1.x in Chrome and Safari extensions for example is similarly affected.

Re: Angular 1.x Banned from Firefox Addons

#147

Isn't any "vulnerability" in a JS framework a vulnerability in the browser's own handling of securing it? Like, there is nothing angular is doing that someone else couldn't do, intentionally, to create said issue, right? Wouldn't the correct handling of this to be to secure the damned interpreter thats running the code to prevent it from having the effect they are trying to mitigate? This feels like a lazy shifting o…

Angular evals text stored in the DOM. If you alone are in control of the DOM (like in a normal webpage), there's no issue. If someone else is in control of the DOM (you're running Angular in a higher-privileged extension running on a random webpage's DOM), then they can put code into the DOM which then gets picked up by Angular and executed within the extension with the extension's full permissions. This isn't an issue inherent to the language or browser at all. This is an issue just comes from that Angular 1.x is designed for use-cases where the DOM is trusted, and that's not the case for browser extensions.

Re: Angular 1.x Banned from Firefox Addons

#148
post #48
post #14

Earlier quoted context omitted.

Was recently at an angular conference -- they said they would continue to support it until the _majority_ of the community had made the switch. That's so far from happening, I imagine they'll be supporting it for years.

At least until they get tired and change their minds, which may not take that long.

Even if that did, there might be a community that pops up to take on the burden instead of G.

Re: Angular 1.x Banned from Firefox Addons

#149

Can someone explain me: If angular can do it, so can just plain javascript? Then it's a problem with their extension architecture? As much as I hate bundling big libraries everywhere, why ban angular? Also, is it possible the researcher wants to get money from Google and didn't want the vulnerability to be shared?

Yes, you can write vulnerable code in plain javascript:

    eval(document.querySelector('.foo').textContent);
In a regular web page where you don't allow the user to insert arbitrary HTML, it's a perfectly fine line allowing you to store code in the DOM.

If you do that in a browser extension where the DOM is controlled by the web page, then you've got a big security vulnerability: the webpage can put anything it wants into a foo tag and then your extension will execute it with its privileges! Your extension will be taken down from the Firefox Addons Marketplace if it's reviewed and this line is found running. If lots of extensions added this line, then Mozilla would probably automate blocking extensions from containing it.

Angular 1.x does something like this line. It's perfectly fine in web pages where you control the DOM, but is insecure if the DOM comes from an untrusted outsider!

Re: Angular 1.x Banned from Firefox Addons

#150

Isn't any "vulnerability" in a JS framework a vulnerability in the browser's own handling of securing it? Like, there is nothing angular is doing that someone else couldn't do, intentionally, to create said issue, right? Wouldn't the correct handling of this to be to secure the damned interpreter thats running the code to prevent it from having the effect they are trying to mitigate? This feels like a lazy shifting o…

Angular evals text stored in the DOM. If you alone are in control of the DOM (like in a normal webpage), there's no issue. If someone else is in control of the DOM (you're running Angular in a higher-privileged extension running on a random webpage's DOM), then they can put code into the DOM which then gets picked up by Angular and executed within the extension with the extension's full permissions. This isn't an iss…

But thats not special to angular... right? You can write that in vanilla javascript just the same - the issue is that the script running in the extension is given the ability to do that. They dont seem to be blocking a feature in javascript, they seem to be blocking a lib that uses it. Angular can't do ANYTHING that any other bit of javascript can't do in the same context.

Angular is just JS, its not special JS, its just JS. If angular can do something, it can be done without angular so blocking angular does nothing to prevent the vulnerability.

Post reply on HN