Attacco XXE: cos'è e come difendere il codice PHP
Un attacco XXE (XML External Entity) sfrutta un parser XML configurato in modo troppo permissivo: l'attaccante invia un documento XML che richiama risorse esterne e così riesce a leggere file del server, a interrogare servizi interni o a saturare le risorse. La causa è quasi sempre una configurazione sbagliata, non un difetto sofisticato. Per questo si previene bene, se si sa dove guardare.
In questa guida vediamo come funziona, perché riguarda da vicino il codice PHP e quali contromisure adottare.
Cos'è un attacco XXE (XML External Entity)?
XML è un formato per scambiare dati strutturati. Nelle sue specifiche esiste la DTD (Document Type Definition), che consente di dichiarare delle "entità": segnaposto che il parser sostituisce con un valore. Alcune entità possono essere esterne, cioè puntare a un file locale o a un indirizzo di rete.
Questa funzione nasce per comodità, ma diventa un problema quando l'applicazione elabora XML proveniente da utenti o sistemi non fidati. Se il parser risolve le entità esterne, è l'attaccante a decidere quale risorsa il server deve leggere o contattare.
Il rischio è noto da tempo. Nell'edizione 2017 della classifica OWASP Top 10 le entità esterne XML avevano una categoria dedicata; nell'edizione 2021 sono confluite in Security Misconfiguration, a conferma che l'origine è la configurazione. Per il quadro generale puoi leggere la nostra guida alle vulnerabilità delle applicazioni web e alla OWASP Top 10.
Come funziona un attacco XXE passo dopo passo
Lo schema è lineare e non richiede strumenti particolari. Capirlo aiuta a riconoscere i punti deboli del proprio codice.
- Individuazione del punto di ingresso. L'attaccante cerca una funzione che accetta XML: un'API, un form, un caricamento file, un servizio SOAP.
- Invio di un documento modificato. Nel documento inserisce una dichiarazione DTD con un'entità esterna.
- Elaborazione da parte del parser. Se le entità esterne sono abilitate, il server recupera la risorsa indicata.
- Restituzione o esfiltrazione. Il contenuto compare nella risposta oppure viene inviato a un server controllato dall'attaccante.
Un esempio concettuale
Il caso didattico più noto è un documento che dichiara un'entità collegata a un file di sistema e poi la richiama nei dati:
<!DOCTYPE dati [ <!ENTITY esterna SYSTEM "file:///percorso/del/file"> ]>
<richiesta>&esterna;</richiesta>
Se l'applicazione restituisce il campo richiesta nella risposta, il contenuto del file compare lì. Anche quando la risposta non mostra nulla, esistono tecniche "cieche" che fanno uscire i dati attraverso richieste di rete verso l'esterno.
Cosa può ottenere l'attaccante
- Lettura di file locali: file di configurazione, chiavi, credenziali del database o variabili d'ambiente salvate su disco.
- SSRF (Server-Side Request Forgery): il server viene usato per contattare servizi raggiungibili solo dall'interno, come pannelli di amministrazione o endpoint dei metadati nel cloud. Ne parliamo anche nell'articolo sulla cloud misconfiguration.
- Denial of service: entità annidate o richieste verso risorse lente possono consumare memoria e CPU.
- Passaggio ad altri attacchi: le credenziali trovate possono servire per accessi successivi o per una privilege escalation.
Perché l'attacco XXE riguarda il codice PHP
PHP elabora XML con più estensioni, tra cui SimpleXML, DOMDocument e XMLReader, tutte basate sulla libreria libxml2. Il comportamento dipende quindi dalla versione di libxml2 e dalle opzioni passate alle funzioni.
Con le versioni recenti di libxml2 il caricamento delle entità esterne non è attivo di default, e questo ha ridotto il problema. Il rischio resta quando lo sviluppatore abilita esplicitamente opzioni pericolose o lavora su sistemi datati.
Le opzioni da controllare
Nel codice conviene cercare le chiamate a simplexml_load_string, simplexml_load_file, DOMDocument::loadXML e XMLReader, e verificare quali flag ricevono. Sono sospetti in particolare:
- LIBXML_NOENT: il nome inganna, perché in pratica attiva la sostituzione delle entità, comprese quelle esterne.
- LIBXML_DTDLOAD: permette di caricare il DTD esterno.
- LIBXML_DTDATTR: aggiunge gli attributi di default del DTD e, in combinazione con altre opzioni, aumenta la superficie di rischio.
La funzione libxml_disable_entity_loader era la protezione classica nelle vecchie versioni, ma è deprecata da PHP 8.0. Se mantieni applicazioni legacy, controlla la versione di PHP e di libxml2 in uso invece di dare per scontato che siano protette.
XML nascosto in formati inaspettati
Molti sviluppatori non pensano di "gestire XML" perché non hanno un endpoint dedicato. Eppure i file SVG, i documenti DOCX e XLSX, i feed RSS, le risposte SAML e i servizi SOAP sono tutti XML. Una funzione di importazione o di anteprima che li apre lato server può esporre un attacco XXE anche in applicazioni dall'aspetto innocuo.
Come prevenire un attacco XXE
La prevenzione si basa su poche regole, da applicare in modo coerente a ogni punto in cui l'applicazione elabora XML.
- Disabilita DTD ed entità esterne nel parser, ovunque sia possibile. Se la tua applicazione non ne ha bisogno, non devono essere attive.
- Evita i flag a rischio come LIBXML_NOENT e LIBXML_DTDLOAD quando elabori dati non fidati.
- Preferisci formati più semplici, come JSON, quando puoi scegliere il formato di scambio.
- Aggiorna PHP e le librerie che trattano XML: il patch management riduce il rischio di restare su componenti con comportamenti insicuri noti.
- Limita il traffico in uscita dei server applicativi: se il server non può contattare Internet o la rete interna senza motivo, anche un XXE cieco ha meno effetto.
- Applica il minimo privilegio: l'utente che esegue PHP dovrebbe poter leggere solo ciò che serve.
- Valida l'input e rifiuta documenti che contengono dichiarazioni DOCTYPE quando non sono previste.
Un WAF può aiutare, ma non sostituisce la correzione alla radice: i filtri sui payload si aggirano, una configurazione corretta del parser no.
Come capire se la tua applicazione è esposta
Il primo passo è un inventario: dove l'applicazione riceve o apre XML, compresi caricamenti di file e integrazioni con terze parti. Il secondo è la revisione del codice sui punti indicati sopra, con attenzione ai flag e alle versioni.
Il terzo è la verifica pratica, con test controllati su un ambiente autorizzato. Un test di sicurezza su un'applicazione web include di norma anche la ricerca di queste falle, e un penetration test automatizzato come FRED può aiutare a tenere sotto controllo l'esposizione in modo ripetibile.
Come valutare la gravità
Se la falla riguarda un componente di terze parti, di solito è catalogata con un identificativo CVE, accompagnato da un punteggio CVSS. Il CVSS indica la gravità teorica, ma non sostituisce l'analisi del tuo contesto: un XXE su un server che contiene segreti e raggiunge la rete interna pesa più dello stesso difetto su un sistema isolato. Ricorda anche la differenza tra vulnerabilità ed exploit: la vulnerabilità è il difetto, l'exploit è la tecnica che lo sfrutta, come spieghiamo in come funziona un exploit informatico.
Conclusione
L'attacco XXE nasce da una funzione legittima di XML usata con troppa fiducia. Nel codice PHP bastano configurazioni attente, librerie aggiornate e un controllo mirato dei punti in cui si elabora XML per eliminare gran parte del rischio.
Se vuoi sapere se le tue applicazioni web sono esposte, puoi approfondire sul blog di Fred for Security oppure valutare un test di sicurezza mirato con i servizi del sito, per ottenere un quadro concreto e priorità chiare su cosa correggere.
Domande frequenti
Un attacco XXE può portare all'esecuzione di codice sul server?
Di norma l'XXE permette lettura di file, richieste verso sistemi interni e consumo di risorse. L'esecuzione di codice è un esito indiretto e dipende dall'ambiente: ad esempio dall'uso di wrapper particolari o dal fatto che i file letti contengano credenziali riutilizzabili per accedere ad altri servizi.
Quali file e funzionalità possono contenere XML senza che me ne accorga?
L'XML è nascosto in molti formati: file SVG caricati come immagini, documenti Office come DOCX e XLSX, servizi SOAP, risposte SAML per il single sign-on e feed RSS. Qualsiasi funzione che elabora questi dati lato server va controllata, anche se l'utente non carica mai un file chiamato XML.
Disattivare le entità esterne rovina la compatibilità con le applicazioni?
Nella maggior parte dei casi no. Le entità esterne e i DTD sono usati raramente nei flussi applicativi comuni. Prima di disattivarli conviene verificare quali partner o sistemi inviano XML all'applicazione, e provare la modifica in un ambiente di test per accertarsi che nessun flusso legittimo si interrompa.
Un WAF basta a proteggersi da un attacco XXE?
No, un WAF può bloccare alcuni payload noti ma non sostituisce la correzione del codice. Chi aggira i filtri con codifiche o varianti del payload può comunque raggiungere il parser. La difesa efficace è configurare il parser in modo sicuro e, dove possibile, evitare del tutto i DTD.