flawopen.com/Referenz/Dependency Confusion
Dependency Confusion: Verwechslungen bei Paketquellen
Stell dir vor, dein Team bestellt eine Komponente in einem Lieferantenkatalog, aber zwei Anbieter verwenden denselben Produktnamen. Wenn die Regeln den maßgeblichen Anbieter nicht festlegen, kann der Build eine unbeabsichtigte Komponente erhalten. Dependency Confusion ist ein Fehler bei der Quellenauswahl: Ein Build löst einen Paketnamen aus einer Registry oder einem Namespace auf, dem die Organisation nicht vertrauen wollte.
Wie Dependency Confusion entsteht
Das genaue Verhalten hängt vom Paketmanager und seiner Konfiguration ab. Ein konkreter Fall ist pip: Die Dokumentation warnt, dass ein privates --index-url zusammen mit einem öffentlichen --extra-index-url dazu führen kann, dass ein gleichnamiges öffentliches Paket ausgewählt wird. npm bestimmt die Registry anhand des Paket-Scopes oder der Standardkonfiguration; es vergleicht nicht grundsätzlich private und öffentliche Versionen und wählt die höhere. Ursache ist eine mehrdeutige Quellenrichtlinie. Sind Paket und Skripte aktiviert, laufen diese mit den für den Build verfügbaren Rechten.
[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"
}
}Ein möglicher Fehlerpfad
- 1Ein interner Paketname oder Namespace wird außerhalb der Organisation bekannt.
- 2Eine öffentliche Registry enthält ein gleichnamiges Paket ohne Scope oder die Quellenrichtlinie lässt diese Registry die Anfrage bedienen.
- 3Der Resolver wählt die unbeabsichtigte Quelle; ein Lockfile oder Review kann die Ersetzung übersehen, wenn die Datei fehlt, neu erzeugt oder ungeprüft akzeptiert wird.
- 4Sind Installations- oder Build-Skripte aktiviert, läuft Paketcode mit den Rechten des Build-Jobs. Die Auswirkungen hängen von Zugangsdaten, Netzwerkzugriff und Isolation ab; Root-Ausführung ist kein zwangsläufiges Merkmal dieser Angriffsklasse.
Schutzmaßnahmen für die Entwicklung
- ✓Quellenrichtlinien explizit festlegen: Nutze nach Möglichkeit organisationsgebundene Scopes oder Namespaces, leite sie an die vorgesehene Registry und verhindere für private Namen den Rückfall auf öffentliche Quellen. Bei Python sollte ein privater Index für private Pakete nicht mit
--extra-index-urlkombiniert werden; nutze einen kontrollierten Proxy oder einen einzigen maßgeblichen Index. - ✓Namespace-Eigentum kontrollieren: Reserviere Organisationsnamen, wenn die Registry das unterstützt, aber ersetze damit nicht die Richtlinie des Resolvers. Erfasse interne Namen und überwache öffentliche Namenskollisionen.
- ✓Lockfiles prüfen und erzwingen: Versioniere das Lockfile und verwende den eingefrorenen CI-Installationsmodus (bei npm
npm ci). Prüfe Änderungen an Namen, Registry-URLs, Versionen und Integritätswerten. Ein Lockfile erhöht die Wiederholbarkeit, beweist aber nicht, dass die Quelle zum erwarteten Herausgeber gehört. - ✓Build-Ausführung begrenzen: Deaktiviere Abhängigkeitsskripte, wenn das Projekt ohne sie funktioniert, und prüfe Ausnahmen. Nutze kurzlebige Zugangsdaten mit minimalen Rechten, isoliere Builds von Produktionsgeheimnissen und begrenze ausgehenden Netzwerkverkehr.