Per anni, le organizzazioni orientate alla cybersecurity hanno cercato di convincere i team di sviluppoad elevare la sicurezza nel processo di sviluppo delle applicazioni. Ciò ha portato alla creazione di discipline moderne come DevSecOps, un modo per costruire codice e app migliori e più sicure.
Nonostante questi sforzi, e in barba agli avvertimenti degli analisti e degli esperti di cybersecurity, il codice vulnerabile di terze parti continua a trovare la sua strada nel DevOps e nel processo di sviluppo delle applicazioni, creando app che sono vulnerabili agli attacchi e allo sfruttamento da parte di truffatori e attaccanti sofisticati.
L’uso del cosiddetto “codice ombra” (script di terze parti e librerie di codice utilizzate per aiutare a creare rapidamente applicazioni web con poco riguardo alla sicurezza) continua ad essere un problema importante per molte imprese e organizzazioni.
Un recente studio pubblicato da Osterman Research e dalla società di sicurezza PerimeterX, condotto tra maggio e giugno, ha incluso le risposte di circa 800 professionisti della sicurezza e sviluppatori, scoprendo che il 99 per cento degli intervistati ha riferito che i siti web utilizzati nella loro organizzazione contengono almeno uno script di terze parti.
Più della metà degli intervistati ha riferito che tale codice di terze parti si aggiorna quattro o più volte ogni anno, ma solo circa un terzo, tuttavia, ha dichiarato di avere la capacità di rilevare le modifiche o gli aggiornamenti fatti sull’app, i quali potrebbero potenzialmente portare a un problema di sicurezza.
Ancora più importante, circa il 50 per cento degli intervistati non è stato in grado di dire se le loro applicazioni mobili erano state oggetto di un attacco. Ciò sembrerebbe dimostrare che l’utilizzo di codice di terze parti non testato è una minaccia informatica anche se aggiunge velocità al processo DevOps.
“Il codice ombra vulnerabile può essere devastante, laddove consenta di introdurre vulnerabilità tra cui l’esecuzione di codice remoto in cui un attaccante può iniettare richieste appositamente elaborate alle applicazioni che vengono eseguite come codice”, ha dichiarato Archie Agarwal, il fondatore e CEO della società di sicurezza ThreatModeler. “Tutto ciò rende possibile rivelare informazioni sensibili che risiedono nei database”.
Il rapporto di Osterman Research ha scoperto che gran parte del codice di terze parti viene utilizzato per accelerare lo sviluppo di applicazioni, e potrebbe essere sfruttato dagli sviluppatori per una serie di scopi, tra cui il monitoraggio degli annunci, i pagamenti, le recensioni dei clienti, i chatbot, la gestione dei tag, l’integrazione dei social media o altre librerie helper che semplificano le funzioni comuni.
Aggiungendo questa funzionalità, tuttavia, gli sviluppatori stanno sottoponendo le loro applicazioni mobili a vari tipi di attacchi, tra cui lo skimming delle carte e le cosiddette operazioni Magecart che sono progettate per inserire il codice nei siti di check-out e-commerce e rubare le informazioni delle carte di credito e di pagamento dai consumatori.
Il codice ombra sotto forma di librerie open-source vulnerabili e codice di terze parti ha il potenziale di aprire le applicazioni ad attacchi che potrebbero potenzialmente rivelare informazioni personali identificabili degli utenti. Il che va ben oltre i nomi e gli indirizzi, naturalmente, quando consideriamo alcune tipologie di app come quelle per la salute. Se questo tipo di informazioni private è esposto, c’è l’onere per l’organizzazione di informare l’organismo di regolamentazione pertinente che può avere gravi implicazioni finanziarie e di reputazione.
Sulla scia della campagna di cyber-spionaggio che ha preso di mira SolarWinds e i suoi clienti, il modo in cui gli attori delle minacce possono manipolare il codice utilizzato in varie app ha sollevato preoccupazioni.
Kevin Dunne, presidente della società di sicurezza Pathlock, ha notato che l’uso di codice di terze parti apre le organizzazioni a tre problemi di sicurezza specifici:
- Il rischio che una terza parte possa visualizzare i dati sul sito dell’organizzazione;
- Il rischio che una terza parte possa accedere direttamente al sito o alla rete dell’organizzazione;
- E il rischio che le librerie di codice ombra e gli script possano diventare non supportati, il che può influire sulla funzionalità del sito dell’organizzazione.
Un’ombra sul mercato di app mobili.
Tutto ciò apre i dati dei clienti e altri dati personali alla potenziale esposizione e al furto e, di conseguenza, portare all’infrazione del Regolamento generale sulla protezione dei dati dell’UE.
Se il codice ombra consente a una terza parte di visualizzare inconsapevolmente i dati sul sito di un’organizzazione, probabilmente mette l’organizzazione in difficoltà nel mantenere la conformità GDPR o CCPA, perché un processore di dati sconosciuto sta visualizzando i dati senza rivelazione pubblica”, ha detto Dunne a Dice. “Questo può comportare milioni di dollari di multe potenziali per un’organizzazione che è tenuta a mantenere questo tipo di conformità alla privacy dei dati”.
Mentre l’uso continuo di codice ombra e altri script e librerie di terze parti sembrerebbe dimostrare che concetti come DevSecOps non funzionano, gli esperti di sicurezza dicono che i risultati dello studio dimostrano esattamente perché le organizzazioni devono attenersi a questi principi di sviluppo di app migliori e più sicure.
“Il mio consiglio per gli sviluppatori che cercano di incorporare la sicurezza nelle loro applicazioni sarebbe quello di attenersi alle librerie approvate dalla loro organizzazione”, ha detto a Dice Taylor Gulley, consulente senior per la sicurezza delle applicazioni di nVisium. “Questo, oltre a rivedere il codice – o ottenere un secondo set di occhi per farlo – è fondamentale per la sicurezza. Infine, assicuratevi di trovare opzioni attivamente mantenute e basi di codice che sono ampiamente utilizzate”.
Parte di questo include anche essere consapevoli delle vulnerabilità nel codice e tenersi al corrente dei vari avvisi di sicurezza. Gulley nota anche che non sono solo i progetti oscuri che hanno codice difettoso che potrebbe essere sfruttato.
“Diffidate dei progetti popolari, perché quelli hanno più probabilità di essere l’obiettivo di un attacco e sono spesso grandi con una superficie di attacco più ampia”, ha detto Gulley. “Questo non significa non usare tali librerie, ma assicurarsi che passino attraverso un’ampia revisione di sicurezza del codice e delle sue dipendenze in modo ricorsivo”.
Caitlin Johanson, direttore dell’Application Security Center of Excellence presso la società di consulenza Coalfire, ha notato che le organizzazioni e i loro team di sviluppo devono definire l’uso, il monitoraggio e l’aggiornamento di piattaforme, librerie e componenti – e che queste politiche devono essere applicate. Questo aiuta a garantire che quando gli aggiornamenti di sicurezza vengono pubblicati, sono responsabilmente lavorati nell’applicazione e nell’ambiente sottostante, ha aggiunto Johanson.
“Il problema che stiamo vedendo tutti è che anche quando uno sviluppatore ha esplicitamente incluso librerie specifiche, spesso, quelle librerie dipendenti hanno le proprie librerie dipendenti”, ha detto Johanson a Dice. “Questo è dove l’associazione di ‘codice ombra’ colpisce veramente a casa per noi. I casi in cui una pagina di un sito web include un singolo file JavaScript da qualche altra parte, ma quell’unica dipendenza finisce per caricarne altri 20 da varie altre destinazioni… è facile vedere quanto velocemente il codice diventa ingestibile”.
