Generatore Security.txt

security.txt è una best practice per la sicurezza web formalmente standardizzata dall'IETF (Internet Engineering Task Force) in RFC 9116, progettata per fornire ai siti web un modo unificato e standard di pubblicare le informazioni di contatto per la sicurezza. In parole semplici, è un file di testo posizionato in un percorso fisso su un sito web, che dice ai ricercatori di sicurezza (hacker white hat): "Se trovate vulnerabilità di sicurezza sul mio sito web, ecco come contattarci, ecco la nostra chiave pubblica di crittografia, ecco la nostra politica di divulgazione, accogliamo con favore le vostre segnalazioni."

Prima che esistesse lo standard security.txt, le informazioni di contatto per la sicurezza dei siti web erano disordinate. Alcuni siti web non avevano alcuna informazione di contatto per la sicurezza, alcuni l'avevano sepolta in qualche pagina oscura, alcuni elencavano solo un'email info@ non presidiata e alcuni richiedevano ricerche faticose su LinkedIn per trovare il team di sicurezza. Ciò ha causato un problema serio: quando i ricercatori di sicurezza in buona fede scoprivano vulnerabilità, spesso non riuscivano a trovare il canale corretto per segnalarle. Il risultato è stato che molte vulnerabilità sono state silenziosamente accantonate, lasciate non corrette, finché non sono state scoperte e sfruttate da hacker dannosi. security.txt è nato per risolvere questo problema dell'"ultimo miglio".

Il concetto di security.txt è stato proposto per la prima volta dai ricercatori di sicurezza EdOverflow e Yakov Shafranovich nel 2017 e ha rapidamente ottenuto un ampio supporto industriale. Nell'aprile 2022, security.txt è stato formalmente approvato dall'IETF come RFC 9116, diventando uno standard di sicurezza web riconosciuto a livello internazionale. Oggi, grandi aziende tecnologiche come Google, GitHub, Meta (Facebook), LinkedIn e Cloudflare, nonché agenzie governative tra cui il Governo del Regno Unito, la CISA statunitense (Agenzia per la Sicurezza Informatica e delle Infrastrutture), il Governo francese, il Governo italiano, il Governo olandese e il Centro di Sicurezza Informatica australiano, hanno deployato security.txt sui loro siti web ufficiali e raccomandano pubblicamente ad altre organizzazioni di adottarlo.

Il design principale del file security.txt è molto semplice: è un file di testo semplice composto da righe nel formato "nome-campo: valore", simile al formato delle intestazioni HTTP. Lo standard definisce due campi obbligatori: Contact (informazioni di contatto per la sicurezza, che possono essere multiple) ed Expires (ora di scadenza del file); oltre a diversi campi opzionali: Encryption (URL chiave pubblica di crittografia PGP), Acknowledgments (URL pagina di ringraziamenti), Policy (URL politica di divulgazione vulnerabilità), Hiring (URL lavori sicurezza), Canonical (URL canonica del file), Preferred-Languages (lingue di report supportate), CSAF (URL metadati provider Common Security Advisory Framework). Questo formato semplice rende facile l'analisi sia per gli esseri umani che per le macchine.

Perché deployare security.txt è così importante? Prima di tutto, abbassa la barriera per la segnalazione delle vulnerabilità. I ricercatori di sicurezza non hanno bisogno di spendere tempo significativo a trovare le informazioni di contatto: possono trovare il canale di segnalazione corretto con un clic. In secondo luogo, dimostra l'atteggiamento proattivo di un'organizzazione nei confronti della sicurezza: un sito web con security.txt essenzialmente sta dicendo "Prendiamo sul serio la sicurezza e accogliamo con favore le segnalazioni responsabili". In terzo luogo, riduce il rischio che le vulnerabilità vengano divulgate pubblicamente o sfruttate: con un canale formale, i ricercatori non sceglieranno di divulgare pubblicamente le vulnerabilità direttamente su Twitter o GitHub perché non riescono a raggiungere nessuno. In quarto luogo, in molti requisiti normativi del settore (finanza, sanità, governo), stabilire un canale di divulgazione delle vulnerabilità è diventato un requisito di conformità.

Ci sono diversi dettagli chiave da notare quando si deploya security.txt. Primo, il percorso deve essere corretto: il percorso standard è /.well-known/security.txt e puoi anche posizionare una copia in /security.txt nella directory root come fallback. La directory .well-known qui è una directory standard di "risorse note" definita da RFC 8615, dove anche altri file standard come robots.txt sono posizionati in posizioni correlate. Secondo, deve essere servito su HTTPS: l'HTTP in chiaro è considerato non sicuro. Terzo, il Content-Type deve essere text/plain, non text/html o altri tipi. Quarto, non eseguire reindirizzamenti cross-domain per security.txt: se https://example.com/.well-known/security.txt reindirizza a https://other-domain.com/security.txt, i ricercatori e gli strumenti automatizzati lo considereranno sospetto. Quinto, ricorda di impostare il campo Expires e di aggiornarlo regolarmente; un security.txt scaduto sarà considerato con informazioni inaffidabili.

Il campo Contact è il campo più importante in security.txt e l'unico veramente essenziale (Expires è anche obbligatorio ma è solo un timestamp). Contact supporta tre formati URI: mailto: per gli indirizzi email, https: per i collegamenti web (come le pagine dei moduli di segnalazione sicurezza), tel: per i numeri di telefono. È fortemente consigliato fornire almeno un'email mailto e un collegamento a un modulo https: i moduli prevengono lo spam dai bot, mentre l'email è più conveniente per i ricercatori per inviare direttamente report crittografati. Contatti multipli possono essere elencati su più righe, ad esempio fornendo contemporaneamente sia l'email del team di sicurezza, l'email del responsabile della sicurezza e i collegamenti a piattaforme di vulnerabilità di terze parti.

Sebbene il campo Encryption sia opzionale, è molto importante nella pratica. Quando i ricercatori di sicurezza scoprono una vulnerabilità critica (come la fuga di dati utente o l'esecuzione di codice remoto), non vogliono assolutamente inviare i dettagli della vulnerabilità in email in chiaro: perché l'email passa attraverso più server durante la trasmissione, ogni hop potrebbe essere intercettato. La crittografia a chiave pubblica PGP (Pretty Good Privacy) è lo standard industriale per la comunicazione sicura. Devi solo generare una coppia di chiavi PGP, posizionare la chiave pubblica sul tuo sito web (ad es. in /.well-known/pgp-key.txt) e inserire quell'URL nel campo Encryption. I ricercatori crittografano il contenuto del report con la tua chiave pubblica e solo coloro che detengono la chiave privata corrispondente possono decrittografarlo e leggerlo.

Il campo Policy si collega alla tua pagina di Politica di Divulgazione delle Vulnerabilità (Vulnerability Disclosure Policy, VDP), che è la chiave per costruire la fiducia dei ricercatori. Una buona VDP dovrebbe indicare chiaramente: ambito di test (quali sistemi sono nell'ambito di test e quali no), metodi di test consentiti (ad es. test SQL injection/XSS consentiti ma DDoS/ingegneria sociale/accesso a dati utente reali proibiti), tempi di risposta impegnati (ad es. "Confermeremo la ricezione dei report entro 3 giorni lavorativi"), se offri ricompense e gli impegni di safe harbor legali (indicando esplicitamente di non perseguire ricercatori in buona fede che seguono le regole). Ci sono molti modelli VDP disponibili a livello internazionale come riferimento e anche la CISA statunitense fornisce un modello VDP open source.

Oltre al contatto di sicurezza in sé, security.txt ha diversi campi a "sorpresa". Il campo Acknowledgments costruisce una Security Hall of Fame: ringraziare pubblicamente i ricercatori che ti aiutano a trovare vulnerabilità, riconoscendo il loro lavoro e servendo anche come costruzione di comunità. Il campo Hiring è un design molto intelligente: le persone che possono trovare vulnerabilità sul tuo sito web sono intrinsecamente eccellenti talenti della sicurezza e inserire un collegamento di reclutamento in security.txt è il canale più preciso per reclutare talenti nel campo della sicurezza. Molte aziende hanno assunto eccellenti ingegneri della sicurezza tramite security.txt. Il campo Canonical è una considerazione di sicurezza: impedisce agli aggressori di falsificare il tuo security.txt su altri domini.

Per quanto riguarda la comune preoccupazione per lo spam, in pratica la maggior parte delle organizzazioni che hanno deployato security.txt segnala aumenti trascurabili dello spam. Questo perché: primo, gli spammer in genere non ottengono indirizzi email crawlando security.txt; secondo, i collegamenti a moduli https:// possono essere utilizzati invece di inserire direttamente email mailto e aggiungere CAPTCHA ai moduli può bloccare completamente i bot; terzo, le email dedicate alla sicurezza (ad es. security@) di solito hanno un filtraggio antispam rigoroso configurato. Al contrario, il costo di perdere report critici di vulnerabilità a causa della mancanza di un canale di contatto per la sicurezza supera di gran lunga il potenziale aumento di piccole quantità di spam.

Questo generatore è costruito in stretta conformità con lo standard RFC 9116 e tutti i formati di output sono normalizzati: il campo Contact riconosce automaticamente i prefissi, il campo Expires utilizza il formato orario UTC standard ISO 8601 e Preferred-Languages viene impostato automaticamente in base alla lingua che stai utilizzando. Il contenuto generato può essere direttamente copiato e deployato nel percorso /.well-known/security.txt senza alcuna modifica. Inoltre, tutta la configurazione viene eseguita localmente nel tuo browser e non viene mai inviata a nessun server: le tue informazioni di contatto per la sicurezza rimangono sempre sul tuo dispositivo. Deployare security.txt richiede solo 5 minuti, ma il canale di comunicazione di sicurezza che stabilisce potrebbe aiutarti a evitare un grave incidente di sicurezza in futuro.