Patch delle applicazioni web: perché aggiornare non basta

Una patch è una correzione di codice che il produttore rilascia per chiudere un difetto, e nella maggior parte dei casi il difetto è una vulnerabilità già nota anche a chi la potrebbe sfruttare. Da qui la regola generale che tutti conoscono: applicarla il prima possibile.

Su un’applicazione web quella regola resta valida ma diventa insufficiente, e per una ragione strutturale. Un server ha un fornitore e un ciclo di aggiornamento; un’applicazione web è composta da decine di componenti che nessuno ha scritto in azienda — un framework, una libreria di terze parti, un plugin, un modulo del gestore dei contenuti — ognuno con un proprio produttore, un proprio calendario di rilascio e una propria probabilità di essere abbandonato. Sul patch management dei sistemi in senso generale abbiamo scritto una guida dedicata; qui il tema è cosa cambia quando l’oggetto da aggiornare è un’applicazione esposta a internet.

1. Perché il tempo conta più che altrove
2. Il problema delle dipendenze
3. Quali patch vengono prima
4. Le patch che non si possono applicare subito
5. Perché la patch non chiude tutto

Perché il tempo conta più che altrove

Quando una vulnerabilità di un componente diffuso viene divulgata, la finestra utile si misura in ore. Il caso di Log4Shell è l’esempio che tutti citano, e vale la pena ricordare perché: la libreria interessata era presente in un numero enorme di applicazioni, e la maggior parte delle aziende colpite non sapeva di averla. La patch esisteva quasi subito, ma non si applica una correzione a un componente di cui non si conosce la presenza.

È la differenza tra un sistema operativo e un’applicazione web. Del primo sapete la versione, perché ve la dichiara. Della seconda conoscete quello che avete scritto o commissionato, e non necessariamente ciò che le vostre dipendenze hanno portato con sé. Un’applicazione esposta a internet, poi, è raggiungibile da chiunque nel momento in cui la vulnerabilità diventa pubblica: non serve un accesso interno, non serve un dipendente che apra un allegato.

Da qui una conseguenza operativa: sulle applicazioni web l’inventario dei componenti conta tanto quanto la disciplina degli aggiornamenti, e nella maggior parte delle organizzazioni italiane non esiste.

Il problema delle dipendenze

Un’applicazione moderna dichiara le proprie dipendenze dirette, quelle che uno sviluppatore ha scelto consapevolmente. Ognuna di quelle, però, ne porta altre, che a loro volta ne portano altre: è la parte dell’inventario che nessuno ha deciso e che spesso costituisce la maggioranza del codice effettivamente in esecuzione.

Le conseguenze pratiche sono tre. La prima è che una vulnerabilità può riguardarvi attraverso un componente di cui non avete mai sentito il nome. La seconda è che l’aggiornamento di una dipendenza profonda dipende dal produttore di quella intermedia, che deve rilasciare prima: tra la pubblicazione della patch e la sua effettiva disponibilità per voi possono passare settimane. La terza è che un componente abbandonato dal proprio autore non riceverà nessuna correzione, e in quel caso la strada non è aggiornare ma sostituire.

C’è poi il codice sviluppato su misura, che per definizione non ha patch. Le vulnerabilità che vi risiedono non compaiono in nessun elenco pubblico e non vengono segnalate da nessun avviso di sicurezza: esistono solo nel vostro applicativo, e si trovano soltanto cercandole.

Quali patch vengono prima

Applicare tutto immediatamente non è realistico, quindi la domanda vera è l’ordine. Il criterio più diffuso è il punteggio di gravità assegnato alla vulnerabilità, ed è un punto di partenza utile ma parziale, perché descrive quanto la falla sarebbe grave in astratto e non quanto lo è nel vostro assetto.

Le variabili che cambiano l’ordine sono altre: se il componente affetto è raggiungibile da internet o soltanto da una rete interna, se la funzione vulnerabile è effettivamente utilizzata dalla vostra applicazione, se esiste già un exploit in circolazione. Un difetto classificato come critico su una libreria che non invocate mai pesa meno di uno di gravità media su un componente esposto e attivamente sfruttato — un ragionamento che abbiamo approfondito parlando di come prioritizzare le vulnerabilità e di come si valuta il livello di gravità.

Questo tipo di ordinamento richiede di sapere due cose contemporaneamente: quali vulnerabilità sono presenti e quali di esse sono raggiungibili nel vostro caso specifico. È il risultato di una verifica tecnica, non di un elenco di avvisi ricevuti dai produttori.

Le patch che non si possono applicare subito

Esiste una categoria di casi che i manuali trattano poco e che in azienda è la norma: la patch esiste, è importante, e non si può installare. Perché l’aggiornamento rompe una personalizzazione, perché il fornitore dell’applicativo non ha ancora certificato la nuova versione, perché la finestra di fermo va concordata con chi usa il servizio, perché il componente non è più mantenuto.

In queste situazioni la scelta non è tra applicare e non applicare, è tra restare esposti e ridurre l’esposizione con altri mezzi. Le strade praticabili sono limitare la raggiungibilità del componente vulnerabile, restringere i privilegi con cui viene eseguito, aumentare il livello di registrazione su quel percorso per accorgersi di un tentativo, e fissare una data per la sostituzione. Nessuna di queste equivale alla patch, e tutte sono meglio dell’attesa indefinita.

La parte che viene sistematicamente omessa è la documentazione della decisione. Una vulnerabilità nota, non corretta e non documentata è un problema tecnico che in sede di verifica diventa un problema di conformità: le discipline che chiedono un piano di gestione delle vulnerabilità non pretendono che tutto sia risolto, pretendono che si sappia cosa è aperto e perché.

Perché la patch non chiude tutto

Anche con un ciclo di aggiornamento impeccabile, una parte del rischio di un’applicazione web resta fuori dalla portata delle patch. Le vulnerabilità che dipendono da come l’applicazione è stata costruita — logiche di autorizzazione che non verificano chi sta chiedendo un dato, funzioni raggiungibili da profili che non dovrebbero vederle, parametri manipolabili per accedere a informazioni di altri utenti — non sono difetti di un componente di terze parti. Sono difetti di progettazione, e nessun produttore rilascerà mai un aggiornamento per correggerli.

È la ragione per cui la classificazione delle vulnerabilità più usata nel settore, la OWASP Top 10, contiene diverse categorie che non hanno relazione con le versioni installate: riguardano il controllo degli accessi, la gestione delle sessioni, il trattamento degli input, la configurazione. Un’applicazione perfettamente aggiornata può contenerle tutte.

Due terzi delle aree di rischio di un’applicazione web non sono raggiungibili da un aggiornamento: si individuano soltanto con una verifica sull’applicazione in esecuzione.

A questo si aggiunge la configurazione, che cambia nel tempo senza che nessuno la ricontrolli: permessi ampliati per risolvere un problema urgente e mai ristretti, ambienti di prova rimasti raggiungibili, credenziali predefinite di un modulo installato anni prima. Sono condizioni che nessuna patch modifica, perché non sono difetti del codice ma scelte fatte da qualcuno.

In conclusione

Sulle applicazioni web la gestione delle patch è necessaria e non sufficiente. È necessaria perché le vulnerabilità dei componenti di terze parti sono pubbliche, sfruttabili in poche ore e raggiungibili da chiunque. Non è sufficiente perché una parte consistente dell’esposizione di un’applicazione dipende da come è stata scritta e da come è configurata, e su quel terreno gli aggiornamenti non arrivano.

Le due cose vanno quindi tenute insieme: un ciclo di aggiornamento ordinato per gravità reale, e una verifica periodica che guardi l’applicazione per quello che è invece che per le versioni che dichiara.