Quello che si è visto oggi sul sito dell'INPS ha tutto l'aspetto di un problema tecnico legato a un errore di configurazione della cache: il tentativo di "dare la colpa agli hacker" mi pare oltremodo debole e può essere un precedente pericoloso.
(thread)
lastampa.it/cronaca/2020/0…
(thread)
lastampa.it/cronaca/2020/0…
Riassumendo in un tweet quello che è successo: oggi il sito dell'INPS, preso d'assalto da oltre 100 richieste al secondo, ha cominciato a restituire agli utenti pagine relative ad altre sessioni (ovviamente contenenti dati personali) ad ogni reload. /2
La causa di questo "insolito" comportamento è presumibilmente da ricondurre all'errata configurazione di un sistema di cache (reverse proxy o CDN), magari installato proprio in previsione dell'atteso incremento di accessi benché ancora non sufficientemente testato. /3
Questi sistemi, per dirla in breve, hanno il compito di memorizzare i contenuti richiesti dagli utenti per un certo lasso di tempo e servirli al posto del sito, risparmiando a quest'ultimo il compito di dover rispondere più volte alla stessa richiesta. /4 
Come si può facilmente comprendere si tratta di un sistema molto efficace quando si ha a che fare con un gran numero di utenti che richiede l'accesso *agli stessi contenuti*, come ad esempio immagini, home page, news, pagine di presentazione del servizio, FAQ e così via. /5
Si tratta però di una strategia inadeguata, o per meglio dire insufficiente, quando il gran numero di accessi riguarda contenuti privati, personalizzati ovvero specifici per ciascun utente. In quel caso la cache HTTP, che resta valida per gestire i contenuti comuni a tutti, /6
dovrebbe accompagnarsi ad accorgimenti infrastrutturali basati su scale-up (potenziamento dei server), scale-out (adozione di architetture distribuite) e load balancing (distribuzione del carico), nonché a una cache di secondo livello volta a ridurre il carico sui database. /7
In questo modo i contenuti comuni a tutti ("pubblici") vengono messi in cache e restituiti dai proxy, mentre quelli "privati" continuano ad essere gestiti a livello applicativo, sia pure in modo più efficiente, evitando che possano erroneamente finire in cache. /8
Quel poco che s'è visto oggi consente di ipotizzare, con le cautele del caso, che questo pattern non sia stato seguito e che i contenuti "privati" dei singoli utenti finissero anch'essi in cache e quindi serviti anche agli utenti immediatamente successivi (in luogo dei loro). /9
Si tratta di un errore di configurazione piuttosto comune quando si mette "sotto reverse proxy" (o sotto CDN) un sito che fa largo uso di richieste AJAX, specie se implementate con framework che gestiscono le XMLHttpRequest ad alto livello (es. JQuery) senza adeguati test. /10
Se davvero è andata così, è bene precisare che errori di questo tipo non hanno nulla a che spartire con il volume di traffico o con qualsivoglia attacco hacker: si tratta semplicemente di sviste, solitamente legate alla fretta e alla mancanza di controlli adeguati. /11
In conclusione: chiamare in causa gli hacker, anche nell'ipotesi in cui vi fossero stati attacchi perimetrali in parallelo, mi sembra estremamente fuorviante e - soprattutto - ben poco rispettoso nei confronti dell'utenza vittima di questo fastidiosissimo data breach. /12
Peraltro chiunque lavori nell'IT security e abbia una certa esperienza di siti ad alto traffico sa perfettamente che questi portali subiscono attacchi (manuali e automatici) con cadenza ormai pressoché costante: pensate che INPS non subisca attacchi DDOS ogni settimana? /END
