Quali sono le vulnerabilità software più sfruttate? I casi pratici che nessuno ti spiega a fondo

Quando parliamo di vulnerabilità software, spesso si pensa a qualcosa di remoto, quasi esoterico. In realtà, le falle più sfruttate sono spesso frutto di abitudini comuni: patch rimandate, configurazioni frettolose, componenti esterni sottovalutati. Ho iniziato a occuparmi di informatica gestendo documenti in uno studio legale: lì ho capito che l’efficienza nasce dal mettere ordine. In sicurezza vale lo stesso, solo che l’“ordine” qui ti evita notti insonni.

Perché alcune falle si sfruttano più di altre

Gli attaccanti non cercano la sfida tecnica, cercano risultati rapidi. Le vulnerabilità più sfruttate sono quelle che offrono tre ingredienti: ampia diffusione, sfruttamento automatizzabile, patch non applicate. Se una libreria è ovunque, bastano pochi script per colpire in massa.

Un altro fattore è l’effetto domino. Nelle aziende si accumulano micro-servizi, plugin, estensioni, vecchie versioni “che tanto funzionano”. Come in casa, quando metti una toppa al tubo della lavatrice e poi te ne dimentichi: regge finché non regge più. Nel software, quella toppa si chiama “aggiorno domani”.

Per orientarsi, molti usano elenchi di riferimento come OWASP Top 10, che classifica i rischi più comuni per le applicazioni web, e gli identificativi CVE, che catalogano pubblicamente le falle note. Non sono oracoli, ma bussola e mappa: aiutano a capire dove guardare per primi.

RCE e vulnerabilità di supply chain: il caso tipico

Le esecuzioni di codice da remoto (RCE) sono l’equivalente digitale di dare le chiavi di casa a uno sconosciuto. Non servono superpoteri: basta una libreria molto usata con una falla grave. Negli ultimi anni, i casi più discussi hanno riguardato componenti di logging o parsing presenti in migliaia di prodotti.

Come funziona in pratica? Immagina un sistema che registra messaggi di errore. Un aggressore invia un contenuto appositamente costruito che, invece di essere solo salvato, attiva una funzionalità non prevista e apre la porta all’esecuzione di comandi. L’attaccante poi si muove lateralmente: prova a vedere cosa c’è in rete, quali permessi ha, quali dati può raggiungere. È come se, trovata una finestra socchiusa, esplorasse tutte le stanze.

Perché questa tipologia esplode? Perché colpisce una “dipendenza di filiera”. Il software moderno è un mosaico di componenti: se uno si rompe, si incrina tutto. E se il pezzo difettoso è in mezza Internet, l’effetto è a catena.

Contromosse concrete: inventario delle dipendenze (anche transitive), aggiornamenti veloci, virtual patching con WAF quando non si può aggiornare subito, e log attivi per rilevare anomalie. Un software bill of materials (SBOM) aiuta a sapere dove guardare appena esce una nuova CVE critica.

SQL Injection: dal campo di ricerca al database

L’SQL injection rimane tra i classici più sfruttati perché nasce da un fraintendimento banale: trattare l’input dell’utente come se fosse affidabile. È come se accettassi un modulo compilato a mano e lo spedissi in posta senza leggerlo: se qualcuno ci scrive “consegna anche il portafogli”, stai regalando accessi non previsti.

Nel mondo reale, l’attaccante inserisce dati malformati in form o parametri di URL per influenzare il modo in cui il database interpreta la richiesta. Se l’applicazione non separa in modo rigoroso “istruzioni” e “dati”, il database potrebbe obbedire a comandi mai immaginati dagli sviluppatori.

Perché è ancora dominante? Perché il codice applicativo cresce in fretta e i controlli vengono dopo. Inoltre, molti framework rendono facile fare query veloci, meno facile farle in modo sicuro quando si va fuori dalle scorciatoie.

Come la eviti senza diventare paranoico? Usa sempre query parametrizzate, valida l’input in entrata (tipi e lunghezze, non solo caratteri), assegna al database permessi minimi (l’utente dell’app non deve amministrare nulla) e monitora query anomale. Se serve, aggiungi un livello di controllo con un proxy che intercetti pattern sospetti.

Cross-Site Scripting: rubare sessioni con un clic

L’XSS colpisce quando un’app web mostra all’utente qualcosa che l’utente stesso (o qualcun altro) ha inserito, ma senza “imbustarlo” in modo sicuro. È come appendere i fogli degli avvisi in bacheca senza controllare che non contengano colla che rovina il vetro.

Nei casi pratici, il risultato può essere il furto della sessione: l’aggressore fa sì che il browser esegua codice non previsto, spesso per impersonarti. A volte è un commento malevolo, altre una preview generata al volo.

La difesa è una combinazione di abitudini tecniche: encoding dell’output in base al contesto (HTML, attributi, JavaScript, URL), Content Security Policy, disabilitare l’esecuzione di contenuti inattesi, sanificare l’input senza fare affidamento su blacklist generiche. E test ripetuti: l’XSS ama i dettagli dimenticati, come le finestre modali o le notifiche in tempo reale.

Configurazioni sbagliate e credenziali riutilizzate

Le falle più sfruttate, spesso, non richiedono exploit creativi. Un pannello di amministrazione esposto, una cartella di backup indicizzata da un motore di ricerca, una porta di servizio lasciata aperta “solo per questa settimana” e poi mai richiusa. Funziona come quando lasci il citofono con il codice uguale per ufficio e magazzino: comodo, ma chiunque entra ovunque.

Capitolo a parte: le credenziali. Il riuso della stessa password su più servizi rende qualunque fuga di dati un lasciapassare. A catena, si passa da un account “minore” a caselle email o console cloud, fino a controlli di produzione.

Le difese qui sono tanto noiose quanto vincenti: MFA ovunque possibile, password manager aziendale con criteri minimi, rotazione periodica delle chiavi di accesso ai servizi, regola del minimo privilegio. E separazione degli ambienti: se sviluppo, test e produzione condividono segreti, stai apparecchiando il tavolo a un ospite indesiderato.

Phishing tecnico e sfruttamento delle integrazioni

Non sempre serve un bug nel codice: a volte basta un’integrazione troppo permissiva. Pensa ai bot che si collegano a chat interne, ai connettori no-code, agli strumenti di automazione. Se una di queste tessere ha token illimitati e nessuno registra le azioni, l’attaccante cerca quella porta. Prima compromette l’account di chi gestisce l’integrazione con un phishing ben fatto, poi usa il canale “fidato” per muoversi indisturbato.

Prevenire? Policy chiare sugli scope dei token, scadenze automatiche, alert quando un’integrazione crea o scarica volumi anomali, revisione trimestrale delle autorizzazioni, e formazione mirata: il phishing non si batte con un corso una tantum, ma con simulazioni periodiche e feedback immediato.

Come difendersi davvero: checklist operativa

Ogni organizzazione è diversa, ma il copione delle difese efficaci è sorprendentemente stabile. E no, non serve rifare tutto da zero: come per l’archivio di uno studio legale, inizi mettendo etichette chiare e chiudendo gli armadi giusti.

• Mappa ciò che hai: asset inventory e SBOM per sapere quali versioni e librerie usi.
• Dai priorità: lega le vulnerabilità alla superficie esposta e al business, non solo al punteggio.
• Automatizza le patch critiche: finestre brevi per rischio alto; fallback con virtual patching.
• Proteggi gli account: MFA, password manager, rotazione chiavi, privilegi minimi e segmentazione.
• Riduci l’attacco web: WAF, rate limiting, hardening dei server, CSP ed header di sicurezza.
• Test continui: SAST/DAST, dependency scanning, e pentest mirati su flussi ad alto impatto.
• Log e rilevamento: centralizza i log, allerta su comportamenti anomali, EDR sugli endpoint critici.
• Back-up verificati: copie offline/immutabili, restore testato periodicamente.
• Processi chiari: playbook di risposta, canali interni per segnalare incidenti, esercitazioni.
• Coinvolgi le persone: formazione breve e ricorrente, con esempi del vostro lavoro quotidiano.

Cosa guardare domani mattina

Se hai dieci minuti oggi, non cercare la falla perfetta: verifica le basi. Controlla se ci sono patch critiche in sospeso per componenti esposti, rimuovi integrazioni inutilizzate, limita i token troppo ampi, e rivedi i permessi degli account di servizio. È come svuotare la cassetta della posta prima di partire: eviti che si accumuli materiale invitante.

Le vulnerabilità più sfruttate prosperano dove il software cresce più in fretta dei controlli. Ma la buona notizia è che l’efficienza, in sicurezza, paga doppio: meno incidenti e meno tempo speso a rincorrere emergenze. Puoi partire da qui, con un inventario onesto e piccole correzioni quotidiane. Il resto, una volta che prendi il ritmo, diventa manutenzione ordinaria.