Защита от уязвимости Dependency Confusion в PHP с помощью Composer

Недавно Алекс Бирсан опубликовал статью «Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies», в которой рассказал, как использовал диспетчеры пакетов уровня языков наподобие npm (Javascript), pip (Python) и gems (Ruby), чтобы заставить компании установить и запустить в своей инфраструктуре зловредный код.

Проблема сводится к тому, что компании ссылаются на внутренние пакеты по имени, например my-internal-package, а злоумышленник публикует в центральном реестре/репозитории пакетов языка (для PHP это packagist.org) пакет с таким же названием my-internal-package, имеющий более высокую версию. После этого компании устанавливали и выполняли эти зловредные пакеты вместо своих внутренних пакетов, потому что их диспетчер пакетов выбирал версию с более высоким номером из стандартного репозитория пакетов вместо внутреннего репозитория.

Рассказывая о решении этой проблемы для Composer и Packagist в Twitter, Джорди вкратце перечислил различные меры, используемые Composer и Packagist для защиты компаний от этой серьёзной проблемы:

1. Названия пакетов Composer всегда содержат префикс поставщика, например, my-company/our-internal-pkg. Такое правило присваивания имён принудительно применяется утилитой командной строки и на packagist.org. Packagist.org сохраняет префиксы имени поставщика для мейнтейнера после публикации его первого пакета. Никто больше не может опубликовать другой пакет с префиксом вендора my-company/ без согласия мейнтейнера. Если у вашей компании есть хотя бы один публичный пакет на packagist.org с префиксом поставщика (подойдёт даже пустой префикс), например, my-company/dummy-pkg, то злоумышленники не смогут создавать пакеты, совпадающие с вашими внутренними названиями пакетов, в которых используется ваш префикс поставщика. Если вы запрашиваете my-company/my-internal-package внутри своей инфраструктуры, злоумышленники не смогут «похитить» это имя на packagist.org.
2. Что касается Composer 2.0, то его пользовательские репозитории по умолчанию каноничны. Это означает, что если имя пакета найдено в репозитории пользовательского или приватного пакета, то всегда будут загружаться только эти версии. Если то же имя пакета существует в репозиториях с меньшим приоритетом или на packagist.org, то оно игнорируется. Даже если злоумышленник публикует пакет с тем же названием, что и ваш внутренний пакет, в более высокой версии, Composer не установит его.
3. Private Packagist всегда обрабатывал сторонние зеркальные репозитории, в том числе и на packagist.org, как канонические, и никогда не загружал информацию пакетов с зеркал, если существует приватный пакет с тем же именем. То есть Private Packagist защищает пользователей на Composer 1.x так же, как это по умолчанию делает Composer 2.
4. Private Packagist позволяет вручную подтверждать каждый новый зеркальный пакет из стороннего репозитория наподобие packagist.org до того, как его можно будет установить с помощью Composer. Это дополнительная функция, предоставляющая пользователям ещё больше контроля над используемым ими сторонним кодом.
5. Composer всегда генерирует файл блокировки (lock file) со списком конкретных версий и URL скачивания установленных зависимостей. Мы настоятельно рекомендуем выполнять коммиты файла блокировки в систему контроля версий и использовать на этапах сборки только composer install, эта команда устанавливает только конкретные версии, перечисленные в файле блокировки. Можно встроить анализ изменений в файле блокировки в свой обычный рабочий процесс, чтобы гарантировать, что код не загружается из ненадёжных сторонних источников.
6. При помощи Composer 2 можно исключать загрузку имён пакетов или паттернов для каждого репозитория. Так что можно быть уверенным, что даже написанные с опечаткой несуществующие пакеты без зарегистрированного префикса на packagist.org не смогут загружаться с packagist.org с помощью замены стандартной конфигурации в composer.json. Этот исключающий фильтр можно использовать и для дополнительных репозиториев сторонних пакетов.

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

Похожие на описанные Алексом атаки на цепочку поставок являются серьёзной угрозой для компаний и в последнее время их часто начали упоминать в новостях, поэтому важно, чтобы ваш бизнес понимал риски, которым подвергается, и предпринимал меры для их устранения.

---

На правах рекламы

Подыскиваете VDS для отладки проектов, сервер для разработки и размещения? Вы точно наш клиент :) Посуточная тарификация серверов, создавайте собственную конфигурацию в несколько кликов, антиDDoS и лицензии Windows уже включены в стоимость.