https://code.google.com/p/google-security-research/issues/at...
<a href="javascript:begin()">Click Here</a> to run the command above
(the default will uninstall Trend Micro Maximum).https://code.google.com/p/google-security-research/issues/at...
<a href="javascript:begin()">Click Here</a> to run the command above
(the default will uninstall Trend Micro Maximum).It's like "They're using JS; how could it possibly be secure?!". That's actually highly ironic considering that JS is so far the only language that is secure enough to run universally in every browser on the planet.
People can't get around the fact that JS has evolved a LOT since it was launched and it still suffers a bad name.
The result is that your server-side JS is more prone to different kinds of security issues.
On the client side, in the browser, JS is sandboxed, so the language is almost irrelevant. If JS can't actually access the underlying system, no number of bugs make the code insecure.
All those are not a factor in this instance. It seems to me it's a result of calling exec() on unscrubbed user input, and this can be done in any language.
JS is not "the only language that is secure enough to run universally in every browser on the planet." In fact, JS has had many, many security issues in browsers.
Rather, JS is the only language nearly every browser on the planet has implemented in the browser (hopefully sandboxed!)
This is just not true.
It's also much, much easier to introduce bugs in certain languages because of the way they handle errors, or because the syntax is confusing and ambiguous. Even permissive handling of boolean logic, like what you get in PHP/JavaScript ("0" == true, for example) can result in massive security holes.