Logo

Whitepaper su sicurezza e privacy (panoramica)Capitolo 11

Capitolo 11: divulgazione delle vulnerabilità e aggiornamenti di sicurezza

FileBolt incoraggia la divulgazione responsabile e costruisce fiducia con meccanismi prevedibili di correzione e comunicazione. Allo stesso tempo, le funzioni di sicurezza devono poter evolvere: policy di sicurezza web, meccanismi di autenticazione lato server e implementazioni della crittografia e dei protocolli end-to-end (ad es. gli aggiornamenti di cryptoVersion). Questo capitolo descrive i canali di contatto pubblici, i flussi di gestione, i principi di rilascio e comunicazione delle correzioni, e spiega le strategie di evoluzione per versioni e di deprecazione.

11.0 Riepilogo

  • DEVE: offrire canali pubblici per la segnalazione delle vulnerabilità (ad es. security.txt ed e-mail di supporto).
  • DOVREBBE: offrire meccanismi di invio cifrati (ad es. una chiave PGP) per trasmettere i dettagli in sicurezza.
  • DOVREBBE: definire una cadenza chiara di risposta e correzione (SLA/tempi obiettivo) e comunicare tramite la pagina di stato quando necessario.
  • DEVE: trattare con la massima priorità le vulnerabilità che possono compromettere gli impegni zero-knowledge (XSS, iniezioni nella supply chain, fuga di frammenti nei log).
  • DEVE: attuare un'evoluzione per versioni (cryptoVersion) e definire strategie di compatibilità, migrazione e deprecazione.

11.1 Canali di segnalazione delle vulnerabilità e contatti

11.1.1 Punti di accesso pubblici

  • DEVE: indicare in /.well-known/security.txt i canali di segnalazione delle vulnerabilità, la scadenza e i link alle policy.
  • DEVE: mettere a disposizione un indirizzo e-mail di contatto per la sicurezza raggiungibile (ad es. support@filebolt.net o uno dedicato, security@filebolt.net).
  • DOVREBBE: fornire brevi istruzioni e linee guida per l'invio nella pagina Sicurezza e privacy.

11.1.2 Invio cifrato e gestione delle informazioni sensibili

  • DOVREBBE: mettere a disposizione una chiave pubblica PGP (o equivalente) perché i ricercatori possano inviare in sicurezza i dettagli di riproduzione.
  • DEVE: applicare internamente il principio del privilegio minimo alla visibilità dei dettagli delle vulnerabilità, rivelandoli solo al personale necessario per la correzione.
  • DEVE: vietare ai ricercatori di includere nei report testo in chiaro degli utenti, CEK, frammenti di URL o materiale da cui si possano derivare chiavi; se vengono inclusi per errore, il team DEVE trattare il caso come un incidente sensibile e limitarne la diffusione.

11.2 Tempi di risposta e principi di comunicazione

I tempi dipendono dalle dimensioni del team e dalla complessità, ma il progetto DOVREBBE offrire una cadenza obiettivo prevedibile e comunicare tempestivamente se gli obiettivi non vengono rispettati. Obiettivi consigliati (modificabili in base alla realtà e pubblicati in /security o in security.txt):

  • Prima risposta: ad es. conferma di ricezione e assegnazione di un ID di tracciamento entro 48 ore.
  • Valutazione iniziale: ad es. classificazione della gravità e valutazione dell'ambito dell'impatto entro 7 giorni.
  • Rilascio della correzione: in base alla gravità; le P0/P1 hanno la priorità per una correzione e un rilascio rapidi.

DOVREBBE: mantenere la comunicazione necessaria durante la gestione (ad es. riprodotta/non riprodotta, servono più informazioni, finestra stimata per la correzione) ed evitare di divulgare pubblicamente dettagli sfruttabili.

11.3 Processo di divulgazione

  1. Ricezione: registrare le informazioni del report, i passaggi di riproduzione, l'impatto e il contatto del ricercatore; assegnare un responsabile e il tracciamento.
  2. Verifica: riprodurre in un ambiente isolato; valutare l'ambito dell'impatto, la sfruttabilità e i componenti coinvolti (frontend/backend/edge/archiviazione).
  3. Correzione: implementare la patch, aggiungere test e casi di regressione, aggiungere se necessario regole di protezione (WAF/limitazione della frequenza/inasprimento delle policy).
  4. Rilascio: rilascio canary e monitoraggio delle metriche chiave; rilascio completo dopo aver escluso regressioni o nuovi rischi.
  5. Comunicazione: spiegare pubblicamente l'impatto, il contenuto della correzione e le azioni richieste agli utenti (se presenti), senza ampliare la superficie di attacco.

Per le vulnerabilità critiche o gli eventi con un forte impatto sugli utenti, si DOVREBBE pubblicare aggiornamenti sull'evento o post-mortem tramite /status in linea con il processo di risposta agli incidenti del capitolo 10.

11.4 Vulnerabilità che colpiscono i confini zero-knowledge

Il cuore dell'impegno zero-knowledge è questo: il server non può accedere alla CEK e l'ambiente di download/decifratura è isolato il più possibile, senza script di terze parti. Per questo le categorie seguenti DEVONO essere trattate con la massima priorità:

  • XSS / iniezione: possibilità di eseguire script arbitrari nelle pagine di download/decifratura, leggendo frammenti o materiale chiave in memoria.
  • Iniezione nella supply chain: avvelenamento delle dipendenze, sostituzione degli artefatti di build, iniezione tramite CDN/edge che porta alla manomissione degli script.
  • Fuga di dati nei log/nel monitoraggio: frammento di URL, CEK, token o testo in chiaro registrati per errore e accessibili.
  • Policy errata di caricamento delle risorse: pagine di download/decifratura che importano script di terze parti, CSP allentata che amplia la superficie di esecuzione.

La gestione dovrebbe comprendere: contenimento immediato (mettere offline il codice a rischio, inasprire le policy, bloccare il vettore), rilascio rapido della correzione, analisi retrospettiva dell'impatto e una dichiarazione chiara nella comunicazione su “se il materiale chiave o il testo in chiaro sia stato potenzialmente esposto”.

11.5 Aggiornamenti di sicurezza e verifica delle regressioni

  • DEVE: stabilire casi di regressione per le modifiche relative alla sicurezza (autenticazione, controllo degli accessi, CSP, filtraggio dei log, flussi di crittografia).
  • DOVREBBE: eseguire controlli automatici sulle pagine critiche (download/decifratura) per assicurarsi che non ci siano script di terze parti e che le policy degli header corrispondano alle attese.
  • DOVREBBE: rieseguire i test sugli elementi verificabili dall'esterno (ad es. scansioni TLS/header di sicurezza) dopo il rilascio della correzione.
  • DOVREBBE: documentare chiaramente nella documentazione le modifiche di compatibilità introdotte dalle correzioni (ad es. vecchi link/vecchi manifest).

In coerenza con il capitolo 12: le scansioni di terze parti verificano alcune basi di sicurezza web, ma non possono dimostrare direttamente tutti i dettagli di implementazione di zero-knowledge/E2EE; perciò la verifica delle regressioni dovrebbe coprire sia l'implementazione del protocollo sia le basi visibili.

11.6 Versionamento di protocolli e crittografia (cryptoVersion)

L'implementazione della crittografia e dei protocolli di FileBolt DEVE supportare il versionamento, per facilitare gli aggiornamenti degli algoritmi, correggere i difetti di implementazione e introdurre un isolamento più forte. Si consiglia di usare campi espliciti (ad es. cryptoVersion) associati al manifest/ai metadati.

  • Versione esplicita: ogni trasferimento/manifest DEVE dichiarare la propria cryptoVersion per stabilire algoritmi, parametri e regole di codifica.
  • Nessuna deduzione implicita: il client DEVE decidere la logica di analisi e decifratura in base ai campi espliciti del manifest, senza ipotesi né euristiche di ripiego.
  • Blocco in caso di errore: DEVE bloccarsi (fail closed) di fronte a versioni sconosciute o parametri incoerenti, senza mai ripiegare su modalità non sicure.

11.7 Compatibilità, migrazione e deprecazione

11.7.1 Retrocompatibilità

  • DOVREBBE: supportare la lettura delle vecchie versioni dei trasferimenti durante i periodi di transizione, per ridurre al minimo l'impatto sui link storici degli utenti.
  • DEVE: dichiarare pubblicamente i confini di sicurezza, i limiti e i piani di deprecazione delle vecchie versioni.

11.7.2 Migrazione (mantenendo lo zero-knowledge)

  • DOVREBBE: offrire agli utenti percorsi di “ricaricamento/ricifratura” se serve migrare dalla vecchia alla nuova versione.
  • DEVE: mantenere lo zero-knowledge durante la migrazione: la ricifratura avviene sul client e il server non può accedere alla CEK né al testo in chiaro.

11.7.3 Deprecazione e fine vita (EOL)

  • DEVE: indicare una scadenza chiara di fine vita per le versioni ritenute non più sicure.
  • DOVREBBE: invitare gli utenti a ricaricare i file nell'interfaccia e nella documentazione e prevedere finestre di migrazione sufficienti.
  • DEVE: dopo la fine vita, i client che incontrano versioni deprecate devono avvisare chiaramente e non devono tentare la decifratura.

11.8 ID delle affermazioni correlati (riservato)

Questo capitolo tratta di “canali di divulgazione delle vulnerabilità, flussi di gestione, versionamento e deprecazione”. Gli ID delle affermazioni corrispondenti saranno aggiunti all' Appendice: elenco principale degli ID delle affermazioni, che resta l'unica fonte autorevole.