{"id":105307,"date":"2022-10-14T15:36:38","date_gmt":"2022-10-14T13:36:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/ataka-na-npm-pozvolyayushhaya-opredelit-nalichie-paketov-v-privatnyh-repozitoriyah"},"modified":"2022-10-14T15:36:38","modified_gmt":"2022-10-14T13:36:38","slug":"ataka-na-npm-pozvolyayushhaya-opredelit-nalichie-paketov-v-privatnyh-repozitoriyah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/ataka-na-npm-pozvolyayushhaya-opredelit-nalichie-paketov-v-privatnyh-repozitoriyah","title":{"rendered":"Angriff auf NPM, der es erm\u00f6glicht, das Vorhandensein von Paketen in privaten Repositories zu erkennen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In NPM wurde eine Schwachstelle entdeckt, die es erm\u00f6glicht, die Existenz von Paketen in gesch\u00fctzten Repositories zu ermitteln. Das Problem resultiert aus unterschiedlichen Reaktionszeiten bei der Abfrage eines existierenden und eines nicht existierenden Pakets durch einen externen Benutzer, der keinen Zugang zum Repository hat. Bei fehlendem Zugang zu irgendeinem Paket in privaten Repositories gibt der Server registry.npmjs.org einen Fehler mit dem Code \u201e404\u201c zur\u00fcck, doch im Fall der Existenz eines Pakets mit dem angeforderten Namen tritt der Fehler mit sp\u00fcrbarer Verz\u00f6gerung auf. Ein Angreifer k\u00f6nnte diese Besonderheit nutzen, um das Vorhandensein eines Pakets durch das Ausprobieren von Paketnamen aus W\u00f6rterb\u00fcchern zu bestimmen. <\/p>\n
Die Definition von Paketnamen in geschlossenen Repositories kann erforderlich sein, um eine Angriffsfl\u00e4che durch Dependency-Mixing zu schaffen, die die \u00dcberschneidung von Abh\u00e4ngigkeitsnamen in \u00f6ffentlichen und internen Repositories manipuliert. Wenn ein Angreifer kennt, welche internen NPM-Pakete in den Unternehmens-Repositories vorhanden sind, kann er Pakete mit denselben Namen und neueren Versionsnummern im \u00f6ffentlichen NPM-Repository bereitstellen. Wenn die internen Bibliotheken bei der Erstellung nicht explizit auf ihr Repository festgelegt sind, betrachtet der Paketmanager npm das \u00f6ffentliche Repository als vorrangig und l\u00e4dt das vom Angreifer pr\u00e4parierte Paket herunter. <\/p>\n
GitHub wurde im M\u00e4rz \u00fcber das Problem informiert, weigerte sich jedoch, einen Schutz gegen den Angriff hinzuzuf\u00fcgen, da architektonische Einschr\u00e4nkungen vorliegen. Unternehmen, die private Repositories nutzen, wird empfohlen, regelm\u00e4\u00dfig nach \u00fcberschneidenden Namen im \u00f6ffentlichen Repository zu suchen oder von ihrem Namen Platzhalter mit Namen zu erstellen, die den Namen der Pakete in den privaten Repositories entsprechen, um zu verhindern, dass Angreifer ihre Pakete mit \u00fcberschneidenden Namen platzieren. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"