1. La fiducia è fragile

Verità fondamentale: i sistemi sono costruiti dagli esseri umani e gli esseri umani commettono errori.

La sicurezza non può essere data per scontata: deve essere costantemente verificata. Meccanismi come l’autenticazione a più fattori, i firewall e la crittografia sono efficaci solo nella misura in cui il loro dettaglio di implementazione più debole o l’eccezione trascurata lo rendono inefficace.

Esempio: tentativo di bypassare l’MFA tramite flussi di lavoro con password dimenticata o endpoint OAuth non configurati correttamente.

2. Ogni input è un’arma potenziale

Verità fondamentale: se accetta input, può essere sfruttato.

Gli input degli utenti (campi dei moduli, parametri API, intestazioni HTTP, caricamento di file) sono tutti potenziali vettori. Gli aggressori testano casi limite, codifiche e payload per sfruttare il modo in cui le applicazioni interpretano i dati.

Esempio: attivazione di SSRF cieco tramite un campo URL in un generatore PDF o iniezione di XSS tramite un campo commento non purificato.

3. I confini sono costrutti umani

Verità fondamentale: i limiti della fiducia esistono nel codice, non nella natura.

La logica di autorizzazione è spesso incoerente o mal applicata. Gli aggressori cercano modi per muoversi lateralmente o aumentare i privilegi, piegando o aggirando queste linee artificiali.

Esempio: esecuzione dell’escalation orizzontale dei privilegi tramite IDOR (Insecure Direct Object References).

4. La complessità è il nemico della sicurezza

Verità fondamentale: più il sistema è complesso, maggiore è il margine di errore.

Con le architetture moderne che includono microservizi, integrazioni cloud e API di terze parti, visibilità e controllo diminuiscono. Errori di configurazione e dipendenze trascurate diventano inevitabili.

Esempio: concatenamento di un ruolo IAM non configurato correttamente con una chiave API esposta e SSRF per accedere ai servizi interni.

5. Gli aggressori pensano in termini di ROI

Verità fondamentale: la maggior parte degli attacchi sono opportunistici.

Gli exploit avanzati non sono sempre necessari. In molte violazioni, gli aggressori sfruttano debolezze a basso impatto e con un basso sforzo: sistemi configurati in modo errato, credenziali riutilizzate, risorse dimenticate.

Esempio: ottenere l’accesso amministratore tramite un sottodominio esposto utilizzando ancora le credenziali predefinite.

Applicazione dei principi fondamentali durante il ciclo di vita del pentest

• Ricognizione: la superficie d’attacco è più ampia di quanto sembri. Ogni piccolo dettaglio potrebbe portare a uno sfruttamento.
• Modellazione delle minacce: i limiti di fiducia sono presupposti. Cosa succede se vengono meno?
• Sfruttamento: gli input sono influenza. La complessità è leva.
• Escalation dei privilegi: le autorizzazioni applicate in modo inadeguato rappresentano delle opportunità.
• Persistenza: la complessità del sistema crea punti d’appoggio a lunga durata.
• Reporting: concentrati sull’impatto, non sul volume. Dai priorità alle informazioni basate sul rischio rispetto alle checklist delle vulnerabilità.

Pensiero finale: andare oltre la lista di controllo

I test basati su checklist hanno la loro importanza, ma per individuare rischi significativi, i tester devono mettere in discussione le ipotesi. Perché un’applicazione si fida di un dato input? Dove i limiti di attendibilità vengono dati per scontati ma non applicati? Quale complessità ha introdotto punti ciechi?

Spesso le vulnerabilità più critiche non risiedono nel codice, ma nella logica.

Quando i penetration tester applicano il pensiero basato sui principi fondamentali, non si limitano a identificare i punti deboli. Espongono anche i ragionamenti errati che li hanno resi possibili, aiutando in definitiva le organizzazioni a costruire sistemi più resilienti.