--- title: "Audit di sicurezza per applicazioni PHP legacy: una guida pratica per identificare e risolvere le vulnerabilità" description: "Audit sicurezza PHP legacy: SQL injection, XSS, sessioni, CSRF con grep e Psalm taint analysis. Checklist OWASP e piano di remediation. Caso reale PMI." canonical: "https://www.mauriziofonte.it/blog/post/audit-sicurezza-php-legacy-guida-pratica-vulnerabilita.html" author: "Maurizio Fonte" date: "2025-09-04T08:47:52+02:00" modified: "2026-04-14T17:48:55+02:00" section: "Penetration Testing" tags: ["Penetration Testing", "Sicurezza Applicazioni"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Penetration Testing](https://www.mauriziofonte.it/blog/cat/penetration-testing.html) [Sicurezza Applicazioni](https://www.mauriziofonte.it/blog/cat/sicurezza-applicazioni.html) # [Audit di sicurezza per applicazioni PHP legacy: una guida pratica per identificare e risolvere le vulnerabilità](https://www.mauriziofonte.it/blog/post/audit-sicurezza-php-legacy-guida-pratica-vulnerabilita.html) Giovedì 4 Settembre 2025, alle 08:47 ![Audit di sicurezza per applicazioni PHP legacy: una guida pratica per identificare e risolvere le vulnerabilità](https://www.mauriziofonte.it/image/002240200-audit-sicurezza-php-legacy-guida-pratica-vulnerabilita.jpg) A novembre 2024, durante un subentro su un gestionale PHP 7.0 di una PMI veneta - azienda metalmeccanica con 30 dipendenti, gestionale custom per ordini, produzione e fatturazione - ho condotto un audit di sicurezza che ha rivelato un quadro preoccupante: 14 endpoint con SQL injection diretta (variabili `$_GET` concatenate nelle query MySQL senza alcun escaping), 23 punti dove l'output utente veniva stampato senza `htmlspecialchars` (XSS riflesso), sessioni senza `session_regenerate_id` dopo il login (session fixation), zero protezione CSRF su qualsiasi form, e un file `phpinfo.php` nella webroot accessibile a chiunque che mostrava tutte le variabili d'ambiente, incluse le credenziali del database. Il gestionale era in produzione da sette anni e nessuno aveva mai condotto un audit di sicurezza. Secondo l'[OWASP Top 10 2021](https://owasp.org/Top10/) - la classificazione di riferimento delle vulnerabilità più critiche nelle applicazioni web - i problemi trovati coprivano le prime tre categorie: A01 Broken Access Control, A03 Injection e A07 Cross-Site Scripting. Il gestionale era esposto a internet senza WAF, senza rate limiting e senza header di sicurezza. Qualsiasi attaccante con competenze anche basiche avrebbe potuto estrarre l'intero database con un singolo parametro URL manipolato. In tre giorni di audit e due settimane di remediation ho chiuso tutte le 37 vulnerabilità critiche senza interrompere l'operatività del gestionale. In questo articolo ti racconto il metodo - lo stesso che applico a ogni audit di sicurezza su applicazioni PHP legacy. > Stai cercando un **Consulente Informatico** esperto per un audit di sicurezza del tuo applicativo PHP? Nel mio [profilo professionale](https://www.mauriziofonte.it/pages/about) trovi l'esperienza concreta su vulnerability assessment, penetration testing e hardening di applicazioni legacy. [Contattami per una consulenza diretta](https://www.mauriziofonte.it/pages/contattami). ## Come si conduce un audit di sicurezza su PHP legacy in 3 giorni? L'audit segue tre fasi: discovery automatizzata (giorno 1), analisi manuale dei risultati (giorno 2), e classificazione con piano di remediation (giorno 3). L'obiettivo non è trovare ogni possibile vulnerabilità - è identificare le falle critiche che un attaccante può sfruttare con facilità. ### Giorno 1: discovery automatizzata con grep e Psalm Il primo strumento è il più semplice: `grep`. Le vulnerabilità SQL injection su codice PHP legacy hanno pattern riconoscibili - variabili `$_GET`, `$_POST` o `$_REQUEST` concatenate in stringhe SQL: ```bash # SQL Injection: variabili utente concatenate in query grep -rn "\$_GET\|\$_POST\|\$_REQUEST\|\$_COOKIE" . --include="*.php" | \ grep -i "query\|select\|insert\|update\|delete\|where" | wc -l # XSS: output senza escaping grep -rn "echo.*\$_GET\|echo.*\$_POST\|print.*\$_REQUEST" . --include="*.php" | wc -l # File upload senza validazione grep -rn "move_uploaded_file\|\$_FILES" . --include="*.php" # Informazioni esposte find . -name "phpinfo.php" -o -name "info.php" -o -name "test.php" find . -name "*.sql" -o -name "*.sql.gz" -o -name "*.bak" ``` Per un'analisi più sofisticata, [Psalm con taint analysis](https://psalm.dev/docs/security_analysis/) è lo strumento più potente disponibile gratuitamente. Psalm traccia il flusso dei dati dall'input utente (`$_GET`, `$_POST`) attraverso tutto il codice fino ai "sink" pericolosi (query SQL, `echo`, `header`, `include`). Se trova un percorso non sanitizzato tra un source e un sink, segnala una vulnerabilità con il flusso completo dei dati: ```bash # Installare Psalm composer require --dev vimeo/psalm # Inizializzare la configurazione vendor/bin/psalm --init # Eseguire l'analisi di sicurezza con taint analysis vendor/bin/psalm --taint-analysis ``` L'output di Psalm è preciso: indica il file, la riga, il tipo di vulnerabilità (SQLi, XSS, command injection, file inclusion) e il percorso del dato dall'input utente al sink pericoloso. Nel caso veneto, Psalm ha trovato 11 delle 14 SQL injection (le altre 3 erano in file che usavano `mysql_query` - funzioni troppo vecchie per essere tracciate dal type system di Psalm) e 19 dei 23 punti XSS. ### Giorno 2: analisi manuale e verifica I risultati automatizzati vanno verificati manualmente - sia per eliminare i falsi positivi sia per trovare le vulnerabilità che gli strumenti automatici non rilevano. La verifica manuale che conduco: Per ogni SQL injection segnalata, verifico se c'è un percorso realmente sfruttabile dall'esterno. Una query con variabile concatenata che viene solo da una sessione autenticata è meno critica di una che accetta input da `$_GET` senza autenticazione. Per ogni XSS, verifico se l'output è in un contesto HTML dove JavaScript può essere eseguito - un `echo` dentro un attributo `value=""` è sfruttabile diversamente da un `echo` dentro un commento HTML. L'[OWASP ZAP](https://www.zaproxy.org/) (Zed Attack Proxy) completa l'analisi con uno scan dinamico - uno scanner che invia richieste reali all'applicazione e verifica le risposte per identificare vulnerabilità che l'analisi statica non può trovare (come problemi di configurazione del web server, header mancanti, cookie insicuri): ```bash # OWASP ZAP spider + active scan (su ambiente di staging, MAI in produzione) zap-cli spider http://staging.esempio.it zap-cli active-scan http://staging.esempio.it zap-cli report -o zap-report.html -f html ``` ### Giorno 3: classificazione e piano di remediation Le vulnerabilità trovate vanno classificate per severità e sfruttabilità. Il sistema che uso è il CVSS (Common Vulnerability Scoring System) semplificato in tre livelli: - **Critico (fix immediato):** SQL injection raggiungibile senza autenticazione, RCE, file upload senza validazione, credenziali esposte (`phpinfo.php`). Fix entro 48 ore. - **Alto (fix entro 1 settimana):** XSS riflesso su pagine pubbliche, sessioni senza regenerate, assenza CSRF su form critici (cambio password, ordini). - **Medio (fix entro 1 mese):** XSS stored in pannello admin, header di sicurezza mancanti, configurazioni subottimali. Nel caso veneto, il piano di remediation ha prodotto 8 interventi critici (chiusura SQL injection e rimozione phpinfo.php), 12 interventi alti (XSS, sessioni, CSRF) e 17 interventi medi. ## Le correzioni: da SQL injection a prepared statement in un pomeriggio La correzione delle SQL injection su codice legacy PHP è meccanica ma richiede attenzione: ogni query con variabile concatenata deve essere convertita a prepared statement. Su un gestionale con 14 endpoint vulnerabili, il lavoro richiede un pomeriggio: ```php prepare("SELECT * FROM orders WHERE id = :id"); $stmt->execute(['id' => $_GET['id']]); $result = $stmt->fetchAll(); ``` Per il XSS, la regola è `htmlspecialchars()` su qualsiasi output che include dati variabili: ```php Ordine " . $_GET['num'] . ""; // DOPO: output sanitizzato echo "

Ordine " . htmlspecialchars($_GET['num'], ENT_QUOTES, 'UTF-8') . "

"; ``` Ho descritto il processo completo di refactoring sicuro - inclusa l'introduzione di test che verificano che le correzioni non rompano il funzionamento - nell'articolo sul [refactoring di codice PHP legacy](https://www.mauriziofonte.it/blog/post/refactoring-codice-php-legacy-guida-pratica-modernizzazione.html), e l'approccio al [subentro su codebase senza documentazione](https://www.mauriziofonte.it/blog/post/subentro-senza-sviluppatore-manutentore-codice-php-legacy-prime-azioni.html) che copre anche gli aspetti non-sicurezza. L'audit di sicurezza su applicazioni PHP legacy non è un lusso riservato alle enterprise - è una necessità per qualsiasi applicazione che gestisce dati di clienti, ordini o fatture. Il costo di tre giorni di audit e due settimane di remediation è una frazione del costo di un data breach - che secondo il GDPR può comportare sanzioni fino al 4% del fatturato globale, oltre al danno reputazionale e alla perdita di fiducia dei clienti. Se il tuo gestionale o e-commerce PHP non ha mai subìto un audit di sicurezza, la domanda non è se ci sono vulnerabilità - è quante ce ne sono e quanto sono gravi. [Contattami](https://www.mauriziofonte.it/pages/contattami) per scoprirlo prima che lo scopra qualcun altro. Dall'articolo al lavoro vero Questo problema di sicurezza, sul tuo sistema Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti. [Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Strumenti gratuiti per questo articolo Funzionano nel browser, sullo stesso tema dell'articolo. - [SQL formatter](https://www.mauriziofonte.it/strumenti/sql-formatter) - [Migrazione database senza downtime](https://www.mauriziofonte.it/strumenti/migrazione-database-senza-downtime) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteIntroduzione ai test automatici su codebase PHP legacy: come iniziare senza riscrivere tutto3 Settembre 2025](https://www.mauriziofonte.it/blog/post/test-automatici-codebase-php-legacy-senza-riscrittura.html)[Articolo successivo »Refactoring del codice PHP legacy: guida pratica per modernizzare un'applicazione senza riscriverla5 Settembre 2025](https://www.mauriziofonte.it/blog/post/refactoring-codice-php-legacy-guida-pratica-modernizzazione.html) ### Articoli correlati a Audit di sicurezza per applicazioni PHP legacy: una guida pratica per identificare e risolvere le vulnerabilità - [Audit tecnico iniziale di un progetto PHP legacy: metodo operativo per i primi 30 giorni](https://www.mauriziofonte.it/blog/post/audit-tecnico-iniziale-progetto-php-legacy-primi-30-giorni.html) Un gestionale PHP 7.0 ereditato da un freelance sparito: 43.000 righe di codice, nessuna documentazione, e il titolare che deve decidere se investire · 9 Settembre 2025 ![Audit tecnico iniziale di un progetto PHP legacy: metodo operativo per i primi 30 giorni](https://www.mauriziofonte.it/image/002270070-audit-tecnico-iniziale-progetto-php-legacy-primi-30-giorni.jpg) - [Sicurezza e Validazione in PHP: prevenire gli attacchi](https://www.mauriziofonte.it/blog/post/sicurezza_e_validazione_prevenire_gli_attacchi_xss_validation_security_class_php.html) La vecchia ricetta della "classe di sicurezza" che ripulisce GET e POST all'ingresso non protegge più nulla: è un anti pattern che dà falsa sicurezza. · 13 Gennaio 2026 ![Sicurezza e Validazione in PHP: prevenire gli attacchi](https://www.mauriziofonte.it/image/000130070-sicurezza_e_validazione_prevenire_gli_attacchi_xss_validation_security_class_php.jpg) - [SQL injection nel 2025: perché continua a colpire le PMI e come prevenirla definitivamente](https://www.mauriziofonte.it/blog/post/sql-injection-2025-pmi-prevenzione-prepared-statements-orm.html) Ho trovato una SQL injection in un gestionale di ordini PHP usato da un'azienda con 80 dipendenti. Il codice era del 2019, aggiornato più volte, · 10 Ottobre 2025 ![SQL injection nel 2025: perché continua a colpire le PMI e come prevenirla definitivamente](https://www.mauriziofonte.it/image/003490070-sql-injection-2025-pmi-prevenzione-prepared-statements-orm.jpg) - [Sicurezza del codice generato da AI: audit sistematico di output ChatGPT e Copilot in PHP](https://www.mauriziofonte.it/blog/post/sicurezza-codice-generato-ai-chatgpt-copilot-audit-php.html) Ho analizzato 200 snippet PHP generati da Copilot e ChatGPT nel contesto di progetti clienti: il 23 conteneva vulnerabilità, di cui il 8 classificabili · 21 Ottobre 2025 ![Sicurezza del codice generato da AI: audit sistematico di output ChatGPT e Copilot in PHP](https://www.mauriziofonte.it/image/002900070-sicurezza-codice-generato-ai-chatgpt-copilot-audit-php.jpg) - [DevSecOps: perché integrare sicurezza e sviluppo è essenziale per la tua azienda](https://www.mauriziofonte.it/blog/post/devsecops-integrare-sicurezza-sviluppo-azienda.html) La maggior parte delle PMI italiane tratta la sicurezza come un controllo finale prima del rilascio. Il DevSecOps capovolge questo approccio, · 19 Mag 2025 ![DevSecOps: perché integrare sicurezza e sviluppo è essenziale per la tua azienda](https://www.mauriziofonte.it/image/001190070-devsecops-integrare-sicurezza-sviluppo-azienda.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Audit di sicurezza per applicazioni PHP legacy: una guida pratica per identificare e risolvere le vulnerabilità", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/audit-sicurezza-php-legacy-guida-pratica-vulnerabilita.html Pubblicato: 2025-09-04 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.