11–20 of 42 posts
This headline is entirely false - 20% of Node modules use 'eval' or 'exec'. While these are certainly less secure and a strong secure coding standard would probably ban them or at least reduce their use, it's entirely possible to use both in safe ways.
This headline is entirely false - 20% of Node modules use 'eval' or 'exec'. While these are certainly less secure and a strong secure coding standard would probably ban them or at least reduce their use, it's entirely possible to use both in safe ways.
(emphasis mine)
Apparently any module that uses eval or exec counts in "may", regardless of whether there's an actual vulnerability. Then using dependency analysis they extrapolate the 3% of packages that actually use these features to 20% that depend on something that use them.
Maybe uses of eval or exec should be more closely audited for safety, but blanket stating that any use of core language features makes you vulnerable is just vacuous clickbait.
This is a Synode sales pitch.
This headline is entirely false - 20% of Node modules use 'eval' or 'exec'. While these are certainly less secure and a strong secure coding standard would probably ban them or at least reduce their use, it's entirely possible to use both in safe ways.
Key word is vulnerable. There is a gap in protection and they are at risk to being potentially exploited.
> Understanding and automatically preventing injection attacks on Node.js
The article further guards the hyperbole with phrasing like "may be vulnerable" which is not reflected in the HN submission title.
As click-baity as the title here could be interpreted, the article is highlighting what could be a significant problem: people often don't perform input validation well or create designs which make it difficult to do well at all.
The article may be understating the issue by concentrating on specific types of attack: it seems to be referring only to calls to exec() and eval(), so could underestimating the problem by only considering served-side JS and shell/OS injection vectors. I would think that database vectors and client-side vectors (resulting on possible XSS attacks) are pretty common too, probably more so. They certainly are in a lot of code I've seen both online and in private codebases, due to lax input sanity checking or worse: architectures that make good validation in this respect practically impossible.
This is not at all unique to node.
> A staggering 90% of the call sites do not use any mitigation technique at all.
Many libraries simply assume that the caller are performing input validation and only sending them sanitised commands. This is not safe, particularly in a publicly available library, as a lot of naive programmers will assume that the library is performing some validation and will raise exceptions in the presence of something dangerous. Even documenting the lack of validation won't help in many cases because how many people read documentation in detail until something goes wrong?!
> Another 9% attempt to sanitise input using regular expressions. Unfortunately, most of those were not correctly implemented.
This is a common problem too, the most problematic issue being people using regular expressions to try identify bad inputs. Trying to enumerate the bad is generally impossible as the range of bad inputs is usually infinitely larger then the range of good ones.
https://news.ycombinator.com/item?id=16566587
I thought it was interesting and relevant for this audience, so I put a more sensational (but arguably accurate - you can argue the semantics of vulnerable all day) headline in the title to grab HN reader's attention. Now it is top of the front page with 40 votes in 25 minutes.
If you want to read papers like this everyday, I got it from the morning paper mailing list: https://blog.acolyer.org/
The issue is an important one to bring attention to, but as I leave this comment all the other comments are arguing whether the submitted title is accurate/click-bait.
This headline is entirely false - 20% of Node modules use 'eval' or 'exec'. While these are certainly less secure and a strong secure coding standard would probably ban them or at least reduce their use, it's entirely possible to use both in safe ways.
So if my backup utility happens to depend on a wrapper library for node's Child Process module (which probably doesn't sanitize its inputs, as that would break quite a bit of functionality), it's considered "vulnerable".
This was posted 9 hours ago with the paper title as the name, and got 3 upvotes: https://news.ycombinator.com/item?id=16566587 I thought it was interesting and relevant for this audience, so I put a more sensational (but arguably accurate - you can argue the semantics of vulnerable all day) headline in the title to grab HN reader's attention. Now it is top of the front page with 40 votes in 25 minutes. If you want to…
Sometimes I worry about humanity!
This was posted 9 hours ago with the paper title as the name, and got 3 upvotes: https://news.ycombinator.com/item?id=16566587 I thought it was interesting and relevant for this audience, so I put a more sensational (but arguably accurate - you can argue the semantics of vulnerable all day) headline in the title to grab HN reader's attention. Now it is top of the front page with 40 votes in 25 minutes. If you want to…
So basically: click-bait / vote-bait works, even with audiences that I expect to have a larger degree of technical literacy overall than the general populace. Sometimes I worry about humanity!