Dependency confusion и тайпсквоттинг

Dependency confusion: побеждает старшая версия в общем пространстве имён

Когда пакетный менеджер разрешает имя, он спрашивает у реестра доступные версии и по умолчанию предпочитает старшую, удовлетворяющую диапазону. Ловушка в том, что «реестр» часто во множественном числе: многие конфигурации трактуют публичный реестр (npm, PyPI) как fallback (резервный источник, опрашиваемый при неудаче в основном) в том же пространстве имён, что и приватный. Так что если твой внутренний пакет acme-internal-utils существует приватно на 1.4.0, а атакующий публикует публичный пакет с идентичным именем на 99.0.0, резолвер сравнивает их в одном пространстве имён и берёт старшую версию — версию атакующего.

Единственная предпосылка для атакующего — твоё внутреннее имя. А эти имена утекают постоянно: package.json, закоммиченный в публичный репозиторий, дерево зависимостей, напечатанное в CI-логе, путь в стек-трейсе, вставленном в issue. Ничто из этого не секрет и ничто из этого не ощущается как уязвимость — пока не станет семенем атаки.

# Что резолвер по сути делает для БЕЗ-scope внутреннего имени:
#   запрос к приватному реестру  -> acme-internal-utils@1.4.0   (твой)
#   запрос к публичному  реестру -> acme-internal-utils@99.0.0  (атакующего, выше)
#   "побеждает старшая версия"   -> ставит 99.0.0 из публичного
# Затем install/postinstall-скрипт исполняется с секретами и сетью CI-джобы.

Полезная нагрузка исполняется потому, что пакетные менеджеры запускают lifecycle-скрипты (postinstall, preinstall — хуки, автоматически вызываемые пакетным менеджером до и после установки) во время установки по дизайну — именно так нативные модули собираются. На CI-раннере это значит, что код атакующего исполняется со всем, что держит джоба: токены реестра, облачные креды, возможность дотянуться до внутренних хостов. Корневая причина структурна, а не баг: единое пространство имён разрешения, где публичный реестр — тихий fallback и побеждает старшая версия, тогда как твои внутренние имена не зарезервированы публично.

Фикс, который реально закрывает дыру: scope + пиннинг реестра

Решающая защита — сделать твои внутренние имена неразрешимыми из публичного реестра, чтобы сравнение выше вообще не происходило. Делаешь это, помещая внутренние пакеты под scope (@acme/...) и пинуя этот scope к приватному реестру в .npmrc:

# .npmrc — scope @acme НИКОГДА не проваливается в публичный реестр
@acme:registry=https://registry.internal.acme.com
//registry.internal.acme.com/:_authToken=${INTERNAL_NPM_TOKEN}

Теперь запрос на @acme/utils маршрутизируется только во внутренний реестр. Резолвер даже не спрашивает публичный реестр об этом scope, так что нет никакого публичного @acme/utils@99.0.0, чтобы победить — ловушка сравнения версий устранена структурно. Для легаси без-scope внутренних имён эквивалент — гарантировать, что резолвер никогда не проваливается в публичный для них (прокси, который fail-closed, или миграция их под scope). Приватность реестра не то же самое, что изоляция пространства имён; изоляцию даёт только пин.

Lockfile, integrity и install-скрипты: слои под пином

Пин закрывает пространство имён; ещё три слоя ограничивают радиус поражения, если что-то всё же проскочит.

Коммить lockfile и ставь через npm ci, а не npm install. npm install имеет право разрешать — он может подтянуть новую старшую версию и переписать lockfile, ровно то поведение, которое эксплуатирует dependency confusion. npm ci ставит только то, что зафиксировано в lockfile, и проверяет каждый артефакт против хэша integrity (SHA субресурсной целостности, записанный во время лока). Если реестр отдаёт подменённый артефакт под ту же версию, проверка хэша падает и установка прерывается.

# npm install: может разрешить старшую версию и ПЕРЕПИСАТЬ lockfile (окно атаки)
npm install

# npm ci: ставит ТОЧНО зафиксированные версии, проверяет каждый integrity-хэш, падает на несовпадении
npm ci --ignore-scripts   # а также отказывает lifecycle-скриптам, где билд это позволяет

Отключай install-скрипты, где можешь (--ignore-scripts). Рычаг вредоносного пакета почти всегда — его postinstall; если скрипты не бегут, подменённый или сконфуженный пакет — это инертный код на диске, а не исполняемый код. Скрипты переразрешаешь намеренно для тех немногих зависимостей, которым реально нужна компиляция.

Тайпсквоттинг: атака-сестра на тот же шаг установки

Dependency confusion целится в твои имена; тайпсквоттинг целится в популярные имена. Атакующий публикует пакеты на одну опечатку от чего-то известного — expresss, lodahs, crossenv — и ждёт, пока разработчик ошибётся в команде установки или скопирует опечатку из блога. Засквоттенный пакет затем запускает тот же вредоносный install-скрипт. Защита слоится иначе, потому что нет scope, который можно запинить: проверяй точное имя перед установкой, прогоняй установки через приватный прокси-реестр (Artifactory, Verdaccio), отдающий только проверенные пакеты из allow-list, сканируй зависимости инструментами (Socket, npm audit) и пинни всё через lockfile, чтобы опечатка не могла тихо попасть в воспроизводимый билд.