Conosci la vulnerabilità SQL Injection?
In cosa consiste un attacco XXE (XML External Entity)?
L’attacco denominato XXE (XML External Entity) è probabilmente tra i meno noti di quelli appartenenti alla OWASP Top 10. Di seguito proponiamo una sua descrizione quanto più comprensibile possibile.
È stato infatti inserito in quarta posizione solamente a partire dalla versione 2017, a segnale del fatto che sta diventando una problematica sempre più diffusa e di impatto generalmente critico.
Descrizione dell’attacco
Un attacco di tipo XML External Entity (XXE) è un tipo di attacco che può avvenire nei confronti di un’applicazione che elabora input XML.
L’attacco si verifica quando l’input XML, nel caso in cui contenga un riferimento ad una “entity esterna”, viene processato da parte di un parser XML configurato in modo debole.
Impatto dell’attacco
L’attacco può comportare la rivelazione di dati confidenziali, Denial of Service (DoS), Server-Side Request Forgery (SSRF), Port Scanning avente come sorgente l’host dove è presente il parser vulnerabile, e numerosi altri impatti critici sul sistema.
Diffusione dell’attacco
Attacchi di tipo XXE hanno coinvolto applicazioni molto conosciute quali Facebook e PayPal, quindi fate molta attenzione a quanto segue poiché anche la vostra potrebbe essere affetta!
Esempio di attacco
Lo standard XML definisce la struttura di un documento XML e, inoltre, un concetto chiamato entità, ovvero un tipo di unità di memorizzazione.
Esiste un tipo di entità, denominata entità esterna, che può riferirsi a dati locali o remoti e che permette di sostituire nel documento XML il loro relativo valore. Se le entità esterne si riferiscono a dati interni o confidenziali, il parser XML potrebbe dunque inserirli nel documento XML finale consentendo ad un attaccante di ottenere informazioni preziose.
Come esempio pratico utilizzeremo l’applicazione vulnerabile “XXE Lab” scaricabile al link, nella quale è presente una semplice funzionalità per la registrazione di un utente.
La richiesta relativa alla creazione di un utente è la seguente:
Essa restituisce la risposta seguente:
La richiesta è quindi di tipo XML e il valore dell’elemento “email” viene riflesso nella relativa risposta.
Definiamo quindi una entità esterna che si riferisca al file “/etc/passwd” e inseriamo tale riferimento nell’elemento “email” in modo tale che il suo contenuto venga inserito nella risposta.
L’entità esterna “xxe” è stata dichiarata nella richiesta nel modo seguente:
La risposta ottenuta è ora la seguente:
Il valore del file “/etc/passwd” è stato dunque sostituito all’entity esterna “xxe” richiamata nella richiesta XML come “&xxe;”.
Poiché il valore dell’elemento “email” viene riflesso nella risposta, un attaccante può leggere direttamente da essa il contenuto del file confidenziale presente sul server attaccato.
Per precisione, si noti che affinché l’attacco vada a buon fine non è necessario che un valore presente nella richiesta venga restituito nella risposta. Un attaccante potrebbe infatti utilizzare tecniche di tipo Out-of-Band (OOB) che gli consentirebbero di ottenere il contenuto del file direttamente come richiesta indirizzata verso un proprio server.
Per maggiori informazioni su questo tipo di tecnica avanzata si faccia riferimento alla seguente risorsa.
Come capire se la tua applicazione è vulnerabile
Le applicazioni e i web service basati su XML potrebbero essere vulnerabili se:
- L’applicazione accetta XML in modo diretto oppure tramite file upload, in particolare se ottenuto da parte di sorgenti non fidate, o inserisce dati non verificati in documenti XML parsati da processori XML configurati in modo debole;
- Il processore XML è configurato per validare e processare il DTD;
- Le entità esterne non sono disabilitate;
- L’applicazione usa SOAP prima della versione 1.2;
- L’applicazione usa SAML o meccanismi di tipo Single Sign On (SSO) per l’autenticazione, in quanto questi usano XML.
Conclusioni
Un attacco di tipo XXE potrebbe avere conseguenze molto gravi qualora venissero ignorate le relative contromisure.
Gli sviluppatori dovrebbero quindi adottare le seguenti best practice per prevenire l’attacco:
- Disabilitare le entity esterne e il “DTD Processing” in tutti i parser XML usati dall’applicazione;
- Aggiornare ed eventuale patchare tutte le librerie che utilizzano parser XML;
- Validare i dati XML in ingresso quando questi vengono caricati mediante funzionalità di file upload (ad esempio file docx, xlsx, ecc.);
- Utilizzare meccanismi di tipo “whitelisting” a livello server per filtrare o sanitizzare eventuale input malevolo presente all’interno di documenti XML.