Hacker News Reader

Comment by mpolichette | Hacker News Reader

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...

View on HN

I 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.

fwiw 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.

Is 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.

Last 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.

Possibly https://snyk.io/ ?

Theoretically, once something is updated all you would have to do is check the diff. Still tedious though.

I look forward to all the clever exploits that result from benign-looking code being added to benign-looking code.

The 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.

You could already do this tons of ways. Native modules come to mind.

Which don't run in browsers

Since 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.

Js code is sufficiently dynamic where I wouldn’t be confident in anyone using this defense, even with a debugger open.

The 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.

You 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.

That’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.

I 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.

Maybe the code wraps querySelector and getAttribute for wasm, or similar. Or maybe its underhanded code, designed to do something different than it seems to.

Thats neat, cool, given that, we are at least only as susceptible as we were before.

Wouldn't the network tab still record any network requests from wasm

I would assume so, but if the request is encrypted you wouldn't know what's in it.

Reply on news.ycombinator.com