cross site scripting xss attacks

cross site scripting xss attacks

Se pensi che il tuo sito web sia al sicuro solo perché hai installato un certificato SSL o usi un framework moderno, ho una brutta notizia per te. La realtà è molto più bastarda. Ogni volta che permetti a un utente di inserire un commento, compilare un modulo di contatto o anche solo cercare qualcosa sul tuo portale, stai aprendo una porta. E dietro quella porta potrebbero nascondersi i famigerati Cross Site Scripting XSS Attacks, una minaccia che non colpisce il tuo server, ma i tuoi utenti. È un attacco subdolo. Non punta a buttare giù la tua infrastruttura, ma a usare la fiducia che il browser del visitatore ripone nel tuo codice per rubare sessioni, cookie e dati personali. In questo articolo ti spiego come funziona questo meccanismo e perché quasi tutti sbagliano l'approccio alla sicurezza front-end.

Capire il nemico per non farsi fregare

Il concetto di base è semplice. Un malintenzionato inietta del codice JavaScript malevolo in una pagina web che altri visualizzeranno. Il browser della vittima riceve questo script e lo esegue, pensando che faccia parte del tuo sito. Fine dei giochi. Il problema è che JavaScript ha accesso a tutto ciò che riguarda la sessione dell'utente. Se non hai configurato bene i tuoi sistemi, un attaccante può spedire il session token del tuo cliente a un server remoto con una riga di codice.

Esistono tre varianti principali di questa minaccia. La prima è quella memorizzata o "Stored". È la peggiore. Il codice malevolo finisce dritto nel tuo database. Immagina un forum dove un utente scrive un post che contiene uno script. Ogni singola persona che caricherà quella discussione eseguirà quel codice. La seconda è quella riflessa. Qui lo script non viene salvato, ma "rimbalza" da un link malevolo. Magari una mail di phishing che punta a un tuo URL con un parametro infetto. La terza è basata sul DOM. Qui il server non c'entra nulla, tutto accade nel browser del cliente manipolando gli oggetti della pagina.

👉 Vedi anche: questa storia

Il mito della validazione lato client

Molti sviluppatori alle prime armi pensano che basti un po' di Regex nel browser per stare tranquilli. Non farlo. È un errore da principianti. Qualsiasi controllo fatto lato client è facilmente aggirabile. Basta usare uno strumento come OWASP ZAP per intercettare la richiesta e inviare quello che si vuole. La sicurezza si fa sul server, sempre. Devi dare per scontato che ogni input proveniente dall'esterno sia spazzatura atomica. Non importa se arriva da un utente loggato o da un admin. Tratta tutto come se fosse radioattivo.

Strategie reali per bloccare Cross Site Scripting XSS Attacks

La difesa non è un singolo muro, ma una serie di ostacoli. La prima cosa che devi fare è gestire l'output. Molti si concentrano sul pulire i dati quando entrano, ma la vera magia avviene quando i dati escono. Devi fare l'escaping. Se stampi il nome di un utente a schermo, i caratteri speciali devono essere trasformati in entità HTML. Un `

GS

Gabriele Serra

Gabriele Serra segue i temi più discussi del momento con spirito critico e attenzione all'impatto sociale delle notizie.