Hacker News new | ask | show | jobs
by mschuster91 3530 days ago
What is justifying this?

If the vulnerable part is in Angular, there's a 100% chance that someone can write code in plain JS that is vulnerable to the same attack. E.g. if there was something in the hashbang-url-router that would lead to eval'ing the code in the hash (which I just made up, but would describe such a class of vulnerability). This means it's pointless to ban Angular.

If something Angular does triggers an issue in the Firefox JS engine, it is Firefox that should be fixed, instead of allowing essentially a 0day exploit to be alive.

3 comments

> If the vulnerable part is in Angular, there's a 100% chance that someone can write code in plain JS that is vulnerable to the same attack.

“can”, not “will”. If everything that uses Angular is vulnerable (unlikely? I couldn’t say), why would you not ban it? This is along the lines of “If Heartbleed is in OpenSSL, there’s a 100% chance that someone can write code in plain C that is vulnerable to the same attack”. Yeah, they can, and it happens all the time, but why not fix a known hole?

> E.g. if there was something in the hashbang-url-router that would lead to eval'ing the code in the hash (which I just made up, but would describe such a class of vulnerability). This means it's pointless to ban Angular.

This would be an excellent reason to ban Angular since a huge majority* of extensions never use eval().

* If this isn’t true… I don’t want to be in web dev anymore.

As AgentME clarifies above, Angular uses a lot of `eval()` of DOM elements, which is perfectly reasonable design decision when you control the contents (as you would if you used Angular in your own app), but a perfectly awful thing to do if the attacker controls the contents (as they would if you used Angular in a browser extension that processes 3rd party webpages).
> there's a 100% chance that someone can write code in plain JS that is vulnerable to the same attack

This is plainly false - please don't spread fear where it doesn't belong.

I'm sure you can think of some things that, when written into the privileged environment of an addon, create vulnerabilities that aren't possible in "plain JS."

There is nowhere near a "100% chance" that this is a problem for web apps that don't run as browser extensions.