Vulnerabilità PHP: tipi più comuni e come prevenirle
Le vulnerabilità PHP sono errori di programmazione, configurazioni deboli o componenti non aggiornati che permettono a un attaccante di leggere dati, modificare un sito o prendere il controllo del server. Nella maggior parte dei casi non dipendono dal linguaggio in sé, ma da come il codice gestisce i dati ricevuti dall'utente e da quanto a lungo resta senza aggiornamenti. In questa guida vediamo le falle più diffuse, come vengono sfruttate e quali misure riducono davvero il rischio.
Cosa sono le vulnerabilità PHP e perché sono così diffuse
PHP è alla base di moltissimi siti, gestionali e CMS, WordPress compreso. Questa diffusione lo rende un bersaglio interessante: una falla in un componente molto usato può interessare migliaia di installazioni, e gli attaccanti la cercano con strumenti automatici, senza scegliere una vittima precisa.
Nella pratica le falle nascono da tre fonti: il codice scritto in casa, le librerie e i plugin di terze parti, e l'ambiente su cui il tutto gira (versione di PHP, server web, permessi). Una piccola azienda milanese con un sito vetrina e un'area clienti può avere problemi in tutte e tre le aree senza saperlo.
Vulnerabilità ed exploit: la differenza
La vulnerabilità è il difetto; l'exploit è la tecnica o il programma che lo sfrutta. Una falla può esistere per mesi senza che nessuno la usi, ma quando diventa pubblica compaiono spesso exploit pronti all'uso. Per approfondire il passaggio dal difetto all'attacco, leggi la nostra guida su come funziona un exploit informatico.
CVE e CVSS: come leggere gli avvisi
Le falle note in software e librerie ricevono un identificativo CVE (Common Vulnerabilities and Exposures), che permette a tutti di riferirsi allo stesso problema. Al CVE è spesso associato un punteggio CVSS, da 0 a 10: da 7,0 a 8,9 la gravità è alta, da 9,0 in su è critica.
Il punteggio è un punto di partenza, non un verdetto. Una falla con punteggio medio su un sito esposto e pieno di dati può essere più urgente di una critica su un sistema isolato. Conta anche se esiste già un exploit pubblico.
Le vulnerabilità nel codice PHP più comuni
Quasi tutte le falle applicative hanno la stessa radice: l'applicazione si fida di un dato che arriva dall'esterno. Questi sono i casi più frequenti.
- SQL injection: l'input dell'utente viene incollato dentro una query SQL, e l'attaccante può leggere o modificare il database. La difesa principale sono le query parametrizzate (prepared statements), per esempio con PDO.
- Cross site scripting (XSS): un dato non filtrato viene mostrato in una pagina e permette di eseguire script nel browser della vittima. Si previene con l'escaping dell'output, ad esempio con htmlspecialchars. Ne parliamo nella guida su cross site scripting, esempi e prevenzione.
- File inclusion: se un parametro decide quale file includere con include o require, l'attaccante può far caricare file non previsti, a volte con esecuzione di codice.
- Upload di file non controllato: se un modulo accetta qualsiasi file e lo salva in una cartella eseguibile, un file PHP malevolo può diventare una backdoor.
- Command injection ed eval: funzioni come exec, system o eval alimentate con dati non verificati consentono di eseguire comandi sul server.
- Deserializzazione non sicura: usare unserialize su dati controllabili dall'utente può portare a comportamenti imprevisti e, in certi casi, a esecuzione di codice.
- Confronti deboli e autenticazione fragile: l'operatore == converte i tipi e, in certi casi, produce risultati inattesi nei controlli. A questo si aggiungono sessioni gestite male e assenza di protezione CSRF.
Molte di queste categorie compaiono anche nell'elenco dei rischi per le applicazioni web: ne trovi un quadro d'insieme nella guida alle vulnerabilità delle applicazioni web e OWASP Top 10.
Dalla falla all'attacco: come vengono sfruttate
Un attacco raramente si ferma alla prima falla. Un'SQL injection può esporre le credenziali degli utenti; un upload non controllato può dare esecuzione di codice remoto. Da lì l'attaccante cerca di muoversi: se il processo web gira con permessi troppo ampi, una privilege escalation gli permette di passare da un account limitato a uno con più diritti sul sistema.
Per questo i siti PHP vulnerabili vengono usati anche come punto d'ingresso verso la rete interna. Un'applicazione esposta e trascurata può diventare il primo passo di una catena che, nei casi peggiori, termina con un ransomware. Non serve inventare scenari: basta ricordare che i gruppi criminali cercano il percorso più facile, e un componente non aggiornato lo è.
Per capire quanto un incidente può pesare sul bilancio, vedi quanto costa un attacco hacker a una PMI.
Versioni, plugin e dipendenze: il rischio del software non più supportato
Una parte consistente delle vulnerabilità PHP non è nel codice scritto da voi, ma in ciò che avete installato. Le versioni di PHP hanno un ciclo di vita: quando una versione esce dal supporto non riceve più correzioni di sicurezza, anche se il sito continua a funzionare. Le date ufficiali si trovano nella pagina delle versioni supportate sul sito di PHP; è la fonte da consultare, non la memoria.
Lo stesso vale per plugin, temi e librerie gestite con Composer. Un plugin abbandonato dal suo sviluppatore è un rischio permanente. Il comando composer audit, nelle versioni di Composer che lo includono, aiuta a segnalare le dipendenze con avvisi di sicurezza noti.
Il ragionamento è identico a quello dei dispositivi connessi: quando un prodotto non è più supportato, le falle scoperte dopo restano aperte, e il problema non è il malfunzionamento ma la maggiore esposizione agli attacchi. Molti dispositivi hanno pannelli di gestione web; se vuoi approfondire, leggi la guida alle vulnerabilità IoT e agli attacchi ai dispositivi connessi. Per organizzare gli aggiornamenti nel tempo è utile un processo di patch management.
Come ridurre le vulnerabilità PHP: una checklist pratica
Non esiste una misura unica, ma un insieme di abitudini che, applicate con costanza, tolgono agli attaccanti la maggior parte delle strade facili.
- Aggiorna PHP e le dipendenze a una versione supportata e verifica la compatibilità in un ambiente di prova prima di andare in produzione.
- Tratta ogni input come non fidato: validalo lato server, usa query parametrizzate e fai l'escaping dell'output.
- Limita i permessi: il processo web deve poter scrivere solo dove serve, e le cartelle di upload non devono eseguire codice.
- Non mostrare errori agli utenti: disattiva la visualizzazione degli errori in produzione e registrali in un log protetto.
- Proteggi accessi e sessioni: password robuste, autenticazione a più fattori sui pannelli di amministrazione, cookie di sessione configurati correttamente e token anti-CSRF.
- Rimuovi ciò che non usi: plugin, temi e file di prova dimenticati sul server ampliano inutilmente la superficie d'attacco.
- Aggiungi un WAF e il monitoraggio dei log come livello ulteriore, senza considerarli sostitutivi del codice corretto.
Se il sito gira su WordPress, trovi indicazioni specifiche nella guida su come proteggere un sito WordPress dagli attacchi.
Come verificare se la tua applicazione è vulnerabile
La revisione del codice e i controlli degli sviluppatori sono il primo passo, ma servono anche occhi esterni. Un vulnerability assessment cerca in modo sistematico falle note e configurazioni deboli; un penetration test prova invece a sfruttarle come farebbe un attaccante reale, per capire l'impatto concreto. Le attività di red teaming, più ampie, mettono alla prova anche persone e processi, e hanno senso quando le basi sono già solide.
Per un'applicazione PHP, chiedi che il test copra autenticazione, gestione delle sessioni, upload, moduli e API, non solo la pagina iniziale. Pretendi un report con priorità chiare, indicazioni di correzione e un nuovo controllo dopo gli interventi. Per un metodo più automatizzato, puoi vedere come funziona il penetration test automatizzato di FRED.
Conclusione
Le vulnerabilità PHP sono quasi sempre prevedibili: input non verificato, software non aggiornato, permessi troppo larghi. Ciò significa che si possono prevenire con disciplina e controlli periodici. Se vuoi capire in quale stato si trova la sicurezza delle tue applicazioni, il team di Fred for Security può aiutarti a individuare le falle e a stabilire da dove partire per correggerle.
Domande frequenti
Come capire se la mia versione di PHP è ancora supportata?
Controlla la versione in uso sul server e confrontala con la tabella delle versioni supportate sul sito ufficiale di PHP, dove sono indicate le date di fine supporto. Se la tua versione non riceve più correzioni di sicurezza, pianifica subito un aggiornamento e verifica la compatibilità del codice.
Un firewall applicativo (WAF) basta a proteggere un sito PHP?
No. Un WAF riduce il rischio e può bloccare molti tentativi comuni, ma non corregge il codice vulnerabile. Va considerato un livello di difesa aggiuntivo, da affiancare a codice sicuro, aggiornamenti regolari, configurazione corretta e test periodici, non un sostituto di queste misure.
Quali conseguenze ha un dispositivo IoT non più supportato dal produttore?
Senza aggiornamenti le falle scoperte dopo la fine del supporto restano aperte, quindi il dispositivo diventa un bersaglio sempre più facile per attacchi informatici. Il rischio non è tanto che smetta di funzionare, quanto che resti acceso in rete diventando un punto d'ingresso. Conviene isolarlo o sostituirlo.
Perché gli aggiornamenti dei dispositivi IoT sono fondamentali per la sicurezza?
Perché chiudono vulnerabilità note e prevengono attacchi informatici. Eventuali miglioramenti di prestazioni o stabilità sono un effetto secondario, non lo scopo principale. Un dispositivo connesso e mai aggiornato accumula falle pubbliche che chiunque può cercare e sfruttare con strumenti automatici.