Le applicazioni che costituiscono la stragrande maggioranza degli stack tecnologici ipercomplessi di oggi dipendono fortemente da codice di terze parti. Sfortunatamente, i vantaggi significativi offerti da questi componenti prefabbricati sono spesso compromessi dalle gravi implicazioni sulla sicurezza dell’architettura di terze parti.
È essenziale che le aziende moderne non solo riconoscano questi rischi, ma contribuiscano anche attivamente ad arginare il flusso di attacchi. Strumenti all’avanguardia, inclusa una soluzione WAF di prossima generazione, potrebbero essere l’unico modo per garantire l’esistenza di terze parti.
1. Codice di terze parti: perché reinventare la ruota?
Il codice di terze parti descrive tutte le righe di un programma che possono essere riprodotte in diverse applicazioni. Ciò semplifica il processo di sviluppo di un'app, poiché il riciclo del codice può ridurre significativamente il tempo di immissione sul mercato. Ma anche una volta gettate le basi di un'app, il codice di terze parti può essere sfruttato dai suoi sviluppatori per il monitoraggio degli annunci, le recensioni dei clienti, i pagamenti, i chatbot, la gestione dei tag, l'integrazione dei social media o altre librerie di supporto che semplificano le funzioni comuni.
La pura utilità e disponibilità del codice di terze parti lo ha visto infiltrarsi in ogni angolo di Internet: oggi, il codice di terze parti costituisce fino al 70% di ogni sito web. Nello stesso sondaggio, il 99% degli intervistati ha affermato che i siti utilizzati e prodotti dalla propria organizzazione contengono almeno un elemento di codice di terze parti.
L'open source descrive un tipo di codice di terze parti, sebbene il termine terze parti si riferisca anche a codice sviluppato esternamente, la cui licenza d'uso potrebbe essere stata acquistata. Qualunque sia il prezzo commerciale di questo codice, le aziende hanno per troppo tempo ignorato i costi sociali e di sicurezza.
2. Il pericolo nascosto del codice fantasma
Il codice di terze parti si presta allo sviluppo di siti e applicazioni altamente accessibili. Sebbene questi ambienti senza codice o a basso codice contribuiscano ad abbassare la barriera di ingresso per imprenditori e hobbisti entusiasti, è essenziale comprenderne i rischi. I criminali informatici sono più che disposti a trarre vantaggio da sviluppatori ingenui o imprudenti. A volte non è la mancanza di competenze che consente loro di infiltrarsi, ma la forte pressione per un rapido dispiegamento.
Dal 2015 gli aggressori raggruppati sotto l'egida di Magecart sfruttano codici di terze parti. Questo sindacato criminale si basa sul furto di carte di credito digitali, rubate inserendo segretamente codice JavaScript nelle pagine di pagamento dell'e-commerce. Magecart ha seminato una scia di distruzione con una posta in gioco impressionante: Ticketmaster, British Airways e innumerevoli altri marchi online sono caduti preda dei loro attacchi.
Nel 2020 si sono verificati due attacchi di alto profilo: sono stati presi di mira il produttore di abbigliamento per bambini Hanna Andersson e il rivenditore britannico Sweaty Betty. Si ritiene che entrambi gli attacchi abbiano avuto a che fare con componenti aggiuntivi del sito apparentemente innocui. Tuttavia, nascoste in queste righe di codice, gli aggressori di Magecart aggiungono alcune righe chiave di JavaScript.
Questo codice di terze parti spesso copia moduli di pagamento legittimi su un sito di e-commerce. Tuttavia, sono stati apportati cambiamenti cruciali, minuscoli. Ad esempio, le informazioni di pagamento vengono inviate segretamente a un server controllato dall'aggressore. La transazione stessa è ancora autorizzata, il che significa che gli utenti finali sono lasciati all’oscuro.
L'aggressione a Hanna Andersson passò inosservata per diverse settimane, anche se la scoperta fu relativamente rapida, mentre le altre vittime rimasero all'oscuro per quasi un anno. La maggior parte delle vittime viene avvisata solo quando i dati della carta di credito rubata compaiono sui mercati del dark web.
Il costo è significativo: Hanna Andersson è stata condannata a pagare 400.000 dollari di danni a più di 200.000 clienti; il costo esatto per le singole vittime è più difficile da determinare, ma rubare il loro nome, indirizzo di spedizione, indirizzo di fatturazione e informazioni sulla carta di pagamento consente agli aggressori di causare danni incredibili. Gli attacchi Magecart sono diventati sempre più popolari durante la pandemia di Covid-19, registrando un aumento del 20%, mentre il tempo medio di rilevamento ha raggiunto i 22 giorni.
Magecart può rappresentare codice dannoso di terze parti, ma anche il codice open source testato può causare accidentalmente uno dei maggiori problemi di sicurezza di questo decennio. Log4j descrive una libreria di registrazione open source che è diventata uno dei pezzi più importanti dell'architettura web, responsabile della trasmissione di informazioni di registrazione vitali al team di sviluppo e manutenzione.
Nel 2021, tuttavia, si è scoperto che la libreria log4j era gravemente vulnerabile all'esecuzione di codice in modalità remota. Centinaia di milioni di dispositivi vengono quindi messi seriamente a rischio, poiché la falla è anche relativamente semplice da sfruttare.
Non è realistico rinunciare completamente al codice di terze parti. Oltre il 60% dei siti web mondiali viene eseguito su server Apache e Nginx e il 90% dei manager IT utilizza regolarmente codice open source aziendale. Tutto il software moderno è costruito a partire da componenti preesistenti e ricostruire queste funzioni da zero richiederebbe ingenti investimenti di tempo e denaro per produrre anche applicazioni relativamente semplici.
3. Non puoi farla franca con una patch.
Una volta integrato in un'applicazione, il codice di terze parti può essere difficile da testare e ancora più difficile da proteggere. Le correzioni dipendono interamente dagli sviluppatori; Anche per gli sviluppatori attivi e ben intenzionati, come quelli che mantengono la funzionalità log4j, le correzioni richiedono una quantità di tempo critica.
Non temere: una soluzione di sicurezza completa può offrire molteplici strumenti per applicare virtualmente le patch e, in definitiva, fermare gli aggressori sul loro cammino. Uno di questi strumenti è il Web Application Firewall (WAF). Si interpone tra l'applicazione e l'utente finale, monitorando e filtrando il traffico in transito. I WAF di prossima generazione offrono la creazione automatica di policy, nonché una rapida propagazione delle regole, per espandere esplicitamente la rete di sicurezza di cui ha bisogno il codice di terze parti.
Mentre il WAF tradizionale si concentra principalmente sul monitoraggio delle connessioni esterne, WAAP (Web Application and API Protection) descrive una suite di protezione più completa. Incorpora l'approccio basato su firewall al WAF, concentrandosi maggiormente sulle API. Queste parti di codice forniscono accesso programmatico a diverse applicazioni e storicamente rappresentano un importante punto debole nelle difese delle organizzazioni.
Infine, l'autoprotezione delle applicazioni runtime (RASP) offre un passo successivo convincente verso la protezione automatizzata. Invece di trovarsi all'esterno del codice dell'applicazione, RASP agisce come un plugin, collegandosi alle parti interne dell'applicazione. Attraverso la visione interna di un'applicazione, RASP può monitorarne i comportamenti e mappare accessi e privilegi tipici che si verificano dietro le quinte. Una volta stabilito un comportamento di base, RASP può rilevare automaticamente – e, soprattutto, fermare – comportamenti sospetti.
Con una suite proattiva di misure di patch virtuali in atto, la tua sicurezza è in grado di tenere il passo con DevOps, contribuendo al tempo stesso a negare la minaccia dei criminali informatici e le conseguenti azioni legali.