In breve: un code review di sicurezza per PHP è la lettura mirata del codice sorgente con una domanda: dove possono input esterni fare qualcosa che non dovrebbero? Si sono dimostrate valide due forme, un review di ogni modifica e un review di base dell'intero progetto, sostenuti dall'analisi statica con PHPStan o Psalm. Le vulnerabilità nell'interprete PHP come PHP2Shell un review non le trova, ma trova i molti errori che nascono nel proprio codice.
Perché guardare proprio ora nel proprio codice?
PHP2Shell ha occupato soprattutto gli admin nell'ultima settimana di ottobre 2026. Aggiornare, riavviare, documentare: il lavoro era sul server. Per i team di sviluppo resta dopo una domanda scomoda. Se un aggressore può eseguire codice tramite un'altra vulnerabilità, che cosa trova nella nostra applicazione? E quante di queste vulnerabilità le abbiamo scritte noi?
La OWASP Top 10 mostra da anni che la maggior parte delle debolezze nelle applicazioni web non è esotica. Controllo degli accessi mancante, injection e configurazione insicura stanno ai primi posti. Sono errori che un occhio esperto trova nel codice sorgente molto prima che un aggressore li provi.
A ciò si aggiunge un motivo pratico. Molte aziende in questo momento fanno comunque verificare, aggiornare e rafforzare i propri server. Chi esamina nello stesso passaggio la propria applicazione colma la lacuna tra esercizio e sviluppo. Un server rafforzato con un'applicazione vulnerabile resta attaccabile, e un'applicazione scritta bene su un PHP non aggiornato lo è altrettanto.
Review di base o review delle modifiche?
Il Cheat Sheet OWASP sul Secure Code Review distingue due tipi, che nella pratica si integrano:
| Tipo | Quando | Ampiezza | Obiettivo |
|---|---|---|---|
| Review di base (baseline) | Nuovo progetto, grande release, dopo un incidente | Intero progetto, ponderato in base al rischio | Rilevare l'insieme delle vulnerabilità |
| Review delle modifiche (diff) | Ogni pull request | Solo il codice modificato | Evitare nuovi errori |
Un review di base dopo un incidente è particolarmente prezioso. Chi ha appena bonificato un server dovrebbe sapere se l'applicazione offre altri punti d'ingresso. Il review delle modifiche mantiene pulito lo stato in seguito, perché ogni modifica viene letta anche dal punto di vista della sicurezza prima di essere integrata.
Code review in PHP: dove si concentrano gli errori di sicurezza
Nei progetti PHP vale la pena guardare in modo mirato determinate funzioni e schemi. Non sono vietati, ma ogni occorrenza merita la domanda se vi possano giungere dati esterni.
| Schema nel codice | Possibile rischio | Approfondimento |
|---|---|---|
| SQL tramite concatenazione di stringhe con variabili | SQL injection | Prevenire la SQL injection in PHP |
unserialize() su dati esterni |
Object injection | Deserializzazione insicura in PHP |
include o require con percorso variabile |
Inclusione di file esterni | Prevenire Local e Remote File Inclusion |
exec(), system(), shell_exec(), proc_open() |
Esecuzione di comandi | Command injection |
Output senza htmlspecialchars() |
Cross-site scripting | Escaping adatto al contesto |
== con token o hash |
La conversione di tipo aggira le verifiche | hash_equals(), confronti rigorosi |
eval(), extract() su input |
Code injection o variable injection | Per lo più da eliminare senza sostituzione |
Una prima panoramica rapida riesce con una semplice ricerca. Non sostituisce un review, ma mostra da dove cominciare:
# Occorrenze di funzioni rischiose nel proprio codice (vendor escluso)
grep -rnE "\b(unserialize|eval|extract|shell_exec|exec|system|passthru|proc_open)\s*\(" src/ app/ 2>/dev/null
Altrettanto importante è ciò che nel codice manca. Ogni controller verifica se l'utente connesso possa vedere o modificare proprio questo record? Gli upload sono limitati per tipo e luogo di archiviazione? Simili lacune non le trova alcuna ricerca di nomi di funzione, solo la lettura del flusso.
Strumenti che sostengono il review
L'analisi statica verifica il codice senza eseguirlo. PHPStan e Psalm trovano errori di tipo, codice non raggiungibile e ipotesi sbagliate sui valori di ritorno. Psalm offre inoltre un'analisi taint, che segue se dati provenienti dalle richieste confluiscano senza verifica in punti critici. Entrambi si possono inasprire per gradi, così che anche i progetti più vecchi possano iniziare. Una panoramica la dà Analisi statica: PHPStan e Psalm.
# Analisi statica nel progetto, aumentare gradualmente il livello
vendor/bin/phpstan analyse src --level=5
# Analisi taint con Psalm
vendor/bin/psalm --taint-analysis
Gli strumenti forniscono indicazioni, non giudizi. Ogni riscontro richiede una valutazione, e un rapporto vuoto non significa che l'applicazione sia sicura.
Altrettanto importante quanto trovare è mettere per iscritto. Ogni rilievo dovrebbe essere registrato con punto di ritrovamento, breve descrizione, stima del rischio, correzione raccomandata e stato, meglio direttamente nel sistema di ticket del team. Così si può ricostruire che cosa sia stato risolto, che cosa deliberatamente accettato e che cosa sia ancora aperto. Dopo la correzione vale la pena un secondo sguardo: la causa è eliminata o solo quel sintomo? Lo stesso schema compare in altri punti del codice? Un errore commesso una volta, per esperienza, raramente si trova in un solo punto.
Una checklist per il proprio team
Per i review delle modifiche si è dimostrata valida un'elenco breve e fisso. Appartiene al modello per le pull request:
- Da dove provengono tutti i dati che questa modifica elabora e vengono verificati lato server?
- Le query al database sono costruite esclusivamente con segnaposto?
- Ogni output è sottoposto a escape per il suo contesto, cioè HTML, attributo, JavaScript o URL?
- Il codice verifica l'autorizzazione per proprio questo oggetto, non solo il login?
- Password, token o dati personali finiscono nei log o nei messaggi di errore?
- Ci sono segreti nel codice o in file sotto controllo di versione?
- Sono state aggiunte nuove dipendenze e sono mantenute?
Faccia leggere le parti critiche per la sicurezza, come login, gestione dei permessi, flussi di pagamento e upload, sempre a una seconda persona che non abbia partecipato al codice. L'occhio esterno trova ipotesi che l'autore ritiene ovvie.
Come aiuta concretamente PHP SOS?
- Con partner specializzati eseguiamo un review di base della sua applicazione PHP, ponderato in base alle parti a più alto rischio.
- Impostiamo PHPStan o Psalm in modo adatto allo stato del suo progetto e scriviamo la checklist per le sue pull request.
- Colleghiamo il review a uno sguardo su server e configurazione, perché molte vulnerabilità nascono solo dall'interazione.
- Dove si desidera una verifica dall'esterno, integriamo il review con audit di sicurezza e penetration test.
Conclusione: un code review è il punto più economico per correggere gli errori di sicurezza, cioè prima che vengano rilasciati. Chi verifica ogni modifica con una breve lista e di tanto in tanto riesamina l'intero progetto riduce la superficie di attacco in modo duraturo.
Domande frequenti
Qual è la differenza tra code review e penetration test?
Un code review legge il codice sorgente e trova errori prima che vengano rilasciati. Un penetration test attacca dall'esterno l'applicazione in esecuzione. I due si integrano: il review trova le cause, il test mostra che cosa è effettivamente sfruttabile.
Un code review trova vulnerabilità come PHP2Shell?
No. PHP2Shell si trova nell'interprete PHP, non nel codice dell'applicazione. Contro di esso aiuta solo un aggiornamento di PHP con riavvio. Un review trova errori nel proprio codice, ad esempio injection, controlli delle autorizzazioni mancanti o deserializzazione insicura.
PHPStan o Psalm bastano per un review di sicurezza?
Sono una buona base e trovano automaticamente molti errori. Errori logici, controlli delle autorizzazioni mancanti e ipotesi sbagliate sui flussi, però, li riconosce solo una persona che sa che cosa l'applicazione deve fare.
Quanto dura un code review di sicurezza?
Dipende dall'ampiezza. Un review di ogni modifica nella pull request richiede poco tempo. Un review completo di un progetto cresciuto nel tempo è un progetto a sé, che si limita alle parti più importanti in base al rischio.