Preventing dependency confusion in PHP with Composer

Click for: original source

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

The problem boils down to companies referencing internal packages by name, e.g. “my-internal-package” and an attacker then publishing a package by the same name “my-internal-package” with a higher version number on the central registry / package repository for that language (for PHP that would be packagist.org).

    "repositories": {
        "private-repo": {
            "url": "https://my-repo.internal"
        }
        "packagist.org": {
            "url": "https://repo.packagist.org",
            "exclude": ["myprefix/*"]
        }
    }

The article then describes what Composer and Packagist have in place to help protect companies from this serious problem:

  • Composer package names always include a vendor prefix
  • As of Composer 2.0 custom repositories are canonical by default
  • Private Packagist has always treated third party mirrored repositories including packagist.org as canonical and never loaded package information from mirrors if a private package by that name exists
  • Private Packagist allows you to manually approve each newly mirrored package
  • Composer always generates a lock file
  • With Composer 2 you can exclude package names or patterns from loading for each repository

Supply chain attacks like the ones described by Alex are a serious threat to businesses and have frequently shown up in the news recently, so it is important that your business understands the risks it is exposed to and takes measures to mitigate them. Good read!

[Read More]

Tags php software web-development open-source app-development