Type II error, False negative.

Lets say my company has a private package, iconic-spoon-collection this package is not supposed to be public. This tool would say everything is probably fine if iconic-spoon-collection existed in the public repository.

If the tool knew that iconic-spoon-collection was a private only package it would know it should not public, and the fact that this package is public is a sign that you have been breached.

Hi there

Thanks for a great tool!

We have checked a large number of package.json files. Sometimes the tool fails with this message: Encountered an error while trying to read packages from file: json: cannot unmarshal bool into Go struct field PackageJSON.bundleDependencies of type []string

For instance when running against this file npm\node_modules\decamelize\package.json

I don't know if it's a general bug or something at our end.

Thanks!

Fixes #1 by adding omitempty tags to the PackageJSON struct as not all package.json files contain every field in this struct.

Also satisfies golint by adding godoc comments to exported types, methods, and interfaces, as well as adding package level documentation.

Finally, simplifies the range statements in npm.go by removing the unnessary _ empty variable

Summary

Hello Team

Thank you for this awesome tool, I wanted to point out that while I was automating my process I came across a certain package.json that gave me all false positive results and I can't figure out why this certain one is giving such a results

Located here https://assets.vimeo.com/package.json

Screenshot

I tested all of these and all of them are already registered

Best regards

Hi guys! thanks for this great tool!.

If someone has created an npm package but later was Unpublished, the tool returns a status code 200 but the takeover for this package is still possible.

I have found this testing the package console-shim

thanks!

pip requirements files can look like this:

appdirs==1.4.4 \
    --hash=sha256:7d5d0167b2b1ba821647616af46a749d1c653740dd0d2415100fe26e27afdf41 \
    --hash=sha256:a841dacd6b99318a741b166adb07e19ee71a274450e68237b4650ca1055ab128 \
    # via black

That has the package pinned to a specific version plus hashes of the package download files. When pip is used to install packages specified like this, it downloads the file and verifies it against the hash in the requirements file. The continuations (\) are used to keep the file readable.

Given a requirements file like that, confused produces output like this:

Issues found, the following packages are not available in public package repositories:
 [!] --hash
 [!] --hash

Seems like confused doesn't support continuations (the \):

https://github.com/visma-prodsec/confused/blob/d0cafe92dca8bcacf76b3d8f36f37da679a9ca77/pip.go#L24-L35

A requirements.txt entry with tilde = is not parsed correctly.

boto3~=2.3.4

it is parsed as package name boto3~ but it should be boto3.

Tilde = is a valid syntax. https://www.python.org/dev/peps/pep-0440/#compatible-release

Hi again!

AFAIK dependencies specified as a URL are not takeovereable, as it'll override the normal lookup mechanism and it will instruct NPM to download the dependency from a specific location:

https://docs.npmjs.com/cli/v7/configuring-npm/package-json#dependencies

Some examples

"dep_name": "github_org_name/repo_name#2.2.0"
"dep_name": "https://github.com/github_org_name/repo_name#2.2.0"
"dep_name": "file:/test/path"

confused still flag these as vulnerable

Maybe the best way to fix this is by checking if the version part is valid semver, but there might be some edge cases ("tag"?)

installing executables with 'go get' in module mode is deprecated. Use 'go install pkg@version' instead. For more information, see https://golang.org/doc/go-get-install-deprecation

Some packages are breaking the npm package.json spec. An example was provided with published package that presented this issue.

This PR makes confused to continue processing while ignoring the broken values.

It is based on #5

Fixes: #1

This PR adds support for PHP checking based on Composer dependency manager.

The dependencies are checked against Composer's official package repository Packagist.

Please note that the way composer handles dependencies is quite different from pip and npm, the developer can define[1]:

1. Different source repositories for a package
2. Different package repository without disabling Packagist
3. Different package repository disabling Packagist

The current implementation does not check for those configuration changes.

There is also a very thorough blog post[2] that explains why PHP/Composer is not susceptive to this attack.

[1] https://getcomposer.org/doc/05-repositories.md [2] https://blog.packagist.com/preventing-dependency-hijacking/

Hi folks,

Awesome work on this tool. I noticed some people could not get it to work and decided to include a simple Dockerfile and instructions to build and run the container easily. Feel free to do with it as you like.

Cheers, 0xbad53c

Update install method as go get -u is outdated and not working anymore.

go get -u repuURL will no longer work. See error message below.

go install repoURL@version works..

Old error:

% go get -u github.com/visma-prodsec/confused
go: go.mod file not found in current directory or any parent directory.
	'go get' is no longer supported outside a module.
	To build and install a command, use 'go install' with a version,
	like 'go install example.com/cmd@latest'
	For more information, see https://golang.org/doc/go-get-install-deprecation
	or run 'go help get' or 'go help install'.

[W] Non-fatal issue encountered while reading package-lock.json : json: cannot unmarshal object into Go struct field PackageJSON.dependencies of type string

Now there is a package.json file content as follows Let's go search: https://www.npmjs.com/search?q=prepack-fuzzer Now, we start to run the tool to test: confused -l npm package.json He said that there is no testcheck, so let's search again Hey bro, please tell me is this normal or a bug