Penetration testing di un'applicazione web: come funziona davvero in un'azienda

Quando un'azienda mi chiede un penetration test, la prima cosa che chiarisco è cosa non è: non è passare uno scanner automatico sull'applicazione e consegnare il suo output. Quello è un vulnerability scan, è utile, costa poco, e trova le cose ovvie, ma chiamarlo penetration test è come chiamare "diagnosi medica" la lettura di un termometro. Un penetration test vero è un percorso metodico in cui un essere umano, con la mentalità di chi attacca, esplora un'applicazione per capire come comprometterla davvero, e lo fa trovando le cose che uno scanner non vede: la logica di business che si può aggirare, l'autorizzazione che si può scavalcare, la catena di piccoli difetti che presi singolarmente sono innocui e insieme aprono una breccia. In un'attività di penetration testing, il valore non sta negli strumenti, sta nel ragionamento. In questo articolo racconto cosa succede davvero quando si testa un'applicazione web in azienda: le fasi del lavoro, le vulnerabilità che si trovano più spesso, come si distingue un problema reale da un falso allarme, e come tutto questo si traduce in interventi concreti e prioritizzati. Dalla prospettiva di chi attacca per difendere.

Un penetration test è uno scan automatico?

No, e confondere i due è l'errore che porta le aziende a sentirsi sicure quando non lo sono. Uno scanner automatico confronta l'applicazione con un database di pattern di vulnerabilità note: è veloce, esaustivo sulle cose standardizzabili, e produce molti risultati, una buona parte dei quali falsi positivi. Trova la versione di un componente con una falla nota, l'header di sicurezza mancante, il pattern di SQL injection più banale. È un controllo prezioso, ma ha un limite strutturale: vede solo ciò che è stato programmato per vedere, e un attaccante reale non si limita a quello.

Un penetration test aggiunge l'elemento che lo scanner non ha, l'intelligenza avversaria. Un tester umano capisce cosa fa l'applicazione, qual è la logica del business che implementa, dove stanno i dati che valgono, e ragiona come farebbe un attaccante motivato: non "questa pagina ha una vulnerabilità nel database delle firme", ma "se questo carrello permette di modificare il prezzo lato client e il server non lo ricontrolla, posso comprare a un euro". Questo tipo di ragionamento, sulla logica e non solo sui pattern, è ciò che nessuno scanner sa fare, ed è esattamente dove vivono le vulnerabilità più gravi e più costose delle applicazioni reali. La metodologia di riferimento del settore, la Web Security Testing Guide di OWASP, codifica proprio questo approccio strutturato che va oltre la scansione.

Uno scanner trova ciò che sa cercare; un attaccante trova ciò che tu non hai pensato di proteggere. Il penetration test serve a portare quel secondo sguardo, quello avversario, sul tuo sistema prima che lo faccia qualcuno con intenzioni peggiori.

Quali sono le fasi di un penetration test?

È un percorso strutturato che va dalla conoscenza del bersaglio allo sfruttamento controllato, e ogni fase prepara la successiva. La prima è la ricognizione: si raccoglie tutto il possibile sull'applicazione, le sue tecnologie, i suoi endpoint, il modo in cui gestisce le sessioni, la sua superficie esposta. È la fase in cui ci si fa un'idea di come è costruito il sistema, perché non si può attaccare bene ciò che non si capisce. La seconda è la mappatura: si esplora sistematicamente l'applicazione, si tracciano tutti i suoi punti di ingresso, i flussi, i ruoli utente, e si costruisce una mappa di dove potrebbero annidarsi i problemi.

La terza fase è l'analisi delle vulnerabilità: si esaminano i punti mappati cercando debolezze, combinando strumenti per le verifiche meccaniche e analisi manuale per la logica. La quarta, il cuore del lavoro, è lo sfruttamento controllato: si prova davvero a sfruttare le debolezze trovate, ma in modo controllato e concordato, per dimostrare che la vulnerabilità è reale e capirne l'impatto effettivo. La differenza tra "questa cosa sembra vulnerabile" e "ho dimostrato che da qui si accede ai dati di tutti gli utenti" è tutta in questa fase. La quinta è l'eventuale post-sfruttamento: capire fin dove un attaccante potrebbe spingersi una volta dentro, perché spesso il primo punto d'ingresso non è il danno, è la porta verso il danno. E l'ultima è il report, che traduce tutto in qualcosa di azionabile. Ogni fase ha senso solo se prepara la successiva, e saltarle, come fa uno scanner che va dritto all'analisi, è ciò che fa perdere le vulnerabilità che contano.

Quali vulnerabilità si trovano più spesso?

Si trovano soprattutto i problemi di autorizzazione, i difetti di logica applicativa e le injection meno ovvie, cioè proprio le classi che gli scanner faticano a vedere. La più comune e la più sottovalutata è il controllo degli accessi rotto: l'applicazione mostra all'utente solo ciò che dovrebbe vedere, ma il server non verifica davvero che la richiesta sia autorizzata, così cambiando un identificativo nell'URL o nella richiesta si accede ai dati di un altro utente. È una falla banale da sfruttare e devastante negli effetti, e si trova con impressionante frequenza perché nasce da un controllo mancante, non da un errore di codice visibile.

Subito dopo vengono i difetti di logica di business: l'applicazione fa esattamente quello per cui è programmata, ma il flusso può essere abusato in modi che chi l'ha scritta non aveva previsto. Saltare un passaggio di pagamento, applicare uno sconto più volte, manipolare la quantità per ottenere un rimborso maggiore dell'acquisto. Nessuno scanner li trova, perché non sono bug tecnici, sono il sistema che funziona "correttamente" in uno scenario non previsto. Poi ci sono le injection di seconda mano, dove un dato malevolo viene salvato in un punto e sfruttato quando viene riutilizzato altrove, sfuggendo ai controlli che guardano solo l'ingresso immediato. E le catene: vulnerabilità come la falsificazione di richieste lato server o gli attacchi sulla logica di autenticazione che, concatenate, portano molto più lontano di quanto ciascuna farebbe da sola. Ho raccontato un esempio concreto di queste concatenazioni nell'articolo sugli attacchi alla logica applicativa tra SSRF e OAuth. Se vuoi capire come applico questa prospettiva offensiva alla difesa di un'applicazione reale, nel mio profilo professionale trovi l'esperienza concreta su penetration testing e hardening per le PMI.

Cosa si concorda prima di iniziare?

Si concorda il perimetro, le regole d'ingaggio e l'autorizzazione formale, perché un penetration test è un'attività che senza queste premesse sarebbe indistinguibile da un attacco vero. Prima di toccare qualunque sistema, si definisce il perimetro: quali applicazioni, quali ambienti, quali funzionalità sono nello scope, e cosa è esplicitamente fuori. Questo non è burocrazia, è ciò che evita che il test danneggi sistemi non previsti o tocchi dati che non doveva toccare. Un test senza un perimetro chiaro è un rischio per l'azienda stessa.

Poi si stabiliscono le regole d'ingaggio: in quali orari si può testare, per non impattare la produzione nei momenti critici, quali tecniche sono ammesse e quali no, cosa fare se si scopre una compromissione preesistente, come comunicare se qualcosa va storto durante il test. Si decide anche il livello di conoscenza iniziale: un test "a scatola nera" parte senza informazioni, simulando un attaccante esterno; uno "a scatola bianca" parte con accesso al codice e alla documentazione, ed è più efficiente perché non spreca tempo a scoprire ciò che l'azienda potrebbe semplicemente dire. La scelta dipende da cosa si vuole simulare e dal budget. Soprattutto, si firma l'autorizzazione formale: il documento che rende l'attività lecita, perché senza il consenso scritto del proprietario del sistema, testare la sicurezza di un'applicazione è un reato, non un servizio. È la differenza giuridica fondamentale tra chi attacca per difendere e chi attacca e basta.

C'è anche la questione del quando ha senso fare un penetration test, perché non è un'attività da una volta sola. I momenti giusti sono precisi: prima del lancio di una nuova applicazione che tratta dati sensibili, dopo un cambiamento architetturale importante che può aver introdotto nuove superfici, periodicamente per le applicazioni critiche perché il codice cambia e con esso il rischio, e quando un requisito normativo o un cliente lo richiede esplicitamente. Un test fatto una volta e mai più dà una falsa sicurezza, perché fotografa il rischio in un istante mentre l'applicazione continua a evolvere.

Come si distingue un finding reale da un falso positivo?

Lo si distingue dimostrandolo: un finding reale è uno che si riesce a sfruttare e che ha un impatto concreto, un falso positivo è un allarme che non si traduce in nulla. È qui che il valore umano del penetration test diventa evidente. Uno scanner segnala una potenziale vulnerabilità ogni volta che un pattern corrisponde, e la maggior parte di quelle segnalazioni, una volta verificate, si rivelano non sfruttabili: protette da un altro controllo, irraggiungibili nel contesto reale, o semplicemente falsi riconoscimenti. Consegnare a un'azienda l'output grezzo di uno scanner, pieno di centinaia di "vulnerabilità" la cui maggioranza è rumore, è un disservizio, perché seppellisce i pochi problemi veri sotto una montagna di falsi allarmi e fa perdere fiducia nell'intero esercizio.

Il tester verifica ogni finding rilevante provando a sfruttarlo, e tiene solo quelli che si dimostrano reali e ne misura l'impatto effettivo. Questo lavoro di separazione del segnale dal rumore è una delle cose che giustificano il costo di un penetration test fatto da una persona competente rispetto a uno scan automatico: il primo ti consegna una lista corta di problemi veri e dimostrati, il secondo una lista lunga che devi ancora verificare tu, senza averne gli strumenti. La fiducia in un report di sicurezza nasce proprio da qui: ogni voce è qualcosa che è stato dimostrato, non ipotizzato, e questo cambia completamente come l'azienda può agire di conseguenza.

Come diventa remediation prioritizzata?

Diventa un report che ordina i problemi per rischio reale e dice, per ciascuno, cosa fare, così l'azienda sa da dove partire invece di annegare in un elenco indistinto. Un buon report di penetration test non è una lista di vulnerabilità, è uno strumento decisionale. Ogni finding viene prioritizzato in base al rischio, che è la combinazione di quanto è grave l'impatto se sfruttato e quanto è facile sfruttarlo: una falla che espone tutti i dati dei clienti ed è banale da innescare sta in cima; una debolezza minore e difficile da sfruttare sta in fondo. Questa prioritizzazione è ciò che permette a un'azienda con risorse limitate, e tutte lo sono, di affrontare prima ciò che conta.

Per ogni problema, il report dice anche cosa fare per risolverlo, in termini concreti e comprensibili, non solo "presente vulnerabilità X". E traduce l'impatto tecnico in impatto di business, perché il titolare o il responsabile che deve decidere dove investire il budget di sicurezza non ragiona in termini di vulnerabilità ma in termini di conseguenze: cosa rischio se non sistemo questa cosa, e quanto mi costa sistemarla. Questa traduzione, dal tecnico al decisionale, è ciò che trasforma un penetration test da esercizio fine a sé stesso in una guida per migliorare davvero la sicurezza.

Un buon report contiene anche un elemento che molti trascurano: il percorso di sfruttamento documentato, cioè la spiegazione passo per passo di come si è arrivati a compromettere il sistema. Questo non serve solo a dimostrare il finding, serve a far capire al team di sviluppo il ragionamento dell'attaccante, così che impari a riconoscere quel tipo di errore in futuro e non si limiti a tappare il singolo buco. Un report che insegna vale più di uno che elenca, perché trasferisce competenza invece che solo informazione. E include una fase spesso saltata, la verifica della remediation: dopo che l'azienda ha applicato le correzioni, si ricontrolla che i problemi siano davvero risolti e che le correzioni non ne abbiano introdotti di nuovi, perché una correzione affrettata può aprire una falla diversa da quella che chiudeva. Senza questa chiusura del cerchio, non si sa se il lavoro ha davvero migliorato la sicurezza o solo spostato il problema.

Il filo che lega tutto è che un penetration test fatto bene è un investimento nella conoscenza del proprio rischio reale, non un bollino da appendere. Non serve a dire "siamo sicuri", serve a sapere esattamente dove non lo sei, prima che lo scopra qualcuno con intenzioni peggiori, e a sapere in che ordine intervenire. La prospettiva offensiva, quella di chi pensa come un attaccante, applicata alla difesa, è ciò che porta alla luce i problemi che restano invisibili a chi guarda il sistema solo dal lato di chi lo ha costruito. Non puoi difendere bene ciò che non hai mai provato ad attaccare, ed è esattamente per questo che il penetration test esiste. Se vuoi sapere dove la tua applicazione è davvero vulnerabile, con una lista corta di problemi dimostrati e prioritizzati invece di un report automatico da decifrare, contattami per una consulenza diretta: partiamo da cosa protegge davvero valore nella tua applicazione, e proviamo a romperlo prima che lo faccia qualcun altro.