È possibile inviare il codice dannoso a NPM?
Sicuramente. Se un pacchetto deve essere compromesso (o ne viene pubblicato uno nuovo), installato e utilizzato qualsiasi codice fornito con quel pacchetto potrebbe essere eseguito. Quindi, se lo eseguono nel contesto node.js, ad esempio, l'attacco ha accesso a molte funzionalità a livello macchina come il file system, le informazioni di sistema, l'esecuzione di file, i processi, ecc. Sarebbe semplice come mettere il codice dell'attaccante su essere restituito nell'esportazione. Quindi non appena viene eseguito il require('bad-package') del codice. Ancora peggio potrebbe essere semplice come installare il modulo. Possono specificare uno script di preinstallazione nel manifest del pacchetto ed eseguire immediatamente lo script.
Il codice dannoso è stato inviato a NPM?
Di certo sicuramente di nuovo. Il 26/01/2015 un pacchetto denominato rimrafall è stato pubblicato su NPM. Lo scopo era quello di aumentare la consapevolezza del problema. Il pacchetto eseguiva un hook di preinstallazione in modo che immediatamente all'installazione rm -rf /* venisse eseguito. Rimrafall è stato rimosso entro 2 ore, ma può essere trovato su Github .
Gli sviluppatori possono mantenere se stessi e i propri utenti al sicuro?
Come sviluppatore, il solo metodo di prevenzione affidabile vicino è il blocco della versione nel package.json alle versioni conosciute per essere al sicuro. Il blocco della versione è normalmente praticato per garantire che venga utilizzata solo una dipendenza di lavoro nota e un aggiornamento delle dipendenze non testato non infrange nulla. Ma lo stesso può essere usato per respingere una versione degli attaccanti. Come hai detto, non puoi ripubblicare un file di una particolare versione. Impostando una versione esatta nelle dipendenze l'applicazione scaricherà solo questa versione. Se un utente malintenzionato doveva ottenere il controllo del pacchetto, poteva solo spingere il codice dannoso agli utenti di un pacchetto successivo. Ho detto "vicino all'affidabilità" perché se un utente malintenzionato doveva compromettere i server NPM, poteva cambiare una versione precedente in qualsiasi modo desiderasse.
Inoltre puoi impedire un attacco di script di preinstallazione utilizzando il flag --ignore-scripts durante l'installazione. Questo ti darebbe la possibilità di installare ma vedere il suo codice prima di eseguirlo. (A meno che il pacchetto contenga file binari nativi.) Prima di installare è possibile verificare la presenza di tali script eseguendo npm show $module scripts . Se vuoi lasciare il NPM fuori dal mix per rivedere lo script, puoi scaricarlo direttamente su http://registry.npmjs.org/MODULENAME/-/MODULENAME-VERSION.tgz .
L'NPM impedisce a qualcuno di rilevare un pacchetto non pubblicato?
Sì e no. Una volta che non è stato pubblicato, è presente una sospensione posta sul nome del pacchetto per evitare un abuso immediato. Tuttavia è ancora ottenibile se richiesto da NPM. In teoria, la semplice ingegneria sociale potrebbe aggirare il processo di controllo e mettere il nome del pacchetto nelle mani dell'attaccante. Di seguito è riportato un messaggio per un pacchetto non pubblicato:
This package name is not currently in use, but was formerly occupied
by a popular package. To avoid malicious use, npm is hanging on to the
package name, but loosely, and we'll probably give it to you if you
want it.
You may adopt this package by contacting [email protected] and
requesting the name.
In conclusione
Quindi, in chiusura, un utente malintenzionato potrebbe sfruttare il pacchetto non pubblicato? Sì, se la persona sbagliata ha preso rapidamente possesso di nulla era nel loro modo di spingere un aggiornamento del pacchetto con il loro codice. Ciò comprometterebbe chiunque scaricasse l'ultima versione di quel pacchetto o installasse / aggiornasse progetti che non bloccavano le loro dipendenze dalla versione.
Modifica: tieni presente che le tue dipendenze possono avere dipendenze. Così, mentre la dipendenza stessa può sembrare sicura, assicurati che non si carichi in una dipendenza non sicura di sua proprietà.