flawopen.com/Referência/Dependency Confusion

Dependency Confusion: como ocorrem confusões na origem dos pacotes

Como ocorre Dependency Confusion

O comportamento exato depende do gerenciador e da configuração. Um caso concreto é o pip: a documentação alerta que combinar um --index-url privado com um --extra-index-url público pode permitir a seleção de um pacote público com o mesmo nome. O npm escolhe o registry pela scope do pacote ou pela configuração padrão; não compara universalmente versões privadas e públicas para escolher a maior. A causa comum é uma política de origem ambígua. Se o pacote for instalado e seus scripts estiverem habilitados, eles executam com as permissões disponíveis para a tarefa de build.

[global]
index-url = https://packages.example.internal/simple
extra-index-url = https://pypi.org/simple

corp-auth-utils

@corp:registry=https://packages.example.internal/repository/npm/

{
  "dependencies": {
    "@corp/billing-engine": "1.2.0"
  }
}

Um caminho de falha de Dependency Confusion

• 1O nome de um pacote interno ou namespace torna-se conhecido fora da organização.
• 2Um registry público contém um pacote com o mesmo nome sem scope, ou a política configurada permite que essa origem atenda à solicitação.
• 3O resolvedor seleciona a origem não pretendida; o lockfile ou a revisão podem não detectar a substituição se o arquivo faltar, for regenerado ou aceito sem inspeção.
• 4Se scripts de instalação ou build estiverem habilitados, o código do pacote é executado com as permissões da tarefa. O impacto depende de credenciais, rede e isolamento; execução como root não é inerente a essa classe de ataque.

Controles de engenharia defensiva

• ✓Explicite a política de origem: use scopes ou namespaces da organização quando houver suporte, encaminhe-os ao registry pretendido e impeça fallback para fontes públicas em nomes privados. Em Python, evite combinar um índice privado com --extra-index-url para pacotes privados; use um proxy controlado ou um único índice autoritativo.
• ✓Controle a propriedade do namespace: reserve nomes da organização nos registries quando possível, mas não trate a reserva como substituta da política de resolução. Mantenha um inventário de nomes internos e monitore colisões públicas.
• ✓Revise e imponha lockfiles: versione o lockfile e use o modo de instalação congelado/CI do gerenciador (no npm, npm ci). Revise nomes, URLs de registry, versões e valores de integridade. Um lockfile melhora a repetibilidade; não prova que a origem pertence ao publicador esperado.
• ✓Limite a execução do build: desative scripts de dependências quando o projeto funcionar sem eles e revise exceções. Use credenciais curtas e com privilégios mínimos; isole o build dos segredos de produção e limite a saída de rede.

Referências

• pip install — package index and dependency-confusion warning
• npm docs — scopes and registry selection
• npm docs — npm ci
• npm docs — lifecycle scripts
• CWE-829 — Inclusion of Functionality from Untrusted Control Sphere
• CWE-1395 — Dependency on Vulnerable Third-Party Component