[Перевод] Защита от уязвимости 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 для защиты компаний от этой серьёзной проблемы:
- Названия пакетов 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. - Что касается Composer 2.0, то его пользовательские репозитории по умолчанию каноничны. Это означает, что если имя пакета найдено в репозитории пользовательского или приватного пакета, то всегда будут загружаться только эти версии. Если то же имя пакета существует в репозиториях с меньшим приоритетом или на packagist.org, то оно игнорируется. Даже если злоумышленник публикует пакет с тем же названием, что и ваш внутренний пакет, в более высокой версии, Composer не установит его.
- Private Packagist всегда обрабатывал сторонние зеркальные репозитории, в том числе и на packagist.org, как канонические, и никогда не загружал информацию пакетов с зеркал, если существует приватный пакет с тем же именем. То есть Private Packagist защищает пользователей на Composer 1.x так же, как это по умолчанию делает Composer 2.
- Private Packagist позволяет вручную подтверждать каждый новый зеркальный пакет из стороннего репозитория наподобие packagist.org до того, как его можно будет установить с помощью Composer. Это дополнительная функция, предоставляющая пользователям ещё больше контроля над используемым ими сторонним кодом.
- Composer всегда генерирует файл блокировки (lock file) со списком конкретных версий и URL скачивания установленных зависимостей. Мы настоятельно рекомендуем выполнять коммиты файла блокировки в систему контроля версий и использовать на этапах сборки только composer install, эта команда устанавливает только конкретные версии, перечисленные в файле блокировки. Можно встроить анализ изменений в файле блокировки в свой обычный рабочий процесс, чтобы гарантировать, что код не загружается из ненадёжных сторонних источников.
- При помощи 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 уже включены в стоимость.