Dependency Confusion Protection in PHP with Composer

Alex Birsan recently published an article “Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies”, in which he described how he used language-level package managers like npm (Javascript), pip (Python), and gems (Ruby) to force companies to install and run malicious code on their infrastructure.

The problem comes down to the fact that companies refer to internal packages by name, for example my-internal-package, and the attacker publishes in the central registry / repository of language packages (for PHP it is packagist.org) a package with the same name my-internal-packagehaving a higher version. The companies then installed and ran these malicious packages instead of their internal packages because their package manager was picking a higher version number from the standard package repository instead of the internal repository.

Talking about the solution to this problem for Composer and Packagist on Twitter, Geordie summarized the various measuresused by Composer and Packagist to protect companies from this serious problem:

  1. Composer package names always contain a vendor prefix, eg, my-company/our-internal-pkg… This naming convention is enforced by the command line utility and at packagist.org. Packagist.org retains the vendor name prefixes for the maintainer after their first package is published. No one else can publish another package with a vendor prefix my-company/ without the consent of the maintainer. If your company has at least one public package on packagist.org with a vendor prefix (even an empty prefix will do), for example, my-company/dummy-pkg, then attackers will not be able to create packages that match your internal package namesthat use your vendor prefix. If you request my-company/my-internal-package inside their infrastructure, attackers cannot “steal” this name from packagist.org.
  2. As of Composer 2.0, its custom repositories default canonical… This means that if a package name is found in the custom or private package repository, then only those versions will always be downloaded. If the same package name exists in lower priority repositories or on packagist.org, then it is ignored. Even if an attacker publishes a package with the same name as your inner package, in a higher version, Composer will not install it
  3. Private packagist always treated third-party mirror repositories, including those on packagist.org, as canonical, and never downloaded package information from mirrors if a private package with the same name exists. I.e Private Packagist protects users on Composer 1.x just as Composer 2 does by default
  4. Private packagist allows you to manually confirm each new mirror package from a third party repository like packagist.org before it can be installed with Composer. This is an optional feature that gives users even more control over the third-party code they use.
  5. Composer always generates a lock file (lock file) with a list of specific versions and download URL of installed dependencies. We strongly recommend that you commit the lock file to source control and use only composer install, this command only installs the specific versions listed in the lock file. You can integrate lock file change analysis into your regular workflow to ensure that no code is loaded from untrusted third-party sources.
  6. With Composer 2, you can exclude downloading package names or patterns for each repository. So you can be sure that even misspelled packages without a registered prefix on packagist.org will not be able to download from packagist.org by replacing the default configuration in composer.json. This exclusion filter can also be used for additional third-party package repositories.
    "repositories": {
        "private-repo": {
            "url": "https://my-repo.internal"
        }
        "packagist.org": {
            "url": "https://repo.packagist.org",
            "exclude": ["myprefix/*"]
        }
    }

Attacks on the supply chain similar to the ones Alex described are a serious threat to companies and have been highlighted in the news lately, so it’s important that your business understands the risks it faces and takes action to mitigate them.


Advertising

Looking for VDS for debugging projects, server for development and hosting? You are definitely our client 🙂 Daily billing of servers, create your own configuration in a few clicks, anti-DDoS and Windows licenses are already included in the price.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *