Vulnerabilità vs exploit: la distinzione che l’esame ama

Prima di parlare di OWASP, fissa il concetto che vale metà delle domande scenario: una vulnerabilità è una debolezza latente (codice non validato, credenziale hardcoded, cifratura assente), mentre un exploit è la tecnica che sfrutta quella debolezza e un attacco è l’atto in corso. Un NGIPS come Cisco Firepower/Secure IPS non “vede” la vulnerabilità nel codice: intercetta l’exploit in transito sulla rete tramite le firme Snort. Questa asimmetria è il cuore della unità.

Le vulnerabilità OWASP più citate

L’esame ricorre a un nucleo ristretto di categorie applicative. La differenza chiave è che sono debolezze di input/logica, quindi generano traffico anomalo osservabile.

Vulnerabilità Natura della debolezza Come appare in rete
SQL injection input non parametrizzato che raggiunge il DB payload HTTP con ' OR 1=1--, UNION SELECT
Cross-Site Scripting (XSS) output non codificato reso nel browser tag <script>, event handler nei parametri
Buffer overflow mancato controllo dei confini di memoria shellcode, NOP sled, stringhe sovradimensionate
CSRF assenza di token anti-forgery / SameSite richiesta cross-origin che replica un’azione autenticata

SQLi e XSS sono debolezze di injection: il difetto è nell’applicazione, ma l’exploit viaggia in chiaro (o dopo decrittazione TLS) come pattern nel payload HTTP, quindi è firmabile. Il buffer overflow è memory-safety: la firma cerca la sequenza binaria dell’exploit, non la logica. CSRF è più insidioso perché il singolo pacchetto è “legittimo”: la debolezza è l’assenza di un controllo, e l’IPS ha visibilità limitata sul contesto di sessione.

Le debolezze “non-injection”

Accanto a queste, OWASP elenca categorie che non si manifestano come payload malevolo:

  • Password deboli o hardcoded e broken authentication: la debolezza abilita credential stuffing e brute force. Qui l’IPS non riconosce una stringa d’attacco ma un pattern comportamentale (rate di login falliti, sorgenti note-malevole).
  • Cifratura mancante o debole (sensitive data exposure): dati sensibili in chiaro. Non è un exploit da bloccare, è una cattiva pratica: l’IPS può segnalare protocolli in clear-text, ma la remediation è architetturale (TLS, at-rest encryption).
  • Broken access control: logica autorizzativa fallace, difficilmente firmabile.

Il messaggio d’esame: non tutte le vulnerabilità sono intercettabili con una firma. Le injection sì; le debolezze di configurazione/credenziali richiedono hardening, MFA e policy, non solo IPS.

Come Snort intercetta l’exploit nel NGIPS

Una regola Snort ha struttura action proto src → dst (opzioni). Contro l’exploit di SQLi la firma cerca il contenuto nel flusso:

alert tcp any any -> $HTTP_SERVERS 80 (msg:"SQL Injection UNION SELECT";
 flow:to_server,established; content:"UNION"; nocase;
 content:"SELECT"; nocase; sid:1000001;)

Concetti chiave da ricordare:

  • flow:to_server,established limita l’ispezione al traffico rilevante e riduce i falsi positivi.
  • I preprocessori (HTTP Inspect, normalizzazione) de-offuscano encoding e frammentazione prima del match: è così che l’IPS resiste all’evasione (URL-encoding, case mixing).
  • La firma matcha l’exploit, non la vulnerabilità: se l’app fosse patchata ma l’attacco arrivasse comunque, l’IPS lo bloccherebbe lo stesso.
  • La visibility dipende dalla decrittazione: su HTTPS senza TLS decryption policy, il payload è cifrato e Snort non vede il pattern.

L’IPS opera inline (blocca/droppa), l’IDS solo in monitor/tap (allerta). In modalità inline puoi usare azioni drop e reset; in tap, solo alert.

Trappole tipiche d’esame

  • Scenario: “Il sito ha un campo di login vulnerabile a SQLi ma nessuno lo ha ancora sfruttato.” → È una vulnerabilità, non un attacco. L’IPS con firma pronta agisce solo quando arriva l’exploit; il fix definitivo è codice parametrizzato/WAF.
  • Scenario: “Rilevi credenziali hardcoded in un’app.” → Debolezza non intercettabile da una firma Snort. Risposta giusta: hardening/secret management/MFA, non una regola IPS.
  • Scenario: “Il traffico è HTTPS e l’IPS non allerta sull’SQLi.” → Manca la TLS decryption: senza decrittazione Snort non ispeziona il payload; non è un difetto della firma.
  • Scenario: “Vuoi bloccare (non solo rilevare) l’exploit.” → Serve deployment inline con azione drop; un IDS in modalità tap può solo allertare.
  • Scenario: “Distinguere CSRF da XSS.” → XSS inietta script eseguito nel browser della vittima (firmabile via <script>); CSRF sfrutta una sessione autenticata con una richiesta cross-origin apparentemente legittima, molto più difficile da firmare.