Le librerie Javascript obsolete presentano un rischio per la mia applicazione web?

L'uso di qualsiasi software obsoleto è intrinsecamente un rischio per la sicurezza; eventuali difetti rattoppati tra la versione che stai utilizzando e l'ultima versione può essere sfruttata. Ad esempio, forse c'è un payload specifico che puoi alimentare per causare un loop infinito, potenzialmente causando un evento Denial of Service (DOS), o forse c'è un bug che può in qualche modo rompere la sandbox JavaScript e provocare il caos nel sistema.

Non vedo alcun problema di sicurezza critico menzionato su Internet, ma ciò non significa che non esistano o non siano stati corretti. È sempre consigliabile utilizzare l'ultima versione quando possibile, ma questo può anche includere testare il codice con la nuova versione per assicurarsi che non si interrompa in termini di funzionalità quando si aggiorna (ad esempio, le versioni principali sono spesso incompatibili con le versioni principali precedenti ).

Il modo migliore per mantenere aggiornate le tue librerie è usare il pacchetto da una toolchain che fornisce aggiornamenti con un clic. Ad esempio, se copi la libreria sul tuo server locale utilizzando npm install , puoi importarli direttamente (cloudflare fornirà protezione per il tuo sito se li usi). Da lì, aggiornare le tue librerie è facile come npm update dal terminale della riga di comando.

Si consiglia vivamente di utilizzare una suite TDD (Test Driven Development), come Mocha , per assicurarsi che i propri script non si interrompano quando le librerie vengono aggiornate, oltre a ridurre in genere la possibilità che si interrompa il codice durante lo sviluppo. Inoltre, ricorda di utilizzare un repository (come git o subversion) in modo che tu possa ripristinare le modifiche se l'aggiornamento di npm fa sì che la roba si interrompa.

Dipende.

Se la nuova versione è rilasciata come patch per qualsiasi problema di sicurezza trovato nella vecchia libreria, utilizzarla è un rischio.

Ma JavaScript è un linguaggio lato client. Quindi, rischia il tuo server solo se c'è un difetto nelle funzioni di richiesta Ajax.

La libreria JS da http fonti potrebbe causare altri problemi, ma da https non creerà nessun altro problema.

Un'altra cosa da notare è che, come sviluppatore web, leggere attentamente il registro di migrazione prima dell'aggiornamento. Perché se qualche funzione è deprecata e hai usato la funzione nella tua pagina, non funzionerà correttamente.

Dipende dalle vulnerabilità (conosciute) nella libreria JavaScript obsoleta. Spesso le versioni più recenti risolvono anche problemi di sicurezza (minori).

Un ottimo elenco per controllare la tua libreria, è uno strumento chiamato Retire.js .

Si noti inoltre che l'uso di una rete di distribuzione dei contenuti (CDN) come CloudFlare potrebbe essere un rischio minore in sé. Perché teoricamente possono cambiare il contenuto del JavaScript che è incluso nella tua pagina. Per mitigare questo tipo di rischio, consiglierei di verificare l'integrità delle risorse secondarie (SRI).

Dico di no, ecco perché. Le librerie eseguono semplicemente il codice che il browser consente loro. Non dovrebbero mai essere in grado di fare cose cattive. Se una lib rivela un problema di sicurezza non lo stai usando correttamente (la gestione degli input ex utente su un modello), o ha rivelato una vulnerabilità browser . Ad ogni modo, sandbox e policy dovrebbero proteggere dagli script dannosi.

L'unica eccezione che posso pensare sarebbe la crittografia lato client, che dovrebbe essere mantenuta e non essere presa alla leggera. Gli autori delle librerie non sono esperti di sicurezza, motivo per cui è così importante che il browser sia la polizia. Durante una partenza incerta, gli ultimi anni hanno visto i browser fare un ottimo lavoro, specialmente ora che i plugin come pdf e flash sono diminuiti.

Un ultimo pensiero: mi riferisco esclusivamente alle librerie javascript basate sul browser lato client; se hai librerie obsolete per un server come node.js, YES, possono succedere cose brutte!

EDIT: include server esterni accanto al tuo; CDN, siti partner, annunci, ecc. Se un exploit web si verificava senza un server, non sarebbe davvero un exploit. Ci sono occasionalmente problemi di sottofondo con il browser / plug-in / etc, ma il codice che viene eseguito su di essi non ha la responsabilità di correggerli: i fornitori lo fanno.