Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify the purpose and usage of the tool #9

Merged
merged 2 commits into from
Feb 12, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
# Changelog

- main
- New
- PHP (composer) support
- Changed
- Python (pypi) dependency definition files that use line continuation are now parsed correctly

- v0.2
- Changed
- npm registry checkup url
- Throttle the rate of requests in case of 429 (Too many requests) responses

- v0.1
- Initial release
25 changes: 25 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,31 @@
A tool for checking for lingering free namespaces for private package names referenced in dependency configuration
for Python (pypi) `requirements.txt`, JavaScript (npm) `package.json` or PHP (composer) `composer.json`.

## What is this all about?

On 9th of February 2021, a security researcher Alex Birsan [published an article](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610)
that touched different resolve order flaws in dependency management tools present in multiple programming language ecosystems.

Microsoft [released a whitepaper](https://azure.microsoft.com/en-gb/resources/3-ways-to-mitigate-risk-using-private-package-feeds/)
describing ways to mitigate the impact, while the root cause still remains.

## Interpreting the tool output

`confused` simply reads through a dependency definition file of an application and checks the public package repositories
for each dependency entry in that file. It will proceed to report all the package names that are not found in the public
repositories - a state that implies that a package might be vulnerable to this kind of attack, while this vector has not
yet been exploited.

This however doesn't mean that an application isn't already being actively exploited. If you know your software is using
private package repositories, you should ensure that the namespaces for your private packages have been claimed by a
trusted party (typically yourself or your company).

### Known false positives

Some packaging ecosystems like npm have a concept called "scopes" that can be either private or public. In short it means
a namespace that has an upper level - the scope. The scopes are not inherently visible publicly, which means that `confused`
cannot reliably detect if it has been claimed. If your application uses scoped package names, you should ensure that a
trusted party has claimed the scope name in the public repositories.

## Installation

Expand Down
4 changes: 3 additions & 1 deletion main.go
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,9 @@ func Help() {

func PrintResult(notavail []string) {
if len(notavail) == 0 {
fmt.Printf(" [*] All packages seem to be available in the public repositories. Dependency confusion should not be possible.\n")
fmt.Printf("[*] All packages seem to be available in the public repositories. \n\n" +
"In case your application uses private repositories please make sure that those namespaces in \n" +
"public repositories are controlled by a trusted party.\n\n")
return
}
fmt.Printf("Issues found, the following packages are not available in public package repositories:\n")
Expand Down