Регистрация

[Информационная безопасность, PHP, Программирование] Защита от уязвимости Dependency Confusion в PHP с помощью Composer (перевод)

Ответить на тему
Автор Сообщение
news_bot ®

Стаж: 6 лет 3 месяца
Сообщений: 27286

Создавать темы news_bot ® написал(а)
16-Фев-2021 13:34
Цитировать


Недавно Алекс Бирсан опубликовал статью «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 уже включены в стоимость.

оригинал
 ===========
 Источник:
habr.com
===========
 ===========
 Автор оригинала: Nils Adermann
===========Похожие новости: Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_php, #_programmirovanie (Программирование), #_dependency_confusion, #_php, #_composer, #_blog_kompanii_vdsina.ru (
Блог компании VDSina.ru
), #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_php, #_programmirovanie (
Программирование
)
Профиль  ЛС 
Показать сообщения:     
Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 10-Май 16:35
Часовой пояс: UTC + 5