Scansionare un host che non controlli è, in molte giurisdizioni, accesso abusivo a sistema informatico. È il vincolo che disegna qualunque scanner self-service: prima di spedire un solo pacchetto verso un bersaglio scritto dall’utente, la piattaforma deve avere una prova ragionevole che quel bersaglio appartenga a chi ha avviato la scansione. Scansionare è il mestiere facile, gli strumenti ci sono da decenni; la parte difficile è che il bersaglio arriva da un form, ed è un dato di cui non ti puoi fidare.

Contesto

La direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024 (in vigore dal 16 ottobre 2024), allarga gli obblighi di gestione del rischio cyber a un perimetro stimato in 15.000–18.000 organizzazioni, contro le circa 500 della NIS precedente (D.Lgs. 65/2018). Tra le misure tecniche chieste alle entità essenziali e importanti c’è l’analisi del rischio sui sistemi informativi e di rete, con notifica degli incidenti significativi al CSIRT Italia secondo la regola 24/72/30. Per una fetta consistente di queste organizzazioni — manifattura, sanità, alimentare, servizi digitali — la conseguenza concreta è dover fare valutazioni di vulnerabilità periodiche senza un team di sicurezza interno.

Da qui la spinta verso piattaforme cloud che eseguono la scansione in self-service: l’utente scrive un dominio o un blocco di indirizzi e ottiene un report. Quando l’iniziativa passa dall’operatore esperto all’utente finale, passa anche il rischio di abuso, e con esso l’onere di provare il controllo legittimo del bersaglio.

Il problema

In un servizio di sicurezza interno il perimetro si conosce in anticipo: l’ingegnere scansiona gli asset dell’azienda che lo paga. In un servizio cloud aperto alla registrazione, l’input arriva da qualcuno che, rispetto al bersaglio, non è autenticato. A livello di rete nulla impedisce a un utente di scrivere example.com quando example.com non è suo. Se la piattaforma esegue la scansione, ha appena generato traffico di ricognizione attiva — e magari di intrusione — verso un’infrastruttura di terzi, per conto di chi non aveva titolo per ordinarlo.

Le metodologie di testing non sciolgono il nodo. La OWASP Web Security Testing Guide v4.2 e l’Application Security Verification Standard dicono come si testa, non chi può far testare un certo bersaglio. L’autorizzazione è un presupposto del lavoro, dato per scontato nelle regole d’ingaggio di un pentest classico. In una piattaforma self-service quel presupposto va costruito a runtime, prima della scansione, in modo automatico e verificabile.

Architettura della validazione

Il meccanismo collaudato è la prova di controllo del dominio: lo stesso schema con cui le autorità di certificazione emettono i certificati e i provider SaaS legano un account a un dominio. L’IETF lo ha messo nero su bianco nel draft draft-ietf-dnsop-domain-verification-techniques (ottobre 2023), che raccoglie le pratiche già diffuse e ne corregge i punti deboli.

Applicato a uno scanner, il flusso è questo:

  1. L’utente dichiara il bersaglio (target.example.com).
  2. La piattaforma genera un token con almeno 128 bit di entropia e lo lega all’account e al dominio richiesto.
  3. L’utente pubblica il token in un record TXT su un’etichetta con prefisso underscore dedicata al provider — _<provider>-challenge.target.example.com — oppure in un file su un percorso noto del web server.
  4. La piattaforma interroga il DNS (o l’HTTP) e procede solo se il token corrisponde.

Per uno scanner il draft IETF aggiunge due dettagli da non trascurare. Il primo è lo scoping dell’etichetta: -host-challenge valida un singolo hostname, -domain-challenge l’intero dominio con i suoi sottodomini. Uno scanner dovrebbe rifiutarsi di estendersi da solo da un host validato all’apex senza una validazione di dominio esplicita, così il consenso su un host non diventa consenso sull’intera zona. Il secondo è la codifica del token: per le etichette DNS si raccomandano base32 o base16, insensibili alle maiuscole e prive di caratteri problematici, mentre base64url subisce normalizzazioni che possono far fallire il confronto.

La validazione via email — il link di conferma sull’indirizzo dell’utente — è un livello a parte, e da solo non basta: dimostra che chi si registra controlla una casella, non che controlli il bersaglio. Le due verifiche rispondono a domande diverse e vanno tenute separate.

Punto critico

La validazione del dominio è un controllo nel tempo, non un’autorizzazione che dura per sempre. Un token TXT pubblicato oggi domani può sparire; un dominio può cambiare proprietario; un sottodominio può finire a un altro tenant (il noto subdomain takeover). Una piattaforma che valida una volta e poi tratta il bersaglio come autorizzato a oltranza accumula autorizzazioni scadute. La conseguenza concreta è che la prova di controllo va riverificata prima di ogni scansione, oppure tenuta valida per una finestra breve ed esplicita — il draft IETF prevede proprio un campo di scadenza in formato ISO 8601 nei metadati del record.

C’è anche un fallimento silenzioso da evitare. Se la query DNS di verifica va in timeout o si perde su un resolver intermedio, la piattaforma deve leggere l’esito come non autorizzato, mai come autorizzato per prudenza. Un fail-open su un controllo di autorizzazione che precede traffico offensivo è un difetto di sicurezza, non un addolcimento dell’esperienza utente.

Implicazioni

Il triage dei risultati è un altro problema. La domanda non è tanto se una vulnerabilità ci sia, ma quanto è probabile che venga sfruttata. Il CVSS v4.0 (FIRST, novembre 2023) dà un punteggio di gravità intrinseca, ma non dice quanto un difetto sia davvero attaccato in natura; l’EPSS, sempre di FIRST, stima la probabilità di sfruttamento entro 30 giorni. Incrociare le due dimensioni separa il rumore (gravità alta, sfruttamento improbabile) dall’urgenza vera (sfruttamento probabile su un asset esposto). È una prioritizzazione costruita su dati pubblici e versionabili, non su un punteggio opaco.

Sul fronte dei dati, una scansione di per sé produce un inventario di asset, porte aperte, versioni di software e vulnerabilità: in pratica una mappa per l’attaccante. Dove risiedono questi dati e come sono segregati per tenant sono proprietà di sicurezza del servizio, prima ancora che voci di compliance: un archivio di report compromesso è un regalo a chiunque voglia colpire i clienti della piattaforma.

Limiti

La prova di controllo del dominio copre il bersaglio raggiungibile via DNS o HTTP; sui blocchi di indirizzi IP nudi non funziona altrettanto bene, perché manca un’etichetta su cui pubblicare un token e la prova di titolarità passa per i registri RIR o per accordi fuori banda. E la validazione tecnica non esaurisce la responsabilità legale: dimostra il controllo di un dominio, non che l’utente abbia il diritto contrattuale di testare ogni sistema dietro quel dominio (basti pensare all’hosting condiviso). Resta un livello di consenso che nessun record TXT può sostituire.

Una piattaforma che porta questi vincoli in un servizio self-service per le PMI italiane sotto NIS2 è CyberScan, descritta nell’insight pubblicato da noze: https://www.noze.it/insights/cyberscan-lancio/.

https://www.first.org/cvss/specification-document https://www.first.org/epss/data_stats https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-03 https://owasp.org/www-project-web-security-testing-guide/v42/ https://owasp.org/www-project-application-security-verification-standard/ https://www.gazzettaufficiale.it/eli/id/2024/10/01/24G00155/sg

Immagine di copertina: Diagramma di una risoluzione DNS iterativa: un resolver interroga in sequenza root nameserver, nameserver .org e nameserver… — diagramma di Lion Kimbro, pubblico dominio — https://commons.wikimedia.org/wiki/File:Example_of_an_iterative_DNS_resolver.svg