In breve: un penetration test per la Sua applicazione PHP mostra quali debolezze un aggressore potrebbe davvero sfruttare, prima che qualcuno lo faccia. Insieme a partner specializzati verifichiamo applicazione e server in una portata concordata per iscritto e consegniamo un rapporto con misure in ordine di priorità. Dopo la correzione verifichiamo in un ritest se le vulnerabilità sono state chiuse.
Perché un penetration test per applicazioni PHP è sensato
PHP2Shell ha mostrato che anche la base di un'applicazione, PHP stesso, può contenere una vulnerabilità critica. La maggior parte delle intrusioni nelle applicazioni PHP passa però da debolezze note nel codice proprio o nella configurazione: SQL injection, cross-site scripting, upload di file non sicuri, sessioni deboli, dipendenze obsolete o aree di amministrazione aperte. L'OWASP Top 10 riassume queste categorie.
Uno sguardo indipendente dall'esterno trova ciò che nella quotidianità sfugge. Per la direzione e gli organi di controllo fornisce una base affidabile per valutare i rischi e impiegare il budget in modo mirato. Per gli sviluppatori è un concreto elenco di lavoro.
Audit o penetration test: che cosa fa al caso Suo?
| Forma | Che cosa viene verificato | Adatta se |
|---|---|---|
| Audit di configurazione | server, PHP, web server, accessi, backup | vuole conoscere lo stato dell'infrastruttura |
| Code review | codice sorgente dell'applicazione con accesso | esistono sviluppi propri o personalizzazioni importanti |
| Penetration test black-box | applicazione dall'esterno senza conoscenze preliminari | vuole vedere la prospettiva di un aggressore esterno |
| Penetration test grey/white-box | applicazione con account di test o codice | vuole trovare il più possibile in tempo limitato |
Spesso è sensata una combinazione, ad esempio un audit di configurazione del server insieme a un test grey-box dell'applicazione. Un test puramente black-box appare realistico, ma consuma molto tempo nell'esplorazione. Con account di test e conoscenza della struttura, i verificatori trovano in genere più debolezze nello stesso tempo.
Oltre all'applicazione vale la pena guardare l'ambiente: quale versione di PHP gira, le interfacce di amministrazione sono raggiungibili pubblicamente, i backup si trovano nella directory web, le dipendenze sono aggiornate? Questi punti li verifichiamo nell'audit, perché nella pratica pesano spesso più di un singolo errore nel codice.
Quando è il momento giusto per un test?
Un penetration test rende di più se si svolge in un punto sensato del ciclo di vita dell'applicazione. Occasioni tipiche sono:
- prima del lancio di una nuova applicazione, di uno shop o di un portale clienti
- dopo modifiche importanti, ad esempio nuovi metodi di pagamento, interfacce o procedure di login
- dopo un incidente, quando bonifica e hardening sono conclusi e desidera un controllo indipendente
- a intervalli regolari, se clienti, partner o la Sua gestione del rischio lo richiedono
Ha poco senso un test finché sono aperte vulnerabilità note. Chi gestisce ancora versioni di PHP senza patch dovrebbe prima ristabilire lo stato di base. Altrimenti si paga un test per confermare ciò che è già noto.
Come aiuta concretamente PHP SOS?
- Definire la portata: chiariamo con Lei quali applicazioni, server e funzioni vengano verificati, quale tipo di test sia adatto e che cosa sia esplicitamente escluso. Il risultato è un incarico scritto con finestra temporale e referenti.
- Preparare: vengono messi a disposizione account di test, accessi all'ambiente di test e un backup recente. Il Suo hoster viene informato, se necessario, affinché il test non venga bloccato come un vero attacco.
- Verificare: i nostri partner specializzati testano secondo metodi riconosciuti, tra l'altro lungo le categorie OWASP. I reperti critici li segnaliamo subito, non solo nel rapporto finale.
- Riferire: riceve un rapporto con sintesi per il management e parte tecnica.
- Ritest: dopo la correzione verifichiamo di nuovo le debolezze trovate e confermiamo che cosa è stato chiuso.
Molti reperti si possono evitare già in anticipo. Le guide su SQL injection in PHP, upload di file sicuri e sessioni in PHP aiutano gli sviluppatori nella preparazione.
Che cosa riceve e che cosa ci serve
Il rapporto contiene ogni debolezza trovata con descrizione, punto interessato, valutazione del rischio e raccomandazione concreta per la correzione. Una sintesi per la direzione inquadra i risultati senza gergo tecnico. Dopo il ritest riceve una conferma di quali punti siano stati risolti. Strumenti di attacco o exploit eseguibili non fanno parte del rapporto.
Da Lei ci servono:
- un'autorizzazione scritta della persona legittimata per ogni sistema da testare, anche se si trova presso un hoster
- account di test con i ruoli da verificare
- un ambiente di test oppure l'autorizzazione a testare nell'ambiente di produzione in una finestra temporale
- un referente tecnico durante il test
- per la code review: accesso al repository
Che cosa non promettiamo
Un penetration test non trova ogni vulnerabilità. È un'istantanea nella portata concordata; nuove funzioni o nuove vulnerabilità nelle dipendenze possono domani dare un quadro diverso. Non citiamo certificati o sigilli che non abbiamo e non rilasciamo attestati che sostituiscano obblighi giuridici. Se un test soddisfi i Suoi obblighi, ad esempio ai sensi della NIS2, lo chiarisca con i Suoi esperti di diritto e compliance.
La correzione dei reperti la assumiamo, se lo desidera, direttamente noi oppure insieme alla Sua agenzia. Per server e configurazione di PHP si presta l'hardening del server.
Domande frequenti
Qual è la differenza tra audit di sicurezza e penetration test?
Un audit verifica configurazione, processi e codice sulla base di requisiti ed esperienza, spesso con accesso ai sistemi. Un penetration test cerca in modo mirato, e con la Sua autorizzazione, di sfruttare le debolezze per mostrarne l'effetto reale. Le due cose si completano.
Un penetration test è pericoloso per la mia applicazione PHP?
Un test può mettere sotto carico i sistemi o modificare dei dati. Per questo portata, finestra temporale e limiti vengono fissati prima per iscritto, e raccomandiamo, dove possibile, di usare un ambiente di test. Un backup recente è sempre richiesto.
Un penetration test trova tutte le vulnerabilità?
No. Un test mostra le debolezze trovate nella portata e nel periodo concordati. È un'istantanea e riduce il rischio, ma non dimostra che non esistano altre vulnerabilità.
Un penetration test aiuta con la NIS2?
Verifiche periodiche delle misure di sicurezza sono un elemento abituale per adempiere agli obblighi di gestione del rischio. Quali requisiti valgano concretamente per la Sua impresa lo chiarisca per favore con esperti di diritto e compliance.