3 ms·

I only use npm to install frontend libraries, so the installed code is limited by the browser when it runs. As far as I know the install scripts can do anythin

I only use npm to install frontend libraries, so the installed code is limited by the browser when it runs. As far as I know the install scripts can do anything they want, which is upsetting whenever I think about it or they try to do something that annoys the corporate web proxy. I bet an install script that dumped environment variables, then encoded them into something seemingly innocent like the extra fields of a dns request would gather all kinds of fun info from all the different ci/cd systems.

ljm 6y ago
That doesn't really provide any meaningful reassurance when the code in the browser can still do anything it wants, such as stealing auth tokens, keylogging, etc. It's a different class of vulnerabilities and if you happened to be doing fancy SPA stuff, you could reasonably get a double bonanza by getting into the server environment on the SSR side.
- diggan 6y ago
  npm scripts having same-as-you access to your computer in a linux-like environment is very different than JS running inside the browser sandbox though. By default its scoped to the origin its running on and with some additional header/html tags, can be further limited to just running your specific code and no get/post to other origins, and more. So while running 3rd party code without inspecting it closely is always risky, its a lot more risky to run via node than via the browser js engine.
- catears 6y ago
  There is already protection against this form of attack in the browser with CORS: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
  - the_duke 6y ago
    CORS doesn't help with compromised client code, since the CORS headers would allow access anyway. CSP [1] can help by preventing malicious code to leak data to third parties, but it's far from trivial to close all loopholes. Especially with the myriad of tracking and other third party scripts most sites/apps use. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

ljm 6y ago

That doesn't really provide any meaningful reassurance when the code in the browser can still do anything it wants, such as stealing auth tokens, keylogging, etc. It's a different class of vulnerabilities and if you happened to be doing fancy SPA stuff, you could reasonably get a double bonanza by getting into the server environment on the SSR side.

diggan 6y ago
npm scripts having same-as-you access to your computer in a linux-like environment is very different than JS running inside the browser sandbox though. By default its scoped to the origin its running on and with some additional header/html tags, can be further limited to just running your specific code and no get/post to other origins, and more. So while running 3rd party code without inspecting it closely is always risky, its a lot more risky to run via node than via the browser js engine.
catears 6y ago
There is already protection against this form of attack in the browser with CORS: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
- the_duke 6y ago
  CORS doesn't help with compromised client code, since the CORS headers would allow access anyway. CSP [1] can help by preventing malicious code to leak data to third parties, but it's far from trivial to close all loopholes. Especially with the myriad of tracking and other third party scripts most sites/apps use. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...