Full-offline installation

[jasonkarns]

I love the concept and idea of this tool. However, when doing an audit of the code, I find that there's a heavy does of irony.

This package is meant to be used to -tighten- the security of applications by being able to install or npm packages without running scripts. However, the CLI as it stands makes web requests for its data. That web request opens this package up to a much wider attack surface: instead of merely compromising this package, one could compromise the website that this package contacts. That's a much more serious vulnerability because it would allow compromising prior versions of this package without requiring a new release.

I would suggest a hardened version of this package be developed. One that is nothing but the CLI (CLI users shouldn't need to download the research, public or api directories at all) and that doesn't make any on-demand web requests.

[naugtur]

This tool does 2 things:

• lists postinstall scripts from dependencies
• downloads and presents latest community recommendations on which you cannot ignore

None of this is strictly security. The security provided for you is the ability to turn off running all postinstall scripts, even the unexpected ones.

You might as well manually allow all existing scripts. The security value-add is in not running scripts that weren't there yesterday.

This command is merely helping you narrow down what you'll run to make the allowlist shorter. It doesn't do any security and should only be run by the developer who's configuring the allowlist of scripts. The http request is there to fetch the latest research even if you installed the CLI much earlier. And it populates a set of all packages with scripts that can be periodically added to the todo for research.

No information provided by this package has security impact. There's nothing to compromise here. You get compromised if you run a malicious script that was added to a package that didn't have one before.
Information about known malicious scripts is not going to exist in here, because they get removed before we could even react and add them to the data.

[jasonkarns]

None of this is strictly security.

Sure, but the people using this are doing it because of the improved security that this tool helps enable. Indeed, the documented (and useful) implementation is to run this in CI after npm/yarn install to get always-up-to-date report of ability to ignore scripts.

You might as well manually allow all existing scripts.

This isn't true because an existing script could be replaced with a malicious one if the owning package is compromised.

The security value-add is in not running scripts that weren't there yesterday.

Plus the value-add of always having an audit/report of deps that use scripts. Even knowing the existing (allowed) scripts makes an app owner aware of the surface area.

There's nothing to compromise here.

That's not how attackers operate. This tool has a value-add for being run in CI environments. This would make a fantastic job that could run on main branches and generate a report of scripts in use that the development team can reference. (Store the report in a particular format and it can even be hosted by certain CI tools and linked directly from app readmes). A secondary value-add is having it run as part of CI on pull requests. That way the report could be diffed against the report generated on mainline in order to spot any new deps' scripts. Would be fantastic information to have, especially on dependabot PRs.

So, there's clearly value-add for this tool to be run in CI. Hopefully I don't need to demonstrate the reason an attacker would love to have access to an app's CI. (CI is a treasure trove of application env vars; even moreso than a user's machine because CI typically has privileged access and higher level rights on its tokens.)

Compromising this package would be sufficient to gain access to any app's CI environment, but that's not unique to this package. That's true of any dependency. What are the two things unique to this package?

1. per your docs and blog post, there is a much higher likelihood that users will not be adding this package as a devDep, but instead fetching directly on demand. (due to the docs recommending npx can-i-ignore) This means that applications will not have the benefit of being pinned to a non-compromised version.
2. the fact that the CLI makes a web request means an attacker could compromise the website instead of this package on npm. Granted, they would have to also have to be able to exploit something in the request package in order to bypass the parsing of the payload as JSON. But vulnerabilities in http and json libraries are not uncommon.

If the web request were critical to the functioning of this tool, we could argue that the risks (having low likelihood) were outweighed by the benefit. However, it is my contention that this web request is not critical. Indeed, the package already functions correctly when the request fails. A more hardened implementation of this utility would give the user the capability to run the tool in fully offline mode, that way application owners can evaluate their own threat models accordingly. Presently, this is not possible. It could be as simple as an --offline flag that skips the request. Or instructing the CLI to read the datafile from STDIN.

[naugtur]

First of all - I really appreciate you care so much. Let's continue.

I could agree with almost all you said. With one exception - the initial assumption it makes sense to run it in CI. There is no reason to do that.

Now I want to understand why you'd think it's a tool to run in CI. I'm probably missing a lot of context. Or I failed to convey the purpose of the tool 😅

[tbroyer]

Fwiw, unless I misread the code, this tool will leak all used packages to the web service. This could include internal package names, enabling industrial espionnage and supply chain attacks if these package names are leaked by the web service somehow.

There should be a flag to only use the local data, without ever reaching out to the web service. Either that or never including package names in the request made to the web service.

[naugtur]

You can see it gets sent to vercel where this repo is deployed and I'm collecting new packages to research.
I'd accept a PR for a switch to opt out or I can add it myself.

Eventually, when people start contributing to data file more I'll remove the code collecting package names and just fetch fresh data from the server.

[tbroyer]

I'd accept a PR for a switch to opt out or I can add it myself.

Unfortunately I have no idea how to handle command line flags in Node scripts 🤷

Ideally, there could be:

• a way to not reach to the network at all
• a way to call the API to retrieve the latest JSON data but without sending package names (retrieving the whole data rather than tailored for those packages that are in node_modules)

(this should probably be a single command line flag, with an argument for the mode you want to use)

Alternatively, release often, with an updated data.json, rather than downloading it from a web service. Running npx can-i-ignore-scripts@latest would then always resolve to the latest version, with up-to-date data.

[naugtur]

Adding commandline attributes is fairly easy if you don't over engineer. Installing yargs-parser and reading its docs should suffice.

I've got other stuff on my plate for the next 2 weeks, so definitely won't get it done myself by the end of next week.

As for releasing often -
would you be willing to contribute the work to automate releasing with GitHub actions?

[tbroyer]

Thanks for the pointer to yargs-parser, see #20

Regarding setting up automatic publishing, I've never published to NPM but it doesn't look too hard (based on https://docs.npmjs.com/cli/v8/commands/npm-version and https://docs.github.com/en/actions/publishing-packages/publishing-nodejs-packages#publishing-packages-to-the-npm-registry), for example triggering an automatic patch release every time the data.json file is modified.
But with a --mode offline flag this becomes less urgent, and in the mean time you can continue receiving package names to investigate and add to the data.