Se si gestisce un server web o si analizzano i log di accesso, è sicuramente capitato di trovare nei log una riga simile a questa:
"GET /?XDEBUG_SESSION_START=phpstorm HTTP/1.1"A prima vista potrebbe sembrare un tentativo di attacco o un errore di sistema. In realtà, si tratta di un comando fondamentale per lo sviluppo in PHP, che però nasconde insidie pericolose se esposto nel posto sbagliato. Vediamo di cosa si tratta e perché si deve prestare attenzione.
Cos’è Xdebug?
Xdebug è l’estensione più diffusa per PHP che permette agli sviluppatori di effettuare il “debugging” del codice e permette di
- mettere in pausa l’esecuzione del codice tramite breakpoint
- esaminare il valore di tutte le variabili in tempo reale
- analizzare lo stack delle chiamate per capire come il codice è arrivato a un determinato punto
Il parametro XDEBUG_SESSION_START=phpstorm comunica al server di avviare immediatamente una connessione verso l’IDE (in questo caso PhpStorm, uno dei più popolari) per iniziare la sessione di analisi.
Perché appare nei log? Ci sono due scenari principali:
- ambiente di sviluppo: se si sta sviluppando un sito in un ambiente di staging, questa stringa indica che è stato attivato il debugger dal browser. È uno strumento di produttività essenziale che permette di risolvere bug complessi in pochi minuti anziché ore
- server di produzione: se è presente questa richiesta nei log di un sito pubblico e non è un’operazione di debug avviata da chi sviluppa il sito, la situazione cambia. Bot e malintenzionati scansionano costantemente il web alla ricerca di server che espongono Xdebug
Perché lo fanno? Perché un server con Xdebug attivo e mal configurato è una miniera d’oro per un hacker. Se riescono a connettersi alla sessione di debug, potrebbero:
- leggere dati sensibili come credenziali del database, chiavi API, …
- aggirare i sistemi di autenticazione modificando il valore delle variabili
- nei casi peggiori, eseguire codice sul server
Come proteggersi?
La regola è semplice: Xdebug non deve mai essere installato o abilitato su un server di produzione. Vediamo di seguito alcune best practice:
- Verificare la configurazione: ci si deve assicurare che l’estensione Xdebug non sia attiva in ambienti di produzione soprattutto se esposti su Internet
- Usa il profiling con cautela: se si ha bisogno di analizzare le performance di un ambiente di produzione utilizzare tool specifici progettati per tale scopo
- Configurare il firewall: se è assolutamente necessario usare Xdebug su un server remoto, non lasciare la porta di default (9003) aperta a tutti. Limitare l’accesso solo ad indirizzi IP specifici
- Monitorare i log: se si nota un volume elevato di richieste verso XDEBUG_SESSION_START da indirizzi IP non conosciuti è un segnale che il sito è sotto scansione. Assicurarsi quindi che il server non risponda a queste chiamate
Come verificare se Xdebug è attivo sul server
Per verificare se il server sta eseguendo l’estensione ci sono vari modi. Il metodo più rapido è da riga di comando, digitando
php -vSe Xdebug è attivo, sarà presente una riga simile a quella seguente tra le informazioni sulla versione
with Xdebug v3.x.x, Copyright (c) 2002-2026, by Derick RethansIn alternativa, è possibile filtrare i moduli caricati:
php -m | grep xdebugSe uno dei test sopra conferma la presenza di Xdebug su un server pubblico è necessario editare il file di configurazione (php.ini) commentando
; zend_extension=xdebug.soper farlo è sufficiente aggiungere il carattere ; all’inizio della riga. Va quindi riavviato il servizio php (es. sudo systemctl restart php-fpm) e/o il web server in uso.
Conclusione
La stringa XDEBUG_SESSION_START=phpstorm è un potente strumento per chi scrive codice, ma può diventare un varco aperto per chi vuole colpire la tua infrastruttura. Conoscere gli strumenti che utilizziamo è il primo passo per una difesa efficace.
E non dimentichiamo che bisogna sempre assicurarsi che gli strumenti di sviluppo restino… negli ambienti di sviluppo!
