Sicurezza, Javascript e NPM

La sicurezza è un tema molto caro a chiunque lavori nel campo dell’IT, ma per ovvi motivi dovrebbe esserlo anche per chiunque acceda ad un servizio in qualità di semplice utente. Non tutti sono completamente consci del fatto che ciò che ci rappresenta come persone, i nostri gusti, le nostre conoscenze, i nostri ricordi, vengono in qualche modo categorizzati e utilizzati, in quanto generano guadagni per le aziende che ci offrono lo stesso servizio di cui stiamo usufruendo: hanno quindi un valore quantificabile.

Questo assioma, su cui sostanzialmente si basa l’Internet moderno, porta con sé tutta una serie di problematiche che andrebbero trattate con grande delicatezza e attenzione, in quanto la loro stessa esistenza, data la quantità di tempo che trascorriamo davanti ad una qualsiasi interfaccia utente, ad un browser web o ad una app, ci mette in una condizione in cui i nostri dati personali sono messi costantemente a rischio.

Possiamo affermare con assoluta certezza che l’altro postulato con cui dobbiamo per forza di cose convivere nella nostra vita di fruitori tecnologici sia l’onnipresenza del linguaggio Javascript in tutte le sue forme: il WWW, nato con validi e nobili principi di diffusione della conoscenza tramite l’Ipertesto, si è poi imbastardito con l’avvento di Javascript, utilizzato inizialmente in una forma ludica, per animare le pagine, rendere dinamici i bottoni, permettere di inviare le form senza ricaricare le pagine Web. Ma ben presto ci si è resi conto della vera potenzialità del linguaggio: il poter eseguire del codice sul client. Da questo caposaldo è stato poi costruito l’Internet moderno.

Nel tempo si sono stratificate numerose soluzioni per costruire siti dinamici, sempre più simili ad applicazioni, con il notevole vantaggio di poter realizzare interfacce utente gradualmente più funzionali e complesse, ma dal comportamento coerente su qualsiasi piattaforma che supporti lo standard. Ovviamente, di pari passo all’aumentare delle funzionalità sono cresciuti i problemi: di compatibilità, di manutenzione e di uniformità.

Per questo motivo sono nati i framework: per avere una nomenclatura costante ed immutabile; per avere la certezza che le metodologie non fossero a carico dello sviluppatore, ma fossero incanalate e regolamentate da una struttura prestabilita. Questo avrebbe garantito, almeno sulla carta, la risoluzione delle tre problematiche principali, ottenendo in maniera laterale l’intercambiabilità degli sviluppatori, ma anche appiattendo le soluzioni e le modalità di approccio. Nel tempo, questo ha, in un certo qual modo, uniformato l’IT, che aveva di certo bisogno di standard da rispettare: ma la modalità con cui questa logica è stata portata avanti ha anche fatto sì che tutta una serie di problematiche e casistiche di sicurezza venissero gestite dai framework, e non fossero più a carico dello sviluppatore. Dal punto di vista dell’azienda e del mercato, questo ha aumentato la produttività, ma, guardando agli effetti a lungo termine sull’educazione tecnica degli sviluppatori del ramo, ha anche creato un ecosistema decisamente favorevole per la scoperta e lo sfruttamento di tutta una serie di problematiche di sicurezza la cui principale vittima è proprio il fruitore.

L’ultima scelta architetturale, dettata dagli stessi principi elencati sopra, è stata la decisione di portare il Javascript, un linguaggio nato anni fa, con tutta una serie di problemi endogeni, su un sistema in grado di sfruttarlo per fare girare applicazioni e servizi sul server, adducendo come principale motivazione la grande performance sull’I/O, fondamentale quindi per la natura stessa di Internet. Ma a che prezzo?

Uno dei problemi principali che nascono da questo approccio, infatti, è la gestione delle dipendenze. Data l’interconnessione totale presente oggigiornoi, non si ragiona più per sistemi isolati, ma si presuppone che l’applicazione stessa, per girare, debba sfruttare dei pacchetti che espongano delle funzionalità. Tali funzionalità, a volte, potrebbero andare a sfruttarne presenti in altri pacchetti, e così via, generando quello che in gergo si chiama dependency hell. Chiaramente, nel non dover reinventare la ruota ogni volta non si ottengono che vantaggi a livello di produttività e di gestione: ma tale modalità, insieme al graduale allontanamento dello sviluppatore dalle problematiche di sicurezza e gli effetti a lungo termine che ne derivano, a tendere crea situazioni in cui si importano pacchetti anche soltanto per dover mettere in uppercase una stringa, o per lavorare con le date. E non dimentichiamo che questa problematica, grazie ai framework come AngularJS, React o Vue.js, si sposta anche sul client.

Tutto questo ci porta alla situazione odierna, in cui un pacchetto come pac-resolver, scaricato settimanalmente più di tre milioni di volte, presenta, nelle versioni precedenti alla 5.0.0, un bug di sicurezza che permette l’esecuzione di codice in remoto. Pac-resolver ha ben 285.000 repository che lo utilizzano come dipendenza: a conti fatti, sono 285.000 progetti potenzialmente vulnerabili e che quindi permettono di eseguire codice in remoto, con tutto quello che ne consegue: installazione di malware, hijack di credenziali e cronologia di navigazione, per non parlare delle implicazioni a livello puramente economico su eventuali software wallet per criptovalute.

Un altro aspetto della centralità di repository di pacchetti come NPM.js è la possibilità di sfruttare credenziali weak del maintainer di un dato package (di nuovo, educazione alla security): da uno scan effettuato qualche tempo fa, è risultato che ben il 13% dell’intero database dei package NPM presentava password molto semplici, come “123456” o “password”: e che, dato l’ecosistema a dipendenze, queste vulnerabilità avrebbero dato ad un’ipotetico attaccante la possibilità di propagare del codice malevolo in ben il 52% dell’intero ecosistema NPM: tra i principali pacchetti compare persino Koa, un rewrite del ben conosciuto Express.io, ma mirato alla performance più che alle funzionalità, anch’esso con milioni di download.

Dove ci porterà il futuro? Dipende da molti fattori, uno fra tutti la presa di coscienza dell’attuale carenza endemica di gestione, anche solo a livello di forma mentis, della sicurezza dei dati a scapito della quantità del software prodotto e delle tecnologie che vengono definite, e successivamente propagate, da corporazioni i cui scopi principali, forse, pongono il rispetto della sfera personale dell’utente in secondo piano.

Sostenitore di lunga data dell’Open Source, Sysadmin ma anche programmatore, mi appassiona qualsiasi cosa nell’IT che possa permettere un’espressione di creatività. Nostalgico della filosofia dei tempi andati, ma incuriosito dalle potenzialità dei paradigmi moderni.

4 risposte a “Sicurezza, Javascript e NPM”

  1. Avatar Alessio Carotenuto

    Per favore levate il logo di Java che con JavaScript non ha niente a che vedere. Ora leggo l’articolo.

  2. Avatar Raoul Scarazzini

    No, prima fai una petizione per togliere il nome Java da JavaScript, poi noi si corregge il logo 😀 😀 😀 Io partecipo con un suggerimento per il nuovo nome: WebPageScript.
    Scherzi a parte: purtroppo un logo ufficiale per JavaScript non esiste, pertanto l’unica alternativa è usare uno di quelli esistenti, come questo.

  3. Avatar Alessio Carotenuto

    Intendiamoci il sito e vostro e potete fare quel che volete ma quello è il logo ufficiale di Java e probabilmente quello che avete postato è stato fatto da un buontempone. In ogni caso appoggio la tua proposta per il nuovo nome 🙂

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *