4 ms·

Traditional JS is actually among the safest environments ever created. Every day, billions of devices run untrusted JS code, and no other platform has seen sand

by jeswin 1y ago

Traditional JS is actually among the safest environments ever created. Every day, billions of devices run untrusted JS code, and no other platform has seen sandboxed execution at such scale. And in nearly three decades, there have been very few incidents of large successful attacks on browser engines. That makes the JS engine derived from browsers the perfect tool to build a server side framework out of. However, processes and practices around NodeJS and npm are in dire need of a security overhaul. leftpad is a cultural problem that needs to be addressed. To start with, snippets don't need to be on npm.

spankalee 1y ago
Sandboxing doesn't do any good if the malicious code and target data are in the same sandbox, which is the whole point of these supply-chain attacks.
- pixl97 1y ago
  I mean, what does do good if your supply chain is attacked? This said, less potential vendors supplying packages 'may' reduce exposure, but doesn't remove it. Either way, not running the bleeding edge packages unless it's a known security fix seems like a good idea.
  - spankalee 1y ago
    The supply chain infrastructure needs to stop being naive and allowing for insecure publishing. - npm should require 2FA disallow tokens for publishing. This is an option, but it should be a requirement. - npm should require using a trusted publisher and provenance for package with over 100k downloads a week and their dependencies. - Github should require a 2FA step for automated publishing - npm should add a cool down period where if won't install brand new packages without a flag - npm should stop running postinstall scripts. - npm should have an option to not install packages without provenance.
    - raxxorraxor 1y ago
      The reality is that for a huge crowd of developers 2FA doesn't do shit.
- AlienRobot 1y ago
  I think the sandbox they're talking about is the browser, not the server (which runs node).
- tetha 1y ago
  But if we think about a release publishing chain like a BSD process separation, why do they have to be? Sure, there will be a step/stage that will require access to NPM publish credentials to publish to NPM. But why does this stage need to execute any code except a very small footprint of vetted code? It should just pickup a packaged, signed binary and move it to NPM. The compilation/packaging step on the other hand doesn't need publishing rights to NPM. Ideally, it should only get a filesystem with the sources, dependencies and a few shared libraries and /sys or /proc dependencies it may need to function. Why does some dependency downloading need access to your entire filesystem? Maybe it needs some allowed secrets, but eh. It's certainly a lot of change into existing pipelines and ideas, and it's certainly possible to poke holes into there if you want things to be easy. But it'd raise the bar quite a bit.
kortilla 1y ago
None of those security guarantees matter when you take out the sandbox, which is exactly what server-side JS does. The isolated context is gone and a single instance of code talking to an individual client has access to your entire database. It’s a completely different threat model.
- galaxyLogic 1y ago
  So maybe the solution would be to sandbox Node.js? I'm not quite sure what that would mean, but if it solves the problem for browsers, why not for server?
  - simiones 1y ago
    You can't sandbox the code that is supposed to talk to your DB from your DB. And even on client side, the sandboxing helps isolate any malicious webpage, even ones that are accidentally malicious, from other webpages and from the rest of your machine. If malicious actors could get gmail.com to run their malicious JS on the client side through this type of supply-chain attack, they could very very easily steal all of your emails. The browser sandbox doesn't offer any protection from 1st party javascript.
  - int_19h 1y ago
    Deno does exactly that. But in practice, to do useful things server-side you generally need quite a few permissions.
WD-42 1y ago
Javascript doesn't have a standard library, until it does the 170 million[1] weekly downloads of packages like UUID will continue. You can't expect people to re-write everything over and over. [1]https://www.npmjs.com/package/uuid https://www.npmjs.com/package/uuid
- skydhash 1y ago
  You have the DOM and Node APIs. Which I think cover more than C library or Common Lisp library. Adding direct dependencies is done by every project. The issue is the sprawling deps tree of NPM and JS culture. > You can't expect people to re-write everything over and over. That’s the excuse everyone is giving, then you see thousands of terminal libraries and calendar pickers.
  - chamomeal 1y ago
    When I was learning JS/node/npm as a total programming newbie, a lot of the advice online was basically “if you write your own version of foobar when foobar is already available as an npm package, you’re stupid for wasting your time”. I’d never worked in any other ecosystem, and I wish I realized that advice was specific to JS culture
    - jlarocco 1y ago
      It's not really bad advice, it just has different implications in Javascript. In other languages, you'd have a few dependencies on larger libraries providing related functionality, where the Javascript culture is to use a bunch of tiny libraries to give the same functionality.
      - lenerdenator 1y ago
        Sometimes I wonder how many of these tiny libraries are just the result of an attempt to have something ready for a conference talk and no one had the courage to say "Uh, Chris, that already exists, and the world doesn't need your different approach on it."
mewpmewp2 1y ago
Interestingly AI should be able to help a lot with desire to load those snippets. What I'm wondering if it would help the ecosystem, if you were able to rather load raw snippets into your codebase, and source control as opposed to having them as dependencies. So e.g. shadcn component pasting approach. For things like leftPad, cli colors and others you would just load raw typescript code from a source, and there you would immediately notice something malicious or during code reviews. You would leave actual npm packages to only actual frameworks / larger packages where this doesn't make sense and expect higher scrutiny, multi approvals of releases there.
skydhash 1y ago
I think the smallest C library I’ve seen was a single file to include on your project if you want terminal control like curses on windows. A lot of libraries on npm (and cargo) should be gist or a blog post.
- mhitza 1y ago
  15+ years ago used to copy paste utility functions from stackoverflow, now people npm installing packages for a function or two.
- deelowe 1y ago
  It shouldn't matter how many libraries npm supports.
lenerdenator 1y ago
> Traditional JS is actually among the safest environments ever created. > However, processes and practices around NodeJS and npm are in dire need of a security overhaul. leftpad is a cultural problem that needs to be addressed. To start with, snippets don't need to be on npm. Traditional JS is the reason we have all of these problems around NodeJS and npm. It's a lot better than it was, but a lot of JS tooling came up in the time when ES5 and older were the standard, and to call those versions of the language lacking is... charitable. There were tons of things that you simply couldn't count on the language or its standard library to do right, so a culture of hacks and bandaids grew up around it. Browser disparities didn't help either. Then people said, "Well, why don't we all share these hacks and bandaids so that we don't have to constantly reinvent the wheel?", and that's sort of how npm got its start. And of course, it was the freewheeling days of the late 00s/early 10s, when you were supposed to "move fast and break things" as a developer, so you didn't have time to really check if any of this was secure or made any sense. The business side wanted the feature and they wanted it now. The ultimate solution would be to stop slapping bandaids and hacks on the JS ecosystem by making a better language but no one's got the resolve to do that.
- com2kid 1y ago
  Python is the other extreme, with an incredibly heavy weight standard library with a built in function to do just about anything. E.g. there is a built in function that takes elements pairwise from a list! That level of minutia being included feels nuts having come from other languages.

by jeswin 1y ago

spankalee 1y ago

Sandboxing doesn't do any good if the malicious code and target data are in the same sandbox, which is the whole point of these supply-chain attacks.

pixl97 1y ago
I mean, what does do good if your supply chain is attacked? This said, less potential vendors supplying packages 'may' reduce exposure, but doesn't remove it. Either way, not running the bleeding edge packages unless it's a known security fix seems like a good idea.
- spankalee 1y ago
  The supply chain infrastructure needs to stop being naive and allowing for insecure publishing. - npm should require 2FA disallow tokens for publishing. This is an option, but it should be a requirement. - npm should require using a trusted publisher and provenance for package with over 100k downloads a week and their dependencies. - Github should require a 2FA step for automated publishing - npm should add a cool down period where if won't install brand new packages without a flag - npm should stop running postinstall scripts. - npm should have an option to not install packages without provenance.
  - raxxorraxor 1y ago
    The reality is that for a huge crowd of developers 2FA doesn't do shit.
AlienRobot 1y ago
I think the sandbox they're talking about is the browser, not the server (which runs node).
tetha 1y ago
But if we think about a release publishing chain like a BSD process separation, why do they have to be? Sure, there will be a step/stage that will require access to NPM publish credentials to publish to NPM. But why does this stage need to execute any code except a very small footprint of vetted code? It should just pickup a packaged, signed binary and move it to NPM. The compilation/packaging step on the other hand doesn't need publishing rights to NPM. Ideally, it should only get a filesystem with the sources, dependencies and a few shared libraries and /sys or /proc dependencies it may need to function. Why does some dependency downloading need access to your entire filesystem? Maybe it needs some allowed secrets, but eh. It's certainly a lot of change into existing pipelines and ideas, and it's certainly possible to poke holes into there if you want things to be easy. But it'd raise the bar quite a bit.

kortilla 1y ago

None of those security guarantees matter when you take out the sandbox, which is exactly what server-side JS does. The isolated context is gone and a single instance of code talking to an individual client has access to your entire database. It’s a completely different threat model.

galaxyLogic 1y ago
So maybe the solution would be to sandbox Node.js? I'm not quite sure what that would mean, but if it solves the problem for browsers, why not for server?
- simiones 1y ago
  You can't sandbox the code that is supposed to talk to your DB from your DB. And even on client side, the sandboxing helps isolate any malicious webpage, even ones that are accidentally malicious, from other webpages and from the rest of your machine. If malicious actors could get gmail.com to run their malicious JS on the client side through this type of supply-chain attack, they could very very easily steal all of your emails. The browser sandbox doesn't offer any protection from 1st party javascript.
- int_19h 1y ago
  Deno does exactly that. But in practice, to do useful things server-side you generally need quite a few permissions.

WD-42 1y ago

Javascript doesn't have a standard library, until it does the 170 million[1] weekly downloads of packages like UUID will continue. You can't expect people to re-write everything over and over. [1]https://www.npmjs.com/package/uuid https://www.npmjs.com/package/uuid

skydhash 1y ago
You have the DOM and Node APIs. Which I think cover more than C library or Common Lisp library. Adding direct dependencies is done by every project. The issue is the sprawling deps tree of NPM and JS culture. > You can't expect people to re-write everything over and over. That’s the excuse everyone is giving, then you see thousands of terminal libraries and calendar pickers.
- chamomeal 1y ago
  When I was learning JS/node/npm as a total programming newbie, a lot of the advice online was basically “if you write your own version of foobar when foobar is already available as an npm package, you’re stupid for wasting your time”. I’d never worked in any other ecosystem, and I wish I realized that advice was specific to JS culture
  - jlarocco 1y ago
    It's not really bad advice, it just has different implications in Javascript. In other languages, you'd have a few dependencies on larger libraries providing related functionality, where the Javascript culture is to use a bunch of tiny libraries to give the same functionality.
    - lenerdenator 1y ago
      Sometimes I wonder how many of these tiny libraries are just the result of an attempt to have something ready for a conference talk and no one had the courage to say "Uh, Chris, that already exists, and the world doesn't need your different approach on it."

mewpmewp2 1y ago

Interestingly AI should be able to help a lot with desire to load those snippets. What I'm wondering if it would help the ecosystem, if you were able to rather load raw snippets into your codebase, and source control as opposed to having them as dependencies. So e.g. shadcn component pasting approach. For things like leftPad, cli colors and others you would just load raw typescript code from a source, and there you would immediately notice something malicious or during code reviews. You would leave actual npm packages to only actual frameworks / larger packages where this doesn't make sense and expect higher scrutiny, multi approvals of releases there.

skydhash 1y ago

I think the smallest C library I’ve seen was a single file to include on your project if you want terminal control like curses on windows. A lot of libraries on npm (and cargo) should be gist or a blog post.

mhitza 1y ago
15+ years ago used to copy paste utility functions from stackoverflow, now people npm installing packages for a function or two.
deelowe 1y ago
It shouldn't matter how many libraries npm supports.

lenerdenator 1y ago

> Traditional JS is actually among the safest environments ever created. > However, processes and practices around NodeJS and npm are in dire need of a security overhaul. leftpad is a cultural problem that needs to be addressed. To start with, snippets don't need to be on npm. Traditional JS is the reason we have all of these problems around NodeJS and npm. It's a lot better than it was, but a lot of JS tooling came up in the time when ES5 and older were the standard, and to call those versions of the language lacking is... charitable. There were tons of things that you simply couldn't count on the language or its standard library to do right, so a culture of hacks and bandaids grew up around it. Browser disparities didn't help either. Then people said, "Well, why don't we all share these hacks and bandaids so that we don't have to constantly reinvent the wheel?", and that's sort of how npm got its start. And of course, it was the freewheeling days of the late 00s/early 10s, when you were supposed to "move fast and break things" as a developer, so you didn't have time to really check if any of this was secure or made any sense. The business side wanted the feature and they wanted it now. The ultimate solution would be to stop slapping bandaids and hacks on the JS ecosystem by making a better language but no one's got the resolve to do that.

com2kid 1y ago
Python is the other extreme, with an incredibly heavy weight standard library with a built in function to do just about anything. E.g. there is a built in function that takes elements pairwise from a list! That level of minutia being included feels nuts having come from other languages.