Pacchetto NPM dannoso: si adatta a OWASP Top Ten 2017?

Question

Pacchetto NPM dannoso: si adatta a OWASP Top Ten 2017?

#1 da (1 voti)

5

Su vari forum di sicurezza ho visto collegamenti a un post su un NPM malizioso fittizio pacchetto di informazioni sulla raccolta. Il titolo dei post:

I’m harvesting credit card numbers and passwords from your site. Here’s how.

La migliore citazione nel post a mio parere:

Lucky for me, we live in an age where people install npm packages like they’re popping pain killers.

Ciò ha portato a una discussione presso la nostra azienda, indipendentemente dal fatto che un pacchetto NPM malevolo si inserisca o meno in OWASP Top Ten 2017 oppure no. Penso che possa rientrare nelle seguenti categorie:

A6: 2017 Configurazione errata della sicurezza
La descrizione dice: "Non solo tutti i sistemi operativi, i framework, le librerie e le applicazioni devono essere configurati in modo sicuro ...". Se hai una libreria malevola che può fare qualcosa perché il tuo CSP non è configurato correttamente, ad esempio, lo farei rientrare in questa categoria.
A7: 2017-Cross-Site Scripting (XSS)
Se la libreria abilita una vulnerabilità XSS rientrerebbe in questa categoria.
A9: 2017-Utilizzo dei componenti con vulnerabilità note
Se la libreria è nota per essere dannosa, rientrerebbe in questa categoria.
A10: 2017 - Registrazione e monitoraggio insufficienti
Se l'attacco non viene rilevato significa che non stiamo registrando abbastanza. Esistono varie librerie per la registrazione di JavaScript lato client e le richieste in uscita potrebbero essere verificate qui. Ovviamente la libreria malevola potrebbe tentare di disabilitarlo ma potrebbe comunque rientrare in questa categoria.

È corretto o è un pacchetto NPM dannoso al di fuori dell'ambito di OWASP Top Ten 2017?

npm web-application owasp package-manager owasp-top-ten

posta Ogglas 10.01.2018 - 09:37

fonte

1 risposta

Leggi altre domande sui tag npm web-application owasp package-manager owasp-top-ten

iTunes Account ha unito il gruppo Famiglia senza autorizzazione I processori AMD K8 potrebbero non essere vulnerabili a Spectre?

score 1 · Answer 1

Mi sembra chiaro che una libreria codificata maliziosamente è coperta perfettamente da A9: 2017-Utilizzo di componenti con vulnerabilità note . Pensavo che A9 fosse stato creato per questo caso molto utile.

Sebbene la dicitura di OWASP parli di librerie più vecchie che hanno scoperte vulnerabilità nel tempo (Heartbleed) e sostituite, non c'è nulla nel testo che suggerisca che questo debba essere il motivo della vulnerabilità. La codifica intenzionale intenzionale funziona altrettanto bene che un motivo.

Potrebbe sorgere un dibattito sull'opportunità o meno che la "codifica malevola" possa essere equiparata a una "vulnerabilità" poiché il codice dannoso potrebbe funzionare come previsto senza effetti indesiderati. Penso che questo dibattito sia un po 'pedante e lo spirito della Top 10 di OWASP è supportato dall'equazione tra le due idee.

Le librerie con codici maligni non sono una "configurazione errata". Una libreria mal configurata è una libreria che non è di per sé vulnerabile, ma introduce vulnerabilità dovute a un uso improprio.

Le librerie con codici maligni potrebbero introdurre vulnerabilità XSS, ma A7 è troppo specifico in questo caso.

La registrazione e il monitoraggio insufficienti sono una meta questione che riguarda tutte le potenziali situazioni ed è troppo ampia per essere applicabile a questo scenario di minaccia.