Quasi tutto il software chiama pi\u00f9 livelli di librerie di terze parti. Supponiamo, per esempio, che un programma Java invochi una funzione da una libreria standard per formattare una data. Quella funzione potrebbe a sua volta chiamare una funzione da un’altra libreria che capisce il calendario. E quella funzione ne chiama un’altra, e cos\u00ec via.
\nE se una falla di sicurezza in una di queste librerie profondamente annidate viene resa pubblica? Il vostro programma \u00e8 ora a rischio di compromissione, e un malintenzionato pu\u00f2 entrare nel server su cui il vostro programma \u00e8 in esecuzione–anche se non avete introdotto un vostro bug.
\nCi sono molti scanner che vi aiutano a trovare le vulnerabilit\u00e0 nelle dipendenze, ma la loro gestione comporta alcune sottigliezze. Vedremo il processo in questo articolo.
\nFonti di informazioni sulle falle
\nTutti noi siamo protetti da una lontana rete di esperti di sicurezza che sottopongono il software a tutti i tipi di test tortuosi per rivelare falle pericolose, e riportano queste falle agli sviluppatori. I loro test possono essere semplici come lanciare input insoliti ad una funzione per vedere se la funzione si confonde e permette ad un intruso di prendere il controllo del programma. Un’interessante disciplina chiamata “fuzzing” sottopone grandi quantit\u00e0 di caratteri generati casualmente ai programmi, ed \u00e8 sorprendentemente efficace nel trovare bug e vulnerabilit\u00e0. Ci sono anche strumenti di analisi completi che cercano problemi sospetti nel codice stand-alone (analisi statica) o in un programma in esecuzione (analisi dinamica).
\n Naturalmente, anche i ricercatori meno ben intenzionati sono alla ricerca di tali falle, con l’obiettivo di creare exploit malevoli per i clienti dei governi e gruppi transomware. Anche se le falle di sicurezza non ancora note al pubblico (zero day exploit) sono pericolose, la maggior parte degli attacchi utilizza falle che sono pubblicamente note, e che le vittime hanno permesso di rimanere sui loro sistemi. Siate certi che gli attori malintenzionati stanno leggendo le liste pubbliche delle falle.
\nLe falle pubblicamente note sono pubblicate su database mantenuti da organizzazioni di sicurezza, in particolare il database CVE (Common Vulnerabilities and Exposures). Il National Institute of Standards and Technology (NIST), una delle principali agenzie governative statunitensi per gli standard nel software e altrove, mantiene il National Vulnerability Database, che aggiunge pi\u00f9 dettagli agli exploit nel database CVE. Un altro sforzo recente per raccogliere le falle conosciute nelle librerie di software libero \u00e8 il database Open Source Vulnerabilities (OSV). E alcuni progetti offrono raccolte specifiche di vulnerabilit\u00e0 rilevanti, come il Python Packaging Advisory Database.
\nNon dovete leggere ossessivamente la sempre crescente lista di vulnerabilit\u00e0; ne vengono scoperte cos\u00ec tante ogni giorno che non potreste nemmeno stare al passo con loro. Per ogni linguaggio di programmazione popolare, \u00e8 possibile eseguire uno strumento per cercare automaticamente le liste e dirvi cosa \u00e8 stato scoperto per tutte le librerie che la vostra applicazione utilizza. Vedere il sito di GitLab per una lista di strumenti automatici. GitHub offre anche controlli automatici attraverso un servizio chiamato Dependabot.
\n\u00c8 conveniente usare gli strumenti offerti da GitLab e GitHub perch\u00e9, con pochi click, puoi far eseguire il controllo nei punti chiave del tuo ciclo di sviluppo. Ma non \u00e8 necessario essere su GitLab o GitHub per eseguire gli strumenti. Puoi integrarli manualmente nel tuo ciclo di sviluppo. I programmi Java e .NET possono anche usare lo strumento OWASP Dependency-Check.
\nQuando dovreste eseguire uno strumento? Se potete tollerare il tempo che aggiunge ad un check-in, vi suggerisco di eseguirlo su ogni check-in che potete. In primo luogo, potreste aver aggiunto un nuovo pacchetto alla vostra applicazione durante le vostre ultime modifiche, e se il pacchetto \u00e8 difettoso, vorreste saperlo subito in modo da poter prendere i passi elencati in questo articolo per risolvere il problema. In secondo luogo, le nuove vulnerabilit\u00e0 vengono scoperte cos\u00ec spesso che vi capiter\u00e0 regolarmente di scoprire un nuovo problema in un pacchetto che prima andava bene.
\nCome minimo, eseguite un controllo automatico delle vulnerabilit\u00e0 prima di un passo importante nel ciclo di vita, come il controllo della qualit\u00e0 o il deployment. Non volete entrare in una fase importante del ciclo di vita con una vulnerabilit\u00e0, perch\u00e9 correggerla diventa molto pi\u00f9 costoso.<\/p>\n
L’esecuzione di scanner di vulnerabilit\u00e0 su base regolare \u00e8 una parte centrale di DevSecOps, una pratica di tendenza che integra la sicurezza nel ciclo di vita dell’applicazione. Alcuni ambienti normativi, tra cui sia la CIA che l’FBI, richiedono scansioni che seguono il Security Content Automation Protocol (SCAP). SCAP \u00e8 stato sviluppato dal NIST e ha un’implementazione open source chiamata Open SCAP.
\nFacili correzioni
\nHai scoperto una vulnerabilit\u00e0! Speriamo che la correzione sia rapida e indolore. Se gli sviluppatori del pacchetto hanno rilasciato una nuova versione con la correzione, tutto quello che dovete fare \u00e8 ricostruire la vostra applicazione usando la versione corretta. Naturalmente, ogni modifica ad un pacchetto introduce potenzialmente nuovi problemi, quindi \u00e8 necessario eseguire i test di regressione dopo l’aggiornamento.
\nUna tendenza sofisticata nella costruzione del software \u00e8 rappresentata da Project Thoth, uno strumento open source sviluppato da Red Hat per trovare librerie sicure per applicazioni Python. (Thoth non si limita ad estrarre l’ultima versione stabile di ogni libreria usata dall’applicazione; consulta vari database pubblici e cerca di raccomandare una combinazione di pacchetti che funzionino insieme senza difetti. Lo stesso approccio \u00e8 stato copiato dagli sviluppatori di altri linguaggi di programmazione.
\nSe non c’\u00e8 ancora una nuova versione che ha risolto la vulnerabilit\u00e0 del software, forse potete trovare una vecchia versione della libreria che non contiene la vulnerabilit\u00e0. Naturalmente, se la vecchia versione ha altre vulnerabilit\u00e0, non vi aiuter\u00e0 molto. E se la vecchia versione sembra soddisfare le vostre esigenze, dovete assicurarvi di non dipendere dalle caratteristiche aggiunte alle nuove versioni, e di nuovo dovete eseguire i vostri test di regressione.
\nDeterminare la portata di un difetto
\nSupponiamo che le soluzioni suggerite nella sezione precedente non siano disponibili. Siete bloccati a costruire il vostro programma con una libreria che ha una falla di sicurezza identificata. Ora sono necessarie alcune ricerche e ragionamenti sottili.
\nGuardate le circostanze che possono innescare una violazione. Molti exploit sono teorici quando i ricercatori di sicurezza li segnalano, ma possono diventare rapidamente reali. Quindi leggete il rapporto di vulnerabilit\u00e0 per vedere i requisiti che un attaccante deve avere per diventare un rischio. Hanno bisogno di un accesso fisico al vostro sistema? Hanno bisogno di essere superuser (root)? Una volta che diventano root, probabilmente non hanno bisogno di sfruttare la vostra falla per creare il caos. Potreste decidere che \u00e8 improbabile che un attaccante sia in grado di eseguire l’exploit nel vostro particolare ambiente.
\nAlcuni scanner automatici di vulnerabilit\u00e0 sono apertamente sensibili. Potrebbero segnalare qualcosa come un problema, ma voi potreste decidere che non \u00e8 un problema nel vostro caso.<\/p>\n
Potreste anche essere in grado di inserire pi\u00f9 controlli per garantire che la falla non venga sfruttata. Supponiamo che un argomento passato alla funzione vulnerabile sia la lunghezza di un buffer, e che l’exploit sia un rischio solo se tale argomento \u00e8 negativo. Naturalmente, la lunghezza di un buffer dovrebbe essere sempre zero o positiva. Il vostro programma non chiamer\u00e0 mai legittimamente la funzione con un valore negativo in quell’argomento. Potete rafforzare la sicurezza aggiungendo questo prima di ogni chiamata alla funzione:
\n\u00a0\u00a0\u00a0 if (argument < 0)\n, exit; \nAltri exploit funzionano iniettando caratteri che non dovrebbero mai essere usati in input legittimi, quindi potete controllare questi caratteri prima di passare input alle funzioni. Alcuni linguaggi, seguendo un'innovazione introdotta molti anni fa in Perl, marcano le variabili a rischio come \"contaminate\" in modo da sapere che le avete controllate per violazioni della sicurezza.\nPotrebbe essere pi\u00f9 facile aggiungere un controllo per l'input pericoloso in un proxy dell'applicazione o in un altro wrapper, invece di inserire tali controlli in tutta l'applicazione.\nQuesto workaround dovrebbe essere temporaneo, perch\u00e9 i manutentori della libreria dovrebbero risolvere presto il bug.\nSe nessuno ha condiviso questo workaround con la comunit\u00e0, aggiungete un commento al problema che ha riportato la falla, e offrite la vostra soluzione agli altri.\nA proposito, potreste determinare che la falla riportata colpisce una funzione che non state chiamando. Ma fate attenzione, perch\u00e9 potreste chiamare qualche altra funzione nella libreria che chiama indirettamente la funzione insicura. Ci sono strumenti di tracciamento e profilazione che vi permettono di guardare l'intera gerarchia delle chiamate di funzione nella vostra applicazione, cos\u00ec potete vedere se siete a rischio.\nForse siete proprio nel mirino degli attaccanti: state usando una funzione con una falla che non potete aggirare. Quindi considerate: avete bisogno della funzione con la falla? Ci sono spesso librerie alternative che offrono funzioni simili. Oppure l'uso particolare che state facendo della funzione potrebbe essere abbastanza semplice per voi da codificarla da soli. Ma scrivere la propria versione della funzione \u00e8 una cattiva idea, perch\u00e9 \u00e8 pi\u00f9 probabile che introduciate dei bug piuttosto che risolvere il problema. Dopo tutto, siete anche meno esperti di codifica sicura dei manutentori della libreria. (Se siete pi\u00f9 esperti di loro, aiutateli a sistemare la libreria!)\nC'\u00e8 anche la possibilit\u00e0 che vi sentiate abbastanza sicuri delle vostre capacit\u00e0 di codifica, e che abbiate abbastanza familiarit\u00e0 con il pacchetto che state usando, per offrire una correzione di bug. Questa \u00e8 un'opzione solo per i pacchetti open source, ma spero che stiate usando pacchetti open source ogni volta che potete.\nNon voglio concludere senza ricordare che la difesa in profondit\u00e0 \u00e8 sempre importante. Per esempio, se la vostra applicazione \u00e8 per uso interno, le regole del firewall e l'autenticazione dovrebbero assicurare che state comunicando solo con utenti legittimi. D'altra parte, anche un utente interno potrebbe essere malintenzionato, o potrebbe essere compromesso da un estraneo che lo usa come passaggio per entrare nel vostro server. Quindi un'applicazione sicura \u00e8 ancora necessaria.\nConclusione\nLe falle di sicurezza sono un rischio costante nello sviluppo del software, e sono tutte intorno a noi. Dovete stare attenti a queste vulnerabilit\u00e0, perch\u00e9 una falla nel vostro sistema potrebbe permettere un attacco ransomware, il furto di dati sensibili dei clienti, lo sfruttamento del vostro sistema in una botnet, o qualche altro brutto risultato. Cercate di non essere vittime.\nMa ci sono cos\u00ec tante falle che non potete semplicemente assumere l'atteggiamento di eliminare ogni libreria contro cui \u00e8 stata segnalata una falla. Se \u00e8 disponibile un aggiornamento, installatelo prontamente. Negli altri casi, spero che questo articolo vi abbia aiutato a prendere decisioni ragionevoli per preservare la vostra sicurezza.\n\u00a0\n\n<\/p>\n","protected":false},"excerpt":{"rendered":"