La nostra metodologia di penetration testing per applicazioni web

Il bug migliore che ho trovato lo scorso trimestre non era nel report dello scanner. È emerso nell’ora morta dopo la fine della scansione, al quarto passaggio su un flusso di checkout, quando ho notato che l’order_id in una richiesta di conferma era un semplice intero incrementale. Sottrai uno. Invia di nuovo. È tornato indietro l’indirizzo di spedizione di un’altra persona. Quella distanza – tra ciò che uno strumento segnala e ciò che un attaccante ci fa davvero – è tutta la ragione per cui la nostra metodologia di penetration testing per applicazioni web è costruita così.

Quello che segue è il processo che seguiamo negli assessment reali, non una slide da presentazione commerciale. L’ordine si adatta all’applicazione. La struttura regge. Ogni fase alimenta la successiva.

Punti chiave

• Una vera metodologia di penetration testing per applicazioni web è guidata dal lavoro manuale. Gli scanner si occupano di copertura e rumore; sono le persone a trovare i difetti di access control e di business logic che gli strumenti, per come sono fatti, non possono vedere.
• Lavoriamo per fasi: definizione dello scope e recon, mappatura, autenticazione e sessione, access control, injection, business logic, poi reporting e un retest per confermare che le correzioni siano davvero andate a segno.
• I finding a maggiore impatto di solito sono broken access control (IDOR) e abusi di logica, non esotiche corruzioni di memoria. Ricadono nell’OWASP Top 10 A01 e restano le criticità più comuni che documentiamo.
• Un finding senza un proof of concept riproducibile e una correzione specifica è mezzo finding. Il report è il prodotto.
• Il retest conta quanto il test. Un ticket segnato come “risolto” che nessuno ha ricontrollato è un modo tipico in cui una vulnerabilità attiva finisce in produzione.

Cos’è davvero il penetration testing per applicazioni web

Il penetration testing per applicazioni web è una simulazione di attacco autorizzata e orientata a un obiettivo contro un’applicazione specifica, condotta da una persona con gli stessi strumenti e la stessa mentalità di un attaccante reale. L’obiettivo non è un elenco di debolezze teoriche. L’obiettivo è dimostrare quali si possono sfruttare, fin dove arrivano e a cosa potrebbe davvero mettere le mani un esterno determinato o un utente autenticato malintenzionato.

Questa distinzione guida tutto il resto. Una scansione chiede: esiste questo pattern? Un pentest chiede: posso trasformarlo in accesso a dati o denaro? La seconda domanda è più difficile. Non si automatizza bene. Ed è esattamente lì che sta il valore.

Fase 1: scope, rules of engagement e recon

Prima che parta una singola richiesta, fissiamo lo scope per iscritto. Quali hostname e sottodomini sono in gioco. Quale ambiente – insistiamo molto per un mirror di staging al posto dei record reali dei clienti. Quali ruoli ci vengono assegnati, se testiamo come esterno non autenticato, come utente a bassi privilegi o entrambi, e quali endpoint sono fuori dai limiti. Le rules of engagement non sono burocrazia. Ottenere account di test a due diversi livelli di privilegio è spesso l’unico fattore che decide se riusciamo o meno a dimostrare un bug di access control.

Il recon poi mappa la superficie di attacco. Enumeriamo i sottodomini, scarichiamo i bundle JavaScript e li analizziamo alla ricerca di route API nascoste e chiavi hardcoded, leggiamo qualsiasi definizione Swagger o OpenAPI e facciamo il fingerprint dello stack. Una moderna single-page app espone volentieri l’intero contratto del backend in un file JS con source map. Leggere con attenzione quel file batte ogni volta il tirare a indovinare.

Fase 2: mappatura dell’applicazione

Ora guidiamo l’applicazione a mano, con Burp Suite che intercetta tutto. Ogni ruolo, ogni workflow, ogni cambio di stato. Registrazione, login, reset di una password, upload di un file, un acquisto, invito di un collega, cambio di ruolo, cancellazione di un oggetto. La cronologia del proxy raccolta in una navigazione accurata diventa la mappa da cui attacchiamo.

Per i percorsi a cui la UI non punta mai, usiamo ffuf e il crawler di Burp per la scoperta di contenuti e parametri. Vecchi pannelli di amministrazione. Route di debug. Un dimenticato /api/v1 che non ha mai ricevuto i controlli di autorizzazione che qualcuno ha innestato su v2. Quest’ultimo caso salta fuori di continuo.

ffuf -w wordlist.txt -u https://app.example.com/api/FUZZ \
  -H "Authorization: Bearer <low-priv-token>" \
  -mc 200,201,401,403 -o results.json

Fase 3: autenticazione e gestione della sessione

L’autenticazione ha un suo filone di lavoro dedicato, perché sbagliarla è catastrofico e sbagliarla in modo sottile è ovunque. Testiamo i flussi di reset della password per prevedibilità dei token e host-header poisoning. Verifichiamo se le sessioni muoiono davvero al logout e al cambio password, o fanno solo finta. Guardiamo con attenzione la gestione dei JWT: algorithm confusion, verifica della firma mancante, alg: none, token che non scadono mai. E sondiamo i flussi multi-factor alla ricerca del classico buco in cui il secondo fattore è imposto nella UI ma non nella chiamata API sottostante.

Una cosa che vediamo in un numero deprimente di applicazioni: rate limiting sul form di login, nessuno sull’endpoint JSON dietro di esso. Se il front end limita e l’API alza le spalle, il credential stuffing entra tranquillamente.

Fase 4: access control – dove vivono le criticità

Il broken access control è l’OWASP Top 10 A01 ed è la categoria che produce la maggior parte dei nostri finding critici. Il classico è l’IDOR (insecure direct object reference, CWE-639): un identificatore di oggetto in una richiesta di cui il server si fida senza mai verificare se l’utente corrente possiede quell’oggetto.

Ecco perché due account di test contano. Catturiamo una richiesta come utente A, la rigiochiamo come utente B scambiando solo l’ID dell’oggetto o il token di sessione, e osserviamo se l’utente B se ne va con i dati dell’utente A.

GET /api/v2/invoices/48213 HTTP/1.1
Host: app.example.com
Authorization: Bearer <user-B-token>

# Invoice 48213 belongs to user A.
# A 200 with A's data means IDOR.

Testiamo anche l’escalation verticale (un utente standard può raggiungere una funzione riservata agli amministratori chiamando l’endpoint direttamente?), il mass assignment (aggiungere "role":"admin" al body di aggiornamento del profilo attecchisce davvero?) e il forced browsing verso funzioni che il menu nasconde ma che il server continua comunque a servire. Gli scanner si perdono quasi tutto questo. Non hanno alcun concetto di chi dovrebbe possedere cosa. Quel contesto vive nella testa di chi testa.

Fase 5: injection e difetti server-side

L’injection è ben compresa e non è affatto sparita. Si è spostata. Continuiamo a cercare la SQL injection con payload manuali e automatici, ma le ore ora vanno nelle varianti che i framework non hanno risolto al posto tuo: server-side template injection, SSRF in cui un parametro URL fa recuperare al server risorse interne (una linea diretta verso gli endpoint di metadata cloud), elaborazione di XML external entity su qualunque cosa ingerisca ancora XML e command injection nascosta nelle funzioni di elaborazione o esportazione dei file.

Il cross-site scripting è ancora ovunque, soprattutto l’XSS DOM-based nelle SPA in cui un valore passa dall’URL a innerHTML o a un sink del framework senza alcuna sanitizzazione. Confermiamo ogni candidato a mano. Un valore riflesso in una risposta non prova nulla. L’esecuzione in un browser lo prova.

Fase 6: business logic – la parte che gli strumenti non sanno fare

Il test della business logic è il punto in cui l’esperienza separa un assessment vero da un PDF sputato da uno scanner. Non esiste una signature per “il coupon si applica due volte”, o “puoi saltare il passaggio di pagamento e finire comunque sul piano a pagamento”, o “il campo quantità accetta un numero negativo e accredita il tuo conto”. Diventano finding solo quando una persona capisce cosa l’applicazione dovrebbe fare, poi rompe deliberatamente l’assunzione che ci sta sotto.

Negli assessment troviamo regolarmente race condition nei flussi di riscatto e prelievo – lancia la stessa richiesta venti volte in parallelo e guarda se un’azione una tantum scatta due volte. Passi di workflow che si possono riordinare o saltare. Limiti imposti solo sul client. Questa categoria compare di rado negli output automatici, ed è spesso lì che sta il danno reale più grande.

Fase 7: reporting e retest

Il report è il deliverable, quindi lo scriviamo per due lettori insieme. I dirigenti ricevono un riassunto ordinato per rischio in termini di business. Gli ingegneri ricevono una descrizione per ogni finding: severità (assegniamo un punteggio con CVSS ma la calibriamo sempre rispetto alla reale sfruttabilità nel tuo contesto), riproduzione passo passo, la richiesta o il payload esatti e una correzione concreta. Non “sanifica l’input”. Quale controllo aggiungere, e dove.

Poi facciamo il retest. Una volta che il tuo team rilascia le correzioni, rieseguiamo esattamente gli attacchi che funzionavano e confermiamo che siano morti, e verifichiamo di non aver aperto un buco lì accanto. Non puoi cavartela a parole da un finding; il payload o scatta o non scatta. Una remediation che nessuno ha verificato è il modo in cui una vulnerabilità “chiusa” arriva silenziosamente in produzione.

Come ti aiuta CyberXplore

Questa metodologia è esattamente ciò che eseguiamo con il nostro servizio di penetration testing per applicazioni web: tester senior, lavoro guidato a mano, un report su cui i tuoi ingegneri possono agire e un retest incluso, così paghi per correzioni che tengono, non per un PDF che prende polvere. Vuoi aiuto sullo scoping o una risposta chiara su impegno e tempistiche per la tua applicazione? Richiedi un preventivo e percorreremo insieme la tua superficie prima che tu ti impegni in qualcosa.

FAQ

Quanto dura un penetration test di un’applicazione web?

Per una tipica applicazione di medie dimensioni, metti in conto circa una o due settimane di test attivo più qualche giorno per il reporting. La durata scala con il numero di ruoli, endpoint e workflow nello scope. Le applicazioni con business logic pesante o molti livelli di privilegio richiedono più tempo, perché sono le parti che non puoi affrettare. Definire lo scope dell’applicazione in anticipo è ciò che mantiene onesta la stima.

Qual è la differenza tra una scansione e un penetration test?

Una scansione delle vulnerabilità è pattern matching automatizzato che segnala signature note e genera parecchi falsi positivi. Un penetration test è una persona che attacca l’applicazione per dimostrare un impatto reale e sfruttabile, inclusi i difetti di access control e business logic che gli scanner non riescono a rilevare. Usiamo gli scanner dentro un pentest per la copertura. Sono l’inizio del lavoro, non tutto il lavoro.

Vi serve accesso alla produzione o un ambiente di staging?

Preferiamo un ambiente di staging o pre-produzione che rispecchi il comportamento della produzione, idealmente popolato con dati di test invece che con record reali dei clienti. Questo ci permette di testare in modo aggressivo senza mettere a rischio i dati reali o l’uptime. Se è disponibile solo la produzione, adattiamo le rules of engagement per testare in sicurezza ed evitare azioni distruttive.

Perché chiedete più account utente e ruoli?

Perché la maggior parte dei finding critici sono fallimenti di access control, e non se ne può dimostrare uno senza due prospettive. Testare come utente A e utente B conferma se il server verifica davvero la proprietà. Testare un account a bassi privilegi contro le funzioni di amministrazione espone l’escalation verticale. Senza quegli account possiamo sospettare questi bug ma non dimostrarli.

Il retest è incluso?

Sì. Dopo che il tuo team ha applicato le correzioni, rieseguiamo gli attacchi andati a segno, confermiamo che le correzioni tengano e aggiorniamo lo stato nel report. Un finding non è davvero chiuso finché qualcuno non ha verificato che la correzione funzioni, e quella verifica fa parte dell’ingaggio invece di essere un extra.

Questa metodologia copre le API e le single-page app?

Sì. Una moderna applicazione web di solito è una SPA che dialoga con un’API JSON o GraphQL, quindi è nell’API che va gran parte del nostro tempo. Analizziamo i bundle di front-end per mappare il contratto del backend, poi testiamo direttamente gli endpoint API per problemi di autorizzazione, injection e logica invece di fidarci di qualunque cosa la UI decida di esporre.