So do these guys now have a runtime model that lets you import a specific version of your packages? Last time I looked, JavaScript just sucked in whatever shit was current on some other guy's website and you picked up whatever malware they were distributing that day. The only way to be safe was to host absolutely everything that your code uses.
One-in-two JavaScript project audits by NPM tools sniff out at least one vulnerability...
JavaScript library custodian NPM, after years of security scrambling, looks to be getting a grip on its code safety. There was that incident in May when NPM swiftly removed a backdoored package following complaints. No real damage was done. A month earlier, the bit-shifting biz added a "audit" command to v6 of npm, the …
COMMENTS
-
-
Wednesday 22nd August 2018 21:22 GMT Pascal Monett
Re: "The only way to be safe was to host absolutely everything that your code uses"
And that is also the only way to be sure of what the hell your website is doing.
I have never understood the mentality of all those who just outsourced half of their website code to people they don't know.
But hey, what do I know ? I'm just an old programmer . . .
-
Wednesday 22nd August 2018 21:56 GMT Nolveys
Last time I looked, JavaScript just sucked in whatever shit was current on some other guy's website and you picked up whatever malware they were distributing that day.
Yup. I love visiting sites that don't work for reasons that don't require javascript, but use it anyway. Then I click on the NoScript button and briefly wonder domain(s) in the pages of schlarf would make the page work. Then I close the tab.
-
Thursday 23rd August 2018 10:25 GMT bombastic bob
agreed on the 'noscript' usage, except this is NodeJS we're talking about (from what I read in the article), and so it's all server-side. Running 'noscript' has no effect on server-side
stupidityJavaScript and its apparent bag of vulnerabilities.Server-side JavaScript is its OWN target for snark, disdain, and generally being made fun of.
-
-
Thursday 23rd August 2018 03:45 GMT FF22
Ignorant
"Last time I looked, JavaScript just sucked in whatever shit was current on some other guy's website and you picked up whatever malware they were distributing that day."
Then you must have looked a very, very long time ago, possibly in a galaxy far, far away: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
-
Thursday 23rd August 2018 11:41 GMT Ken Hagan
Re: Ignorant
Not *that* long ago (https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/) and the link you provide describes a technique that would not have helped in that case because "missing package" is exactly what an integrity check failure is required to look like. Then there is the fact that if you know exactly what you wish to import and refuse to import anything else, you might as well host it yourself rather than steal bandwidth.
-
Sunday 26th August 2018 09:47 GMT FF22
Re: Ignorant
" and the link you provide describes a technique that would not have helped in that case"
The link I've provided was an answer to the nonsensical complaint about JavaScript loading "whatever shit was current on some other guy's website and you picked up whatever malware they were distributing that day". Which obviously has nothing to do with node.js in the first place, which does not have this problem, as it's not loading stuff from "some other guy's website".
So, yeah, that technique would not have helped in the case... because that problem OP complained about doesn't even exist as such in node.js
-
-
-
-
Thursday 23rd August 2018 06:55 GMT el-keef
Context lacking
One problem with the npm vulnerability scans is that they don't take account of the context of the dependency inclusion.
For example, a fresh out-of-the-box Angular 6 install will show several dependencies with vulnerabilities. But, if you look closer, some are only vulnerabilities if e.g. deployed on the server-side in Node.js, or if they hit production browser code. Within Angular they're only used as part of the build system which means they'll never see anything public facing, they never become part of the code actually used to provide a service to the end user, so will never cause any issues.
While it's fantastic that tools like npm and Github are reporting library vulnerabilities, the trouble here is that you get 'boy-cried-wolf' syndrome. If everything is is always reporting security audit issues which are easy to ignore then the one that matters, when it happens, will be missed.