{"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\/it\/blog\/news\/ataka-na-npm-pozvolyayushhaya-opredelit-nalichie-paketov-v-privatnyh-repozitoriyah","title":{"rendered":"Attacco su NPM che consente di determinare la presenza di pacchetti nei repository privati","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In NPM \u00e8 stata identificata una vulnerabilit\u00e0 che consente di determinare l'esistenza di pacchetti in repository privati. Il problema \u00e8 causato da tempi di risposta differenti quando si richiede un pacchetto esistente rispetto a uno inesistente da parte di un utente esterno privo di accesso al repository. In assenza di accesso per qualsiasi pacchetto in repository privati, il server registry.npmjs.org restituisce un errore con codice «404», ma nel caso di esistenza di un pacchetto con il nome richiesto, l'errore viene restituito con un notevole ritardo. L'attaccante pu\u00f2 utilizzare questa particolare caratteristica per determinare la presenza di un pacchetto testando nomi di pacchetti tramite dizionari. <\/p>\n
La determinazione dei nomi dei pacchetti nei repository privati pu\u00f2 essere necessaria per condurre attacchi tramite miscelazione delle dipendenze, che manipola l'intersezione dei nomi delle dipendenze nei repository pubblici e interni. Sapendo quali pacchetti interni NPM sono presenti nei repository aziendali, un attaccante pu\u00f2 pubblicare pacchetti con gli stessi nomi e numeri di versione pi\u00f9 recenti in un repository pubblico NPM. Se durante la compilazione le librerie interne non sono chiaramente vincolate nelle impostazioni al proprio repository, il gestore pacchetti npm considerer\u00e0 pi\u00f9 prioritario il repository pubblico e caricher\u00e0 il pacchetto preparato dall'attaccante. <\/p>\n
GitHub \u00e8 stato avvisato del problema a marzo, ma ha rifiutato di aggiungere protezione contro l'attacco, citando limitazioni architettoniche. Alle aziende che utilizzano repository privati \u00e8 consigliato di controllare periodicamente l'emergere di nomi in conflitto nel repository pubblico o di creare a proprio nome dei placeholder con nomi che ripetono i nomi dei pacchetti nei repository privati, affinch\u00e9 i malintenzionati non possano pubblicare i propri pacchetti con nomi in conflitto. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"