Sicurezza

Open Source e APP: ci sono problemi di sicurezza?

Viviamo in un mondo App-centrico, dove a tutte le nostre necessità corrisponde un’applicazione mobile. All’inizio del 2019 erano 2,6 milioni per Android e 2.2 milioni per iOS. C’è però un problema, uno dei motivi per cui è stata così facile la proliferazione di questi software è la facilità di accesso a tool e risorse necessarie per costruirle; quasi sempre da una base open source.

A parte il codice che è stato scritto dagli sviluppatori, praticamente nessuna applicazione moderna può evitare di includere librerie open source che forniscono funzionalità che sarebbe estremamente noioso e dispendioso, in termini di tempo, scrivere da zero. Sia che si tratti di una relativamente comune libreria con un ricco set di funzionalità come OpenSSL, o una libreria JavaScript, tutto questo codice importato rappresenta una funzionalità che gli sviluppatori dovranno necessariamente gestire.

Photo credit - depositphotos.com

Esiste tuttavia ancora una certa mancanza di consapevolezza su dove e come le librerie open source vengono utilizzate. Secondo un rapporto di Veracode, il 70% delle applicazioni utilizzate oggi ha almeno una vulnerabilità di sicurezza che deriva dall’uso di questi pacchetti open source.

Le librerie open source – repository di codice gratuiti e centralizzati che forniscono “blocchi di costruzione” di applicazioni pronte per gli sviluppatori – non sono solo onnipresenti ma anche rischiose. L’analisi ha esaminato oltre 350mila librerie esterne utilizzate in 85mila applicazioni e ha rilevato che queste librerie sono estremamente comuni. Per esempio, la maggior parte delle applicazioni JavaScript contiene centinaia di librerie open source: alcune hanno più di 1000 librerie diverse. Inoltre, la maggior parte dei linguaggi presenta lo stesso insieme di librerie di base.

JavaScript e PHP in particolare hanno diverse librerie core che sono presenti in quasi tutte le applicazioni. Queste librerie, come altri software, hanno delle vulnerabilità. Il problema è che grazie al riutilizzo del codice, un singolo bug può influenzare centinaia di applicazioni.

Oggi, in quasi tutte le applicazioni, le librerie open source permettono agli sviluppatori di muoversi più velocemente aggiungendo rapidamente funzionalità di base. In effetti, sarebbe quasi impossibile innovare con il software senza queste librerie. Tuttavia, la mancanza di consapevolezza su dove e come vengono utilizzate e sui loro fattori di rischio è una pratica problematica.

Quattro librerie principali rappresentano la maggior parte dei bug open source che si trovano nelle applicazioni: Swift, .NET, Go e PHP. Swift ha un uso specializzato nell’ecosistema Apple e secondo Veracode ha la più alta densità di difetti, ma ha anche una bassa percentuale di librerie difettose in termini di volume; .NET ha, nel frattempo, la più bassa percentuale di librerie difettose delle quattro. Go ha un’alta percentuale di difetti, ma un numero complessivamente basso di vulnerabilità per ogni singola libreria, infine PHP ha un tasso di librerie difettose più alto di Go e più del doppio della densità di vulnerabilità.

L’azienda ha anche scoperto che il cross-site scripting (XSS) è la categoria di vulnerabilità più comune che si trova nelle librerie open source ed è presente nel 30% di esse. Seguono la deserializzazione insicura (23,5%) e il controllo degli accessi interrotti (20,3%). I dati hanno anche mostrato che la maggior parte delle librerie difettose finisce nel codice indirettamente: gli sviluppatori potrebbero usare una sola libreria ma, a loro insaputa, quella che stanno usando ha estratto il codice da un’altra completamente diversa per sostenerla.

Il 47% delle librerie difettose nelle applicazioni sono transitive: in altre parole, non sono inserite direttamente dagli sviluppatori, ma sono figlie della prima libreria. Questo significa che gli sviluppatori stanno introducendo molto più codice, spesso codice imperfetto, di quanto si aspettassero. La buona notizia è che affrontare le falle di sicurezza in queste librerie non è un grande sforzo.

La maggior parte dei difetti introdotti dalle librerie (quasi il 75%) nelle applicazioni possono essere affrontati con solo un aggiornamento minore della versione; non sono quindi necessari grandi aggiornamenti. È più un problema di scoperta e di tracciamento, non un’enorme rifattorizzazione del codice.