5 ms·
I cant help but think of the post about stealing password credentials from the site you build by surreptitiously inserting extra code into the published NPM pac
by mpolichette 8y ago
I cant help but think of the post about stealing password credentials from the site you build by surreptitiously inserting extra code into the published NPM package. Except wasm packages seem like they'd be even harder to detect.
https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 https://hackernoon.com/im-harvesting-credit-card-numbers-and...
- crispyporkbites 8y agoI have a package on NPM which is only partially implemented, using it in a production app is a bad idea, a quick glance at the source code or the todo section of the readme makes it pretty obvious. I still gets bug reports and npm says it has hundreds of download every month. For anything serious, read the source code, at the very least check your dependencies.
- ag_dubs 8y agofwiw as a former npm registry engineer i can tell u that "hundreds of download every month" likely is a result of the background bot activity npm gets. but your advice is sound! definitely vet your deps before you use them! and YES! read the source.
- probablycorey 8y agoIs this realistic though? Every time you update a dependency you would have to read its source (and its source dependencies, and their source dependencies...) To do that well, it would be someone's fulltime job to read and do security audits on all those dependencies.
- illustrioussuit 8y agoTheoretically, once something is updated all you would have to do is check the diff. Still tedious though.
- Y_Y 8y agoI look forward to all the clever exploits that result from benign-looking code being added to benign-looking code.
- komali2 8y agoLast time I went to one of the Bay Area node meetups, that given meetup was being sponsored by just such a company. Can't remember the name, unfortunately. The idea was though that you'd feed them your package.json and they'd let you know of any vulnerabilities, iirc. Or maybe they had a private repo of packages they'd checked? Can't remember.
- tomsmeding 8y agoPossibly https://snyk.io/ https://snyk.io/ ?
- mpolichette 8y agoThe argument in that article is that it doesn't matter what is in the source. The published package has no guarantees to be from the source.
- maxyme 8y agoYou could already do this tons of ways. Native modules come to mind.
- creatonez 8y agoWhich don't run in browsers
- eridius 8y agoSince wasm (currently) requires js to interact with the DOM, you could still read the js code to see if it's passing any sensitive data into wasm.
- mattnewton 8y agoJs code is sufficiently dynamic where I wouldn’t be confident in anyone using this defense, even with a debugger open.
- eridius 8y agoThe complaint here is that moving from js to wasm means you can't tell if a package is maliciously exfiltrating your sensitive data. That presupposes that you can read and understand the js code. If your argument here is that you can't be confident in your ability to read and understand the js code, then moving to wasm is no longer a problem.
- bzbarsky 8y agoYou can read the JS code. If it's trying to be sneaky, you _cannot_ understand it, in general. If you think you can, that is false confidence that is best gotten rid of.
- mattnewton 8y agoThat’s probably true, but I do think that the addition of wasm complicated things. Imagine a js bridge that calls window objects by strings built in the wasm blob, or does anytning using eval. Now the wasm code can call anything js can through this bridge.
- eridius 8y agoI suppose that's true, but you can also tell that the JS is trying to obfuscate what it's doing and just generally distrust it at that point.
- mpolichette 8y ago