allow_url_include: rischi e protezioni in PHP

Cos’è allow_url_include e perché è pericoloso

allow_url_include è un parametro di configurazione di PHP che consente, se attivato, di includere file remoti tramite URL dentro funzioni come include, require, include_once e require_once. In pratica, un’applicazione può caricare ed eseguire codice proveniente da una risorsa esterna, non solo da file locali sul server.

Questa possibilità, sulla carta comoda in vecchi progetti o in script scritti male, è oggi considerata un rischio serio. Se un’applicazione contiene una vulnerabilità di inclusione di file, l’attaccante potrebbe trasformarla in esecuzione remota di codice. Per questo motivo, nella quasi totalità dei casi, allow_url_include deve restare disattivato.

Il principio da ricordare è semplice: un file PHP deve includere solo contenuti locali e prevedibili. Ogni eccezione aumenta la superficie d’attacco e complica il controllo del flusso applicativo.

Differenza tra allow_url_fopen e allow_url_include

Spesso i due parametri vengono confusi, ma non hanno lo stesso impatto:

• allow_url_fopen permette a funzioni come file_get_contents o fopen di aprire URL remoti, se il codice lo richiede.
• allow_url_include abilita invece l’inclusione di risorse remote dentro il flusso di esecuzione PHP, ed è molto più delicato dal punto di vista della sicurezza.

In molti ambienti moderni, allow_url_fopen può essere utile in casi specifici e controllati, mentre allow_url_include quasi mai lo è. Se stai facendo hardening, il secondo va disabilitato senza esitazione, salvo scenari legacy molto particolari e comunque da evitare.

Quali rischi introduce davvero

Il problema non è solo teorico. Quando un’applicazione accetta input non validato e lo usa in una include, l’attaccante può provare a far puntare quella variabile verso una risorsa remota o verso un percorso manipolato. Se allow_url_include è attivo, il server può eseguire codice che non dovrebbe mai eseguire.

I rischi principali sono:

• Remote Code Execution: esecuzione di codice arbitrario sul server.
• Compromissione completa del sito: modifica di pagine, furto di dati, inserimento di backdoor.
• Movimento laterale: in ambienti condivisi o mal segmentati, l’attacco può estendersi ad altri servizi.
• Persistenza dell’infezione: l’attaccante può lasciare meccanismi di riaccesso difficili da individuare.

In un contesto hosting o VPS, questo parametro non va trattato come una semplice opzione funzionale. È una scelta di sicurezza che può fare la differenza tra un bug innocuo e una compromissione totale.

Perché molti ambienti lo disabilitano di default

Le distribuzioni moderne, i pannelli hosting e le best practice di hardening tendono a mantenerlo disattivato. La ragione è pratica: i casi d’uso legittimi sono rarissimi, mentre gli abusi sono frequenti. Inoltre, le applicazioni ben scritte non hanno bisogno di includere codice da URL esterni.

Un altro punto importante è la manutenzione. Se un progetto dipende da inclusioni remote, diventa fragile: basta un problema di rete, un cambio di contenuto remoto o una compromissione del server terzo per creare indisponibilità o, peggio, eseguire contenuti malevoli. La sicurezza non è solo prevenzione dell’attacco, ma anche riduzione della dipendenza da componenti non controllati.

Come verificare se è attivo

Prima di modificare qualcosa, conviene verificare lo stato reale della configurazione. Il controllo può essere fatto da pannello o da terminale.

Da pannello di controllo

In cPanel, Plesk o FastPanel cerca la sezione PHP del dominio o del pool/FPM e controlla il valore di allow_url_include. In molti casi è visibile nel selettore delle direttive PHP o nelle impostazioni avanzate del dominio.

Se non trovi il parametro nell’interfaccia, potrebbe essere gestito dal file php.ini, da un file di override del virtual host o dalla configurazione PHP-FPM.

Da terminale

Puoi controllare il valore effettivo con:

php -i | grep -i allow_url_include

Esito atteso: il valore deve risultare Off. Se usi PHP-FPM o più versioni PHP, verifica anche la versione corretta del sito, perché la CLI può non coincidere con quella servita dal web server.

Per vedere il file di configurazione caricato:

php --ini

Questo aiuta a capire dove intervenire senza modificare il file sbagliato.

Come disabilitarlo in modo sicuro

La soluzione consigliata è semplice: impostare allow_url_include = Off nel contesto corretto, senza toccare altre direttive se non necessario.

Metodo 1: php.ini o file equivalente

Individua il file di configurazione usato dal servizio PHP del sito e aggiungi o modifica la direttiva:

allow_url_include = Off

Prima di salvare, fai un backup del file. Per esempio:

cp /percorso/php.ini /percorso/php.ini.bak

Dopo la modifica, riavvia il servizio PHP-FPM o il web server, in base alla tua architettura.

Metodo 2: pannello hosting

Se il pannello consente la gestione delle direttive PHP per dominio, imposta allow_url_include su Off e salva. Questo è spesso il metodo più pulito in ambienti shared o in VPS gestite, perché limita la modifica al solo sito interessato.

Controlla poi che il valore effettivo sia cambiato con una pagina phpinfo() temporanea o con il comando di verifica, e rimuovi subito eventuali file di test.

Metodo 3: override per singolo sito

In ambienti con .user.ini o configurazioni per directory, puoi forzare il valore solo per l’applicazione interessata. Anche in questo caso, l’obiettivo è evitare modifiche globali se non servono.

Attenzione però: non tutti i parametri sono sempre modificabili a livello locale, e dipende da come è costruita la catena PHP del server. Se il valore non cambia, significa che il livello di configurazione scelto non è quello giusto o che il pannello blocca l’override.

Se il sito dipende da inclusioni remote

Se scopri che un’applicazione legacy usa davvero URL remoti per includere file, la risposta corretta non è lasciare attivo allow_url_include. La strada migliore è rifattorizzare il codice.

Le alternative sane sono:

• scaricare il contenuto remoto con una richiesta HTTP controllata e trattarlo come dato, non come codice;
• salvare i file necessari in locale e includere solo path interni;
• validare rigidamente il percorso o il nome del modulo consentito;
• usare whitelist statiche invece di input libero dell’utente.

In altre parole, il contenuto remoto va gestito come dato esterno, non come pezzo di programma da eseguire.

Se un progetto “funziona solo” con allow_url_include attivo, il problema di solito non è la configurazione PHP: è il codice.

Contromisure di hardening da affiancare

Disabilitare allow_url_include è una buona base, ma non basta da solo. Per ridurre il rischio complessivo, conviene applicare altre misure coerenti con un server esposto su Internet.

• Tenere PHP e il sistema aggiornati, per ridurre vulnerabilità note.
• Usare utenti separati per ogni sito o account, evitando condivisioni inutili.
• Limitare i permessi dei file, soprattutto su upload, cache e directory scrivibili.
• Disabilitare funzioni pericolose solo se compatibile con il progetto, dopo test accurati.
• Monitorare i log di web server, PHP e applicazione per individuare richieste anomale.
• Fare backup regolari e verificare che il ripristino funzioni davvero.

Se lavori su un ambiente WordPress, CMS o e-commerce, aggiungi anche controllo dei plugin, integrità dei file core e scansione periodica di malware. Un parametro insicuro non vive quasi mai da solo: è spesso il sintomo di una configurazione più larga e meno controllata.

Come riconoscere un abuso o un tentativo di exploit

In produzione, alcuni segnali meritano attenzione immediata:

• richieste strane nei log con parametri che puntano a URL o file insoliti;
• creazione di file PHP in directory di upload o cache;
• redirect non autorizzati o contenuti modificati senza intervento noto;
• picchi anomali di errori PHP o accessi su endpoint poco usati;
• presenza di script con nomi casuali o offuscati.

Se noti questi indicatori, non limitarti a disattivare allow_url_include. Isola il sito, salva evidenze, controlla i log e verifica se ci sono altre debolezze come upload non validati, plugin vulnerabili o permessi eccessivi.

Buona pratica operativa in hosting e VPS

In un ambiente condiviso o multi-sito, la regola migliore è standardizzare: allow_url_include sempre Off, eccezioni solo con motivazione scritta e controllo puntuale del codice. Ogni deroga dovrebbe essere temporanea, tracciata e rivista.

Se gestisci più server, conviene inserire questa impostazione nei profili base o nei template di provisioning, così non dipende dalla memoria dell’operatore. La sicurezza efficace è quella che si ripete in modo coerente, non quella applicata a mano quando ci si ricorda.

Un buon criterio pratico è questo: se una direttiva PHP aumenta la possibilità di eseguire codice non locale, deve essere disabilitata per default e attivata solo con prova concreta di necessità. allow_url_include rientra pienamente in questa categoria.

Checklist finale

• Verifica che allow_url_include sia Off nel PHP realmente usato dal sito.
• Modifica la configurazione nel punto corretto: pannello, php.ini o override locale.
• Controlla che l’applicazione non dipenda da inclusioni remote.
• Rivedi log, permessi e versioni aggiornate di PHP e CMS.
• Se trovi codice legacy, pianifica la refactorizzazione invece di riattivare la direttiva.

In sicurezza PHP, la regola più solida resta la stessa: ridurre ciò che può eseguire codice esterno e mantenere il comportamento del server prevedibile, locale e verificabile.