in lingua italiana

#INPSDown: alla ricerca della causa scatenante

Schema di funzionamento della cache

Stamattina la parte del sito dell’INPS che serve per richiedere il bonus di 600 euro per l’emergenza coronavirus è andata giù. Anzi: qualcuno entra con i propri dati e si trova le informazioni di altri utenti. Un fatto gravissimo per la privacy.

Spoiler: gli hacker non c’entrano niente. Dire che è colpa di attacchi hacker significa solo “buttarla in caciara”.

Come è possibile, tecnicamente, che accadano certe cose? Non avendo mai messo piede nella pubblica amministrazione e men che meno negli uffici informatici dell’INPS, non lo sappiamo. Però, sulla base dell’esperienza e di qualche informazione raccolta in giro, ci sentiamo di fare un’ipotesi, sottolineando appunto che si tratta di un’ipotesi.

Un fatto certo è che si tratta di un problema di cache, ovvero il fatto che in qualche modo il server sia stato indotto a salvare dei dati e darli al primo utente che accede, senza generare daccapo la pagina.

Il punto è questo: ci si aspettava un carico molto elevato di accessi al sito (per un sito normale). Ciò anche per via della comunicazione iniziale sul fatto che le richieste sarebbero state accolte in ordine cronologico qualora fosse terminato il budget. (Questo click day è forse stato smentito dopo dal presidente dell’INPS… Già questo è assurdo). Dunque è stato ragionevole voler inserire degli accorgimenti per evitare che il sito andasse giù. Ma il tempo è poco, quindi i problemi sono dietro l’angolo.

Nella tecnologia presumibilmente usata per il sito (ASP.NET) esiste un accorgimento di questo tipo e si chiama “Output Cache”. Vale a dire che un utente entra e visita una pagina web ed allo stesso tempo il server centrale mantiene in memoria quella stessa pagina web, cosicché potrà darla (senza “ricrearla da zero”) al prossimo utente che vorrà visitarla. Piccolo problema: io sono l’utente X e richiedo una pagina web, ci sono delle parti del sito che sono uguali per tutti, ma altre che differiscono fra me e l’utente Y. Se l’utente Y entra, per esempio, sulla pagina dell’anagrafica prima di me, può darsi che l’ultima versione cachata dal server sia proprio la sua e quindi a me vengano mostrati i suoi dati. Si può evitare questa cosa? Ovviamente sì.

PS: Potrebbe trattarsi anche di una qualche variabile globale statica lasciata alla deriva… Ma ci rifiutiamo di pensarci. Gli hacker russi ci hanno assicurato che non è così 😀

Se la ricostruzione fosse esatta si spiegherebbe anche perché la richiesta del bonus non va a buon fine: perché l’utente X ha fatto login ed il server lo sa, ma la richiesta contiene dei dati (cachati) dell’utente Y.

Questa è solo un’ipotesi tecnica, che andrà confermata o smentita.

Si tratta di un’ipotesi sufficiente, ma non necessaria. Di sicuro, se fosse andata come abbiamo supposto, allora i risultati sarebbero stati esattamente quelli che si sono ottenuti oggi, cioè scambi di identità e una volta ogni tanto per fortuna si beccano i propri dati e si riesce a fare la richiesta. Ma potrebbero esserci altre spiegazioni e magari ancora più sofisticate. Di sicuro niente hacker.

Una variante (pur molto simile) di questa ipotesi prevede che abbiano usato un meccanismo di cache più “semplice” che non salva la pagina web per intero ma solo alcuni dati. In vista del picco di richieste potrebbero aver aggiunto altri server in parallelo per velocizzare. Nel farlo però si deve stare molto attenti alla cache: può accadere che la richiesta dell’utente parta dal suo computer ed arrivi ad uno dei server, che a sua volta chiama la sua cache. A questo punto cliccando su un’altra pagina si può finire su un server diverso che ha una cache diversa e quindi mostra dati sballati. Questo potrebbe spiegare anche perché nei video pubblicati sui social i nomi si ripetono ciclicamente.

Se io fossi un hacker però… La seconda parte è qui

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.