⚠️ SQL Injection, XSS e CSRF come non te li hanno mai spiegati prima

Immaginate di aver deciso di lanciare finalmente la vostra attività online. Dopo mesi di pianificazione, vi rivolgete a uno sviluppatore che promette di realizzare per voi un sito e-commerce completo a un prezzo stracciato. Il sito viene consegnato in una settimana, sembra professionale e funziona perfettamente. Iniziate a ricevere i primi ordini e tutto va liscio per qualche mese. Poi una mattina aprite il vostro sito e rimanete di sasso. Il vostro catalogo prodotti è sparito, sostituito da una marea di pubblicità pubblicità di farmaci illegali e casinò online. Quel che è peggio è che la vostra email aziendale è piena di messaggi di clienti che dicono di aver ricevuto addebiti strani e mail di phishing apparentemente provenienti da voi. In poche ore la situazione precipita ulteriormente: Google rimuove il vostro sito dai risultati di ricerca, i clienti chiedono risarcimento, un consulente privacy vi dice che devono essere fatte notifiche alle autorità per segnalare il data breach. Il vostro sito web è appena stato vittima di un attacco hacker che combinando varie tecniche diverse è riuscito a ottenere accesso al vostro database dei clienti, a modificare le pagine del sito e a ingannare i vostri utenti. Cerchiamo di capire bene cos'è successo. Ciao a tutti e benvenuti in questo nuovo video. Ammetto che ho un po' procrastinato negli ultimi mesi perché l'hackeraggio dei siti web doveva essere oggetto di uno dei primissimi video, ma l'ho sempre rimandato. Il motivo è semplice: è un tema veramente molto complesso e non sapevo da che parte farmi per affrontarlo. Oggi finalmente mi sono decisa, per cui andremo con calma a spezzettare l'argomento e a renderlo masticabile a chiunque, anche perché è un tema che interessa veramente tutti noi. Se state pensando "a me non frega niente, tanto io non ho un sito web, non ho neanche intenzione di aprirne uno", vi rispondo che alcune tecniche di attacco sono rivolte non al sito in sé, ma all'utente che lo visita, quindi quindi domani se YouTube fosse hackerato ad andarcene di mezzo potreste essere voi. In ogni caso, visto il tema e inevitabilmente anche la lunghezza del video, vorrei dire a chiunque arriverà in fondo: hai tutta la mia stima. Ma andiamo con ordine. Ogni volta che visitate un sito web è come se entraste in un edificio, per esempio una banca. Quando entriamo in banca vediamo la sala d'attesa, vediamo gli operatori agli sportelli e così via, no? In un sito web questa parte si chiama front end ed è appunto quella che vediamo, è l'home page, page, sono le varie pagine, i prodotti se siamo su un e-commerce e cose di questo tipo. Ora, non è che un sito web finisce lì, in quelle pagine, così come una banca non è solo la sala d'attesa. In una banca, ad esempio, ci sono degli uffici sul retro, noi sappiamo che sono lì, sappiamo che ci lavorano persone che non danno servizi direttamente al pubblico, ma si occupano di questioni più delicate, come decidere se una persona può ottenere un mutuo e cose di questo tipo. Questa parte in un sito web si chiama back-end, Noi non la vediamo, ma serve a prendere le richieste che noi mandiamo al sito, come la richiesta di autenticarci con username e password, e decidere se acconsentire oppure no. Infine, in ogni banca c'è un altro posto molto importante che è il cavò, un posto che normalmente viene protetto con una grandissima attenzione perché è dove si trovano le riserve di denaro e di preziosi della banca. Se siete un rapinatore, è proprio il cavò il posto a cui più di tutti vorreste avere accesso, perché quello in assoluto importante. Anche i siti web hanno il loro cavò che si chiama database. È dove vengono raccolte tutte le informazioni più importanti come le password degli utenti, i dati delle loro carte di credito, i loro indirizzi, il riepilogo degli ordini fatti e cose di questo tipo. Non tutti i siti web hanno un database, a volte abbiamo dei siti che sono semplicemente informativi e non hanno bisogno di raccogliere e conservare i dati degli utenti. Questi siti li possiamo paragonare più che a una banca a una galleria d'arte dove entriamo, guardiamo e usciamo e abbiamo finito. Anche questi comunque possono essere interessanti per dei malintenzionati, ma ci arriviamo con calma. Ora, un ladro che vuole rubare dei soldi a una banca può farlo in vari modi. Una cosa che può fare, ad esempio, è puntare tutto sull'entrare nel cavo della banca e fare tantissimi soldi tutti in una volta, ma con maggiore sforzo, perché deve studiare bene l'ambiente, capire come funziona la sorveglianza, qual è il momento migliore per colpire, eccetera. Oppure può decidere di mettersi fuori dalla banca e rapinare tutte le persone che hanno appena prelevato dei soldi. Oppure ancora può entrare e truffare il cassiere senza minacce né nulla, convincendolo a dargli dei soldi che in realtà non gli spettano. Insomma, di modi per rubare ce ne sono diversi, e ci sono anche diversi modi per hackerare un sito web. La tecnica più famosa si chiama SQL injection. Partiamo proprio dal termine stesso: injection significa iniezione, mentre SQL, che è l'acronimo di Structured Query Language, è il linguaggio che i computer usano per comunicare con i database. Usando questo linguaggio il computer prende l'attività dell'utente, quindi i comandi che vengono dati, e li traduce in comandi per il database. Ad esempio gli dice di aggiungere nuovi dati o leggere, aggiornare o cancellare quelli già esistenti. Per fare un esempio, Amazon ha un database enorme con tutti i nostri dati di acquisto, quindi carte di credito, indirizzo, eccetera. Se io apro Amazon, eseguo la procedura per cambiare il mio metodo di pagamento, il mio il computer prende questa procedura, la converte in comandi SQL e dice al database: guarda, cancella la carta che usava Veronica Paolucci per pagare e sostituiscila con quest'altra. Già negli anni '90, quindi parliamo degli albori dei siti web, gli utenti più smanettoni si erano resi conto che il linguaggio SQL poteva essere usato anche per forzare un sito a fare cose che teoricamente non doveva fare. Il giorno di Natale del 1998 28 su una rivista per hacker di nome FRAC, un ricercatore di sicurezza descrisse la tecnica che oggi chiamiamo SQL injection. Questo ricercatore spiegò che nei campi input di un sito web, quelli in cui ad esempio scriviamo le nostre credenziali per accedere, potevano essere inseriti dei comandi SQL che costringevano il database a fare quello che volevamo. In realtà pare che già alcuni anni prima ci fossero stati incidenti riconducibili col senno di poi a questa tecnica, ma appunto nel 1998 per la prima volta venne spiegato come funzionava. Prendiamo proprio l'esempio dei campi username e password. Quando io inserisco le mie credenziali, il sito prende il mio username e la mia password e li inserisce all'interno di un comando SQL tipo questo: SELECT FROM utenti WHERE username Mario AND password 1234. Questo comando serve a dire: seleziona dalla sezione utenti del database il profilo in cui lo username è Mario e la password è 1234. Quindi il sito dice al database: dimmi se trovi una corrispondenza, quindi dimmi se c'è qualcuno che ha lo username Mario abbinato alla password 1234. Il database dice: sì, c'è, l'ho trovato, e il sito web ci fa accedere. Oppure il database dice: no, guarda, non c'è nessuno che ha questo username abbinato a questa password, perché magari ho sbagliato a digitare, e il sito mi dice username o password errata. Un hacker che usa la tecnica di SQL injection nel campo username non scrive Mario, ma scrive ad esempio apostrofo punto e virgola DROP TABLE utenti punto e virgola meno meno. Analizziamo un attimo questo comando. L'apostrofo iniziale serve a dire il campo username è finito, perché normalmente il sito prende lo username inserito e lo mette fra virgolette. Quindi se io come prima cosa chiudo le virgolette, dico al database Il campo username è vuoto. Il punto e virgola serve a separare più comandi SQL, quindi lo inserisco per dire al database: il comando che serve a verificare lo username dell'utente è finito, adesso ti inserisco un altro comando che devi eseguire. La scritta DROP TABLE utenti è un altro comando SQL che dice al database: elimina tutta la tabella degli utenti. Poi metto un altro punto e virgola per dire: è finito anche questo comando. E termino con il meno meno per dire: tutto quello che viene dopo puoi ignorarlo. Il sito web pensa pensa che tutto questo sia semplicemente il mio nome utente, perché io l'ho inserito appunto nel campo username. Quindi cosa fa? Prende questa scritta e la concatena all'interno del comando classico che darebbe al database. Il comando diventa SELECT FROM utenti WHERE username vuoto, punto e virgola, quindi nuovo comando, DROP TABLE utenti, punto e virgola, meno meno. Il database obbedisce perché è abituato a ricevere comandi dal sito web, quindi prima seleziona seleziona un campo vuoto nella tabella utenti, perché gli avevo detto seleziona il campo dove username è vuoto. Poi fa il secondo comando, quindi elimina tutta la tabella utenti. Per capire meglio quello che è successo, torniamo all'esempio della rapina in banca. La SQL injection è come se un malintenzionato riuscisse a convincere un dipendente a dargli una somma di denaro. Se io chiamo un dipendente e gli dico ciao, puoi trasferire sul mio conto 1 milione di euro prendendoli dal conto di qualcun altro? Lui mi ride in faccia. Ma se io lo chiamo fingendo Raggiungendomi un collega di un'altra filiale e uso il linguaggio giusto, ad esempio gli dico: "Guarda, mi serve che tu faccia un'operazione di tipo D26 sul conto numero 2294775, il codice di autorizzazione è X4GH6". Insomma, se io capisco qual è il linguaggio giusto da usare, il linguaggio tecnico tipico di questa operazione, e lo uso, posso ingannarlo e convincerlo a fare quello che chiedo. È la stessa identica cosa che succede con la SQL injection. Gli hacker usano il linguaggio che il database è in grado di capire e applicare e riescono a forzarlo a fare quello che normalmente non farebbe. Torniamo alla nostra storia. Quando viene pubblicato questo articolo a Natale del 1998, fra l'altro proprio in un momento in cui i siti web e le applicazioni stavano iniziando a diffondersi, la tecnica della SQL injection diventa un'arma molto usata sia dai malintenzionati veri e propri sia da semplici curiosi o vandali. Inizia quindi anche a essere studiata il modo di impedire che questa cosa si verifichi, perché di fatto un criminale informatico con i comandi giusti poteva leggere tutti i dati nel database, modificarli, cancellarli o addirittura prendere il controllo completo del sistema. Io vi ho fatto l'esempio DROP TABLE utenti, ma chiaramente lì nel mezzo come comandi poteva essere inserito veramente qualunque cosa. Il problema nasce dal fatto che i computer non pensano, non ancora. Se ricevono qualcosa che sembra un'istruzione valida, la eseguono. Non è che cercano di capire se alla base ci sono cattive intenzioni. Se a loro arriva una richiesta che usa il linguaggio giusto, sono a posto. Qual era quindi l'obiettivo di chi stava studiando modi per evitare che gli attacchi basati su SQL injection andassero a buon fine? Quello di far sì che al computer, al database, non arrivassero tutte le richieste in modo così indiscriminato, perché altrimenti venivano eseguite sia le richieste legittime che quelle malevole. Si dovevano inserire dei filtri, dei blocchi che pulissero quello che l'utente inseriva sul sito, in modo che al database arrivassero solo le richieste legittime. In pratica si doveva fare in modo che il dipendente della banca non eseguisse ciecamente un ordine solo perché era contenuto nel modulo giusto o era presentato con il linguaggio corretto. Dovevano essere inserite procedure di verifica sugli ordini dati. Mentre i ricercatori di sicurezza studiavano questa cosa e cercavano soluzioni contro la SQL injection, alcuni ingegneri Microsoft scoprirono un'altra minaccia ancora più grave. Quello di cui si accorsero gli ingegneri alla fine del 1999, quindi veramente 5 minuti dopo che era stata scoperta la SQL injection, era che su internet stavano comparendo delle pagine web con all'interno dei tag script, cioè pezzetti di codice JavaScript. JavaScript è il linguaggio che rende le pagine web interattive, ad esempio quelle che regolano i menu a tendina, i pulsanti che aprono finestre, i moduli che si tornano senza ricaricare la pagina. JavaScript quindi rende più belle le pagine web, è uno strumento molto utile, molto conosciuto, e i browser, quindi il nostro Chrome, il nostro Safari, Firefox, eccetera, lo eseguono in automatico perché lo considerano parte del sito. Quindi appena un browser vede un tag script con delle istruzioni, prende e lo esegue. I criminali informatici, che ormai usavano la SQL injection come dei pro, avevano scoperto che i campi input potevano essere usati non solo per iniettare delle richieste da mandare al database, ma anche per iniettare questo codice JavaScript. Vi faccio un esempio per capire meglio. Se io vado in un negozio online che vende solo calzini spaiati e scrivo una recensione normale tipo "bel prodotto", il sito salva il mio commento e lo mostra a tutti. Se voi state cercando dei calzini spaiati, capitate su quel sito e andate a vedere i commenti, vedrete anche la mia recensione. Quello che i criminali hanno capito da questa cosa era che chiunque poteva modificare l'esperienza utente degli altri, perché la mia recensione ha cambiato il modo in cui voi vedete il sito web. Quindi se anziché scrivere "bel prodotto" io scrivo un pezzo di codice JavaScript, il sito salva anche quello e il browser di tutti gli utenti vede il mio commento con il codice malevolo. Ma cosa fa un browser quando vede un codice JavaScript? Non lo lascia lì scritto e basta, lo esegue. Quindi voi non vedete un commento con scritta roba strana in un linguaggio di programmazione, voi non vedete nulla, ma il sito fa cose che non dovrebbe fare. Quindi, a differenza della SQL injection, questo tipo di attacco non colpisce il server o il database, ma direttamente gli utenti finali. Il loro browser esegue inconsapevolmente il codice dell'attaccante, che può ad esempio servire a rubare la password, mostrare dei pulsanti o dei link che sembrano validi ma che in realtà rimandano a delle pagine malevole, o anche mostrare dei contenuti falsi. Falsi, come finte pagine di login per leggere le credenziali dell'utente. Il browser non sospetta nulla perché quel codice sembra provenire dal sito di fiducia che la persona ha scelto di visitare. Gli ingegneri Microsoft chiamarono questa tecnica XSS, o XSS, abbreviazione che sta per cross-site scripting, scripting attraverso i siti, perché l'attaccante inserisce lo script, quindi questo codice JavaScript, in un sito web, ma l'effetto dannoso si ha sul browser dell'utente finale. Quindi è come se io dal mio computer scrivo il mio commento e voi dal vostro computer vedete il mio commento. Il mio commento ha attraversato due siti web. Torniamo all'esempio della nostra rapina in banca. Se la SQL injection era come fregare un dipendente convincendolo a dare accesso al cavo, l'XSS è diverso. È come se il ladro si sedesse in sala d'attesa e invece di colpire la banca iniziasse a ingannare direttamente i clienti, fingendosi un impiegato e chiedendo loro informazioni sul conto corrente o di dargli il bancomat e comunicargli il PIN. Perché il cliente dovrebbe fidarsi? Perché è in banca, la persona con cui sta parlando sembra un impiegato di banca, quindi il cliente fa quello che gli viene chiesto perché l'ambiente gli ispira fiducia che la richiesta sia legittima. E lo stesso fa il browser quando visitiamo un sito web colpito da cross-site scripting perché non è in grado di capire quali parti del codice JavaScript quali invece no. C'è un caso reale che secondo me fa capire ancora meglio come funziona il cross-site scripting, ed è il worm Semi. Siamo nel 2005, quindi già 6 anni dopo che l'XSS era stato scoperto, e il sito social più frequentato di tutti è MySpace. In MySpace, lo dico alle persone come me che non lo hanno mai usato, c'era la possibilità di creare un proprio profilo per farsi conoscere, e c'era una sezione chiamata "Su di me" o "I miei interessi" che tutti quelli che visitavano la tua pagina potevano vedere. L'obiettivo di MySpace era avere più amici possibile, quindi questa parte normalmente veniva anche magari un po' personalizzata. Era possibile ad esempio rendere questo testo più colorato, cambiare font, eccetera, inserendo del linguaggio HTML o CSS. Un ragazzo di 20 anni di nome Samy Kamkar pensò bene di scrivere in questa sezione non una frase normale tipo "mi piacciono i gatti", magari decorata in blu, ma un codice JavaScript. Quando qualcuno visitava il profilo di Sammy, il browser eseguiva questo codice che aggiungeva immediatamente Sammy agli amici della persona che aveva visitato il suo profilo e copiava lo stesso codice nella pagina di questa persona, così chiunque visitava il profilo anche di quest'altra persona aggiungeva Sammy agli amici. In meno di 24 ore Sammy aveva oltre un milione di amici su MySpace. Il bello è che in realtà MySpace impediva di inserire in questa sezione del codice JavaScript lo bloccava in automatico. Sammy però era riuscito ad aggirare questa cosa approfittando del fatto che comunque si poteva inserire del codice HTML o CSS dentro questa sezione. In pratica, se lui avesse messo solo lo script "aggiungimi agli amici", MySpace l'avrebbe bloccato. Lui invece inseriva codice HTML che diceva: il font di questa sezione deve essere Arial, lo sfondo deve essere blu e il colore del testo deve essere "aggiungimi agli amici". In questo modo MySpace faceva passare il codice perché interpretava tutto insieme come se fossero semplicemente regole di stile. A quel punto, una volta scoperto quanto fosse diffusa questa tecnica, divenne ancora più urgente trovare un modo per impedire che un malintenzionato approfittasse dei campi input di un sito web per inserire la qualunque. Non si doveva più trovare solo il modo di evitare che venissero presi ed eseguiti comandi SQL per prevenire la SQL injection. Le ricerche si concentrarono lavorarono anche sul prevenire la modifica dei siti tramite l'inserimento di comandi JavaScript. Non si poteva pensare che fosse il browser a capire da solo quali parti di codice andavano bene e quali no, così come non si può pensare che siano i clienti della banca a capire quali sono i dipendenti reali e quali sono i malintenzionati. È la banca che deve far sì che nessuno possa piazzarsi in sala d'attesa e convincere i clienti a dare delle informazioni. Oltretutto i ricercatori iniziarono a pensare a quante altre minacce potevano venir fuori che sfruttassero siti web legittimi per compiere azioni dannose. Era solo questione di tempo prima che venisse scoperta una nuova tecnica ancora peggiore delle precedenti. E infatti nei primi anni 2000 questa terza tecnica venne scoperta. Gli informatici si accorsero che un sito web malevolo poteva indurre il browser di un utente già autenticato su un altro sito a inviare operazioni non autorizzate sfruttando la sessione aperta. Ad esempio, Immaginate di essere connessi al vostro home banking in una scheda di Google Chrome. Aprite un'altra scheda lasciando aperta quella della banca e visitate un sito web apparentemente innocuo che però contiene un codice nascosto che dice al vostro browser: vai nella scheda della banca e trasferisci 1000 euro su questo conto. Il vostro Google Chrome vedendo che siete già autenticati esegue l'ordine senza che voi ve ne accorgiate. Ho fatto un esempio che nel 2025 è un po' forzato, perché sappiamo tutti che in realtà adesso per fare un'operazione di questo tipo serve l'autorizzazione dell'utente, che spesso passa da un altro dispositivo. Quindi dovrei ad esempio mettere l'impronta digitale sul mio telefono per confermare. Dobbiamo però pensare che questa tecnica è stata scoperta 25 anni fa, quando ancora c'era molta ingenuità rispetto a internet. Se ne stavano scoprendo le potenzialità in quel momento, e spesso ci si accorgeva dei pericoli solo dopo che si erano già verificati dei danni. Per farvi un esempio, sempre ancorato a un caso reale, nel 2008 questa tecnica è stata usata contro ING Direct. Quindi innanzitutto siamo nel 2008, 8 anni dopo che questa tecnica era stata scoperta, e in secondo luogo parliamo proprio di una banca, di un istituto finanziario. Quindi in realtà queste cose non sono esempi campati per aria, sono cose successe. Comunque questa tecnica, quella che sfruttava il fatto di essere già autenticati in un altro sito per fare quello che si voleva, venne chiamata CSRF, acronimo che sta per Cross Site Request Forgery, che potremmo tradurre con falsificazione di richieste fra siti, perché un sito, quello malevolo, crea una richiesta falsa che il sito legittimo esegue pensando che sia una richiesta valida. Capisco che questi acronimi non siano semplici da ricordare, sarebbe più facile per tutti se anziché XSS e CSRF si chiamassero Pino e Mauro, ma purtroppo va fa così. Quello che serve perché il CSRF funzioni sono i cosiddetti cookie di sessione. Sono pezzettini di testo che il browser conserva e che dicono: l'utente è correttamente autenticato in questo sito, quindi le richieste sono valide finché la sessione non sarà finita. È il singolo servizio, il singolo sito web, a decidere quand'è che la sessione è finita. Ad esempio, Gmail fa durare una sessione almeno un paio di mesi prima di chiederci di nuovo l'autenticazione. I siti bancari oggi fanno durare una sessione per tutto il tempo in cui siamo davanti al sito web, ma appena chiudiamo la pagina dobbiamo rifare l'autenticazione, quindi quel cookie di sessione non è più valido. Di solito una sessione finisce anche quando cambiamo le credenziali. Ad esempio, se cambio la mia password di Amazon dal telefono, quando poi lo riapro sul computer Amazon mi chiede di rifare l'autenticazione, quindi di rimettere username e password, perché il cookie di sessione non non vale più essendo collegato alla password precedente. Il CSRF sfrutta appunto questi cookie di sessione che sono come un biglietto che garantisce al browser che tutte le richieste che arrivano sul sito in cui siamo autenticati e per cui c'è un valido cookie di sessione sono opera nostra. E normalmente è così. Se io voglio fare un'operazione bancaria, come prima cosa mi loggo al sito della banca che mi genera un cookie di sessione. Il mio browser lo salva e lo allega a ogni richiesta che invia poi alla banca, ad esempio Veronica Paolucci chiede di fare un giroconto di 100 euro. È davvero lei a chiederlo. Guarda, ecco il suo cookie di sessione. Se io faccio la stessa cosa su un altro computer o usando Firefox anziché Google Chrome, devo per forza autenticarmi di nuovo perché il mio cookie di sessione è salvato esclusivamente sul browser che ho usato per loggarmi. Il malintenzionato che usa la tecnica del cross-site request forgery non ha i miei cookie di sessione, ma non importa, L'importante è che io visiti il sito malevolo usando lo stesso browser che ha salvato il cookie di sessione. Il sito malevolo genera una richiesta, ad esempio dice al browser: "Fai un giroconto di 100 euro". Il browser la trasmette al sito a cui deve trasmetterla, quindi il sito della mia banca, e automaticamente allega anche i cookie di sessione, perché è quello che ci si aspetta da lui. Il browser è una macchina, non è in grado di capire se la richiesta di giroconto proviene da me che ho usato il mio mio mouse e la mia tastiera o se è stata generata da un sito malevolo progettato apposta per questo. E voi qui potreste dire: "Vabbè, ma chi visiterebbe mai siti malevoli così tanto per?" E infatti questa domanda se la sono posta anche i criminali che hanno detto: "Mm, però è un po' improbabile che riusciamo a convincere qualcuno ad aprire il nostro sito malevolo e intanto anche il sito legittimo da cui vogliamo rubare soldi, credenziali, informazioni e così via." e così via. E così cos'hanno fatto i nostri cybercriminali? Hanno iniziato a unire il cross-site scripting e il cross-site request forgery, il nostro Pino e il nostro Mauro. L'utente si collega a due o più siti normalissimi che è abituato a frequentare senza sapere che uno di questi è stato colpito da cross-site scripting. Il malintenzionato ad esempio ha preso il sito di repubblica.it e ha iniettato del codice in quel sito, codice che viene eseguito normalmente direttamente dal browser dell'utente, perché il sito è di fiducia, è repubblica.it, mica hai vinto un iPhone.com, quindi non pensa che ci sia qualcosa di strano. Questo codice JavaScript dice al browser: invia questa richiesta all'altro sito su cui l'utente è già autenticato. Ed ecco che si uniscono le due tecniche: da una parte il cross-site scripting, che permette di inserire codice malevolo in un sito legittimo, e dall'altra il cross-site request forgery, perché quel codice sfrutta la sessione dell'utente per per inviare richieste non autorizzate a un altro sito web. Tranquilli, so che è difficile, ma noi torniamo ancora una volta all'esempio della rapina in banca. Il Cross Site Request Forgery è come se un cliente fosse davanti allo sportello della banca per fare un'operazione e mentre firma un modulo che gli ha dato il dipendente, il ladro di nascosto gli infilasse davanti un foglio diverso. Il cliente pensa di firmare un modulo normale, invece in realtà sta firmando un trasferimento verso il conto ladro. Il dipendente della banca riceve il modulo firmato e lo esegue. Per lui è tutto regolare perché c'è la firma del cliente che è davanti a lui in quel momento. È quello che succede al browser. Ha l'utente loggato su un sito, ad esempio Gmail, quindi è ragionevolmente sicuro del fatto che le richieste fatte sul sito di Gmail provengano dall'utente stesso. Un altro sito manda una richiesta da eseguire su Gmail e il browser lo fa perché non ha motivo di pensare che la richiesta sia di qualcun altro. Un dipendente della banca che ha il cliente davanti a sé, che gli dà un modulo compilato, non può pensare che il modulo firmato davanti a lui dal cliente in realtà sia stato messo lì da un malintenzionato. Sul Cross Site Request Forgery a questo punto è bene che io faccia una precisazione. Ho parlato per semplificare di siti aperti in più schede che comunicano fra loro, ma così sarebbe come dire che se una persona è abbastanza furba da non tenere tutte le schede aperte contemporaneamente è al sicuro dal CSRF. SRF. In realtà non è così, quello che conta è l'autenticazione. Se state usando il vostro computer, aprite il browser e andate per esempio su Gmail, nel 90% dei casi non avete bisogno di rimettere le vostre credenziali, siete già autenticati. Quindi anche se tenete Gmail chiuso e visitate un sito malevolo che non c'entra niente, quel sito è potenzialmente in grado di mandare richieste a Gmail, perché essendo voi già autenticati il browser pensa che la richiesta sia legittima. Io uso questa cosa cosa per giustificare la mia mania di tenere sempre 8000 schede aperte contemporaneamente, perché penso tanto non è che se le chiudo sono automaticamente al sicuro dal cross-site request forgery. Vi accennavo all'inizio del video che ci sono siti che possiamo paragonare a un negozio o a una banca, perché i malintenzionati vogliono rubare qualcosa proprio dal sito in sé, e ci sono siti che invece assomigliano più a una galleria d'arte, perché sono siti vetrina o landing page. Anche questi ultimi sono rischiosi per l'utente che li visita, perché possono essere il veicolo per un attacco cross-site scripting o cross-site request forgery, quindi è importante che nessuno di noi sottovaluti la cosa. La buona notizia è che oggi la maggior parte dei siti ha delle protezioni contro tutte e tre le minacce. La brutta notizia è che comunque esistono ancora siti bucabilissimi, perché magari sono stati fatti tempo fa o non sono mai stati modificati o comunque non hanno implementato queste protezioni, ed esiste un rischio concreto sia per i proprietari del sito che per l'utente. Giusto per capirci, nel 2015, quindi non tantissimo tempo fa, è stato rubato l'intero database a TalkTalk, che è uno dei maggiori operatori di telefonia e internet del Regno Unito. Il database è stato rubato semplicemente con la SQL injection, e non da un gruppo di criminali informatici super organizzati, ma da un ragazzino di 17 anni che stava cazzeggiando coi suoi amici. Nonostante fossero passati più di 15 anni dalla scoperta di questa questa tecnica ancora non era stata implementata nessuna protezione, per cui è ancora importante parlarne. Vediamo quindi quali tecniche vengono implementate per proteggere i siti e i visitatori dalle minacce di cui stiamo parlando. Partiamo dalla SQL injection, che se vi ricordate è l'inserimento in campi come username e password di comandi che vengono poi eseguiti a livello di server o di database. La soluzione in questi casi è introdurre delle regole che facciano sì che il tratti tutto quello che viene inserito come valore. In pratica diventa impossibile che quello che il malintenzionato scrive venga interpretato come comando. È come se in banca il dipendente mi chiedesse il mio nome e io rispondessi "dammi tutti i soldi che hai". Se non ci sono protezioni, il dipendente interpreta quello che io sto dicendo come un comando, quindi mi dà tutti i soldi che ha. Se ci sono protezioni, il dipendente interpreta quello che io sto dicendo come la risposta alla sua domanda, quindi sul modulo che sta compilando, nel campo nome, scriverà: "La signora si chiama dammi tutti i soldi che hai". Le regole tecniche che proteggono contro la SQL injection funzionano come pulizia dei dati inseriti, che non sono più interpretabili appunto come una richiesta, ma sono interpretabili solo come riempimento di quel campo. Ci sono altre tecniche ancora più semplici, ad esempio inserire delle regole di validazione dell'input. Presente quando state scegliendo uno username e mettete magari mariorossi! e vi arriva un messaggio di errore con scritto usa solo numeri e lettere vuol dire che è stata messa una regola di validazione che accetta l'input inserito dall'utente solo se ha determinati parametri. Nel caso della SQL injection le regole di validazione possono essere: non puoi mettere apostrofi o virgolette, non puoi mettere punti e virgola così non puoi separare comandi e siamo a posto. Regole simili valgono anche per il cross-site scripting che è l'iniezione di codice JavaScript all'interno di un sito web usando sempre dei campi input come username, password o la sezione dedicata alle recensioni. Anche qui una tecnica usata è quella di impedire che vengano inseriti dei tag script, quindi quelli che inseriscono il codice. Molti browser inoltre adesso hanno delle regole che eseguono il codice JavaScript solo se contenuto nei punti giusti del sito e bloccano i codici che servono a fare cose non previste o appunto malevole. Trovare misure di protezione contro il cross-site request forgery invece è stato più complicato. Oggi i siti bancari o i siti che comunque gestiscono informazioni delicate introducono oltre al cookie di sessione, quindi a quella firma che dice al sito che siamo proprio noi a fare l'operazione, anche un codice casuale. Quando arriva una richiesta alla banca, se proviene da noi che siamo davanti al sito in quel momento, verrà automaticamente inserito oltre al cookie di sessione anche questo codice casuale. Se la richiesta proviene da un'altra parte, come appunto da un sito malevolo creato da un malintenzionato, questo codice casuale non sarà inserito e la richiesta sarà quindi rifiutata. Prima vi ho fatto l'esempio parlando della banca di un malintenzionato che mentre siamo lì a firmare moduli infila un modulo aggiuntivo creato da lui che noi firmiamo senza guardare. Se non ci sono protezioni il dipendente prende tutti i moduli di richiesta e li esegue tutti, quindi anche quello malevolo. Immaginate però che la banca decida che ogni modulo debba avere un codice specifico, diverso non solo da modulo a modulo ma anche da cliente a cliente. Il dipendente ha quindi un database che dice: se Veronica Paolucci vuole fare un bonifico, nel suo modulo ci sarà stampato il codice X4H di 5. Se il malintenzionato mi mette davanti un modulo creato da lui che dice al dipendente di inviare tutti i miei soldi a un altro conto, io posso anche firmarlo e consegnarlo al dipendente, ma lui non potrà accettare la richiesta perché questo modulo non avrà il codice associato a me e a quel tipo di operazione. Il ladro non può conoscerlo, non lo conosco nemmeno io questo codice. Non basta la mia firma sul foglio, che è come il cookie di sessione, serve anche questo codicino che è la banca a mettere sui moduli che mi dà da firmare. Un altro modo semplice per evitare che si verifichi il cross-site request forgery si chiama cookie same site. Banalmente il sito accetta come validi i cookie di sessione solo se provengono dallo stesso sito in cui siamo autenticati. In questo modo se ci colleghiamo a un sito malevolo che invia una richiesta allegando i nostri cookie di sessione, la richiesta viene rifiutata perché il cookie di sessione proviene da un sito diverso. A questo punto voi direte: ma ha senso aver visto tutto questo video se i 3 problemi di cui ha parlato sono già tutti stati risolti? La risposta risposta è sì, ha senso. Un po' perché se 'ste cose le devo studiare io, mi dispiace, ma ve le beccate pure voi. Un po' perché, a parte gli scherzi, come dicevo, ancora ci sono siti che non implementano queste misure base, quindi siamo noi utenti a doverci proteggere. Quindi vediamo adesso come possiamo fare noi per aumentare la nostra sicurezza quando magari stiamo visitando siti che non sappiamo se sono a posto. La nostra protezione contro la SQL injection è usare credenziali diverse per ogni sito che utilizziamo. Pensiamoci un attimo, se un malintenzionato riesce a mettere le mani sul database con le nostre credenziali, la prima cosa che farà sarà venderle sul dark web o provare lui stesso a inserire queste credenziali in altri siti. Se siamo furbi ed evitiamo di usare lo stesso username abbinato alla stessa password in 100 siti diversi, limitiamo i danni. Contro cross-site scripting e cross-site request forgery possiamo: 1. Intanto tenere sempre aggiornato il nostro browser. Quando ci arriva la notifica che Google Chrome, Safari, Firefox, eccetera, devono essere aggiornati, facciamolo subito, perché spesso gli aggiornamenti di sicurezza riguardano proprio come il browser carica le informazioni sui siti o invia le richieste fra siti diversi. Quindi aggiungono proprio protezioni contro XSS e CSRF, o come li chiamiamo noi, contro Pino e contro Mauro. Chiedo scusa a tutti i Pino e Mauri che sto offendendo involontariamente con questo video. 2. Implementiamo, dove possiamo, l'autenticazione a più fattori, così anche se un malintenzionato riesce a inviare delle richieste, non riesce a farsele approvare automaticamente, dobbiamo intervenire noi ad autorizzarle. 2 bis: ovviamente autorizziamo solo le operazioni che riconosciamo e che abbiamo fatto noi. È scontato ma lo dico perché non si sa mai. 3: quando usiamo siti un po' delicati come quello bancario o siti di cui non ci fidiamo fino in fondo, appena abbiamo finito le operazioni che dovevamo fare facciamo logout, così il cookie di sessione termina il nostro automatico. In questo modo, dove non arrivano i siti con le loro misure di sicurezza, arriviamo noi a proteggerci direttamente. Perché davvero non si sa mai quello che può succedere. I malintenzionati ancora sfruttano queste tecniche e a volte funzionano, creando danni anche per gli utenti, come è successo a British Airways nel 2018. Ma di questo ne parliamo nel prossimo video, anche perché si è fatta una certa. Bene, come sempre spero che il video di oggi vi sia piaciuto. Come vi dicevo, se siete arrivati fino in fondo siete degli eroi, perché so che non era facile, Ma adesso che sapete tutto su queste tecniche, non potete assolutamente perdervi i video della prossima settimana, perché è una storia che lascia veramente a bocca aperta. A presto!