Re:20% of all Node.js modules found vulnerable to injection ...
by dspillett on Monday March 12, 2018 @11:27AM
(#16568759)
The title here (20% of all Node.js modules found vunerable to injection attacks) seems more sensationalised then that of the actual article:
> 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.
> 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.