Whitepaper su sicurezza e privacy (panoramica)Capitolo 11

Capitolo 11: Divulgazione delle vulnerabilità e aggiornamenti di sicurezza

FileBolt incoraggia la divulgazione responsabile e crea fiducia attraverso meccanismi di risoluzione e comunicazione prevedibili. Allo stesso tempo, le capacità di sicurezza devono essere evolubili: comprese le policy di sicurezza Web, i meccanismi di autenticazione lato server e le implementazioni di crittografia/protocollo end-to-end (ad esempio, cryptoVersion aggiornamenti). Questo capitolo descrive i canali di contatto pubblico, i flussi di lavoro di elaborazione, i principi di rilascio e annuncio della correzione e spiega le strategie di evoluzione e deprecazione delle versioni.

11.0 Riepilogo

MUST: fornire canali pubblici di segnalazione delle vulnerabilità (ad esempio, security.txt ed e-mail di supporto).
SHOULD: Fornire meccanismi di invio crittografati (ad esempio, chiave PGP) per l'invio sicuro dei dettagli.
SHOULD: definire una risposta chiara e una cadenza di riparazione (tempistica SLA/Target) e comunicare tramite la pagina di stato quando necessario.
MUST: Trattare le vulnerabilità che potrebbero incidere sugli impegni Zero-Knowledge (XSS, supply chain injection, perdita di frammenti di registro) come massima priorità.
MUST: implementa l'evoluzione con versione (cryptoVersion) e definire strategie di compatibilità, migrazione e deprecazione.

11.1 Canali e contatti per la segnalazione delle vulnerabilità

11.1.1 Punti di Ingresso Pubblici

MUST: fornisce canali di invio delle vulnerabilità, scadenza e collegamenti alle policy /.well-known/security.txt.
MUST: fornire un indirizzo email di contatto per la sicurezza raggiungibile (ad es. support@filebolt.net o dedicato security@filebolt.net).
SHOULD: fornire brevi istruzioni e linee guida per l'invio del file Sicurezza e privacy page.

11.1.2 Invio crittografato e gestione delle informazioni sensibili

SHOULD: fornire la chiave pubblica PGP (o equivalente) affinché i ricercatori possano inviare i dettagli di riproduzione in modo sicuro.
MUST: Applicare internamente la visibilità con privilegi minimi per i dettagli delle vulnerabilità, divulgandoli solo al personale richiesto per la risoluzione.
MUST: vietare ai ricercatori di includere testo in chiaro dell'utente, CEK, frammenti di URL o materiale chiave derivabile nei report; se incluso inavvertitamente, il team DEVE trattarlo come un incidente sensibile e limitarne la diffusione.

11.2 Tempistiche di risposta e principi di comunicazione

Le tempistiche dipendono dalle dimensioni e dalla complessità del team, ma il progetto DOVREBBE fornire una cadenza target prevedibile e comunicare tempestivamente se gli obiettivi vengono mancati. Obiettivi consigliati (modificabili in base alla realtà e pubblicati in /security o security.txt):

Prima risposta: Ad esempio, conferma la ricezione e assegna l'ID di tracciamento entro 48 ore.
Valutazione iniziale: Ad esempio, completare la classificazione della gravità e la valutazione dell'ambito dell'impatto entro 7 giorni.
Rilascio corretto: Progresso basato sulla gravità; P0/P1 con priorità per correzione e rilascio rapidi.

SHOULD: mantenere la comunicazione necessaria durante l'elaborazione (ad esempio, riprodotto/non riprodotto, necessità di maggiori informazioni, finestra di correzione stimata) ed evitare di divulgare pubblicamente dettagli sfruttabili.

11.3 Processo di divulgazione

Receipt: registra le informazioni del report, le fasi di riproduzione, l'impatto e il contatto del ricercatore; assegnare proprietario e tracciamento.
Verification: Si riproducono in ambiente isolato; valutare l'ambito dell'impatto, la sfruttabilità e i componenti interessati (frontend/backend/edge/storage).
Remediation: Implementare patch, aggiungere casi di test/regressione, aggiungere regole di protezione se necessario (WAF/Limite di velocità/Restringimento delle policy).
Release: Rilascio Canary e monitoraggio dei parametri chiave; rilascio completo dopo aver confermato l'assenza di regressioni o nuovi rischi.
Announcement: spiegare pubblicamente l'impatto, correggere i contenuti e le azioni richieste dall'utente (se presenti) senza espandere la superficie di attacco.

Per vulnerabilità critiche o eventi ad alto impatto sull'utente, SHOULD pubblicare aggiornamenti di eventi o autopsie tramite /status in linea con il processo IR del capitolo 10.

11.4 Vulnerabilità che colpiscono i confini a conoscenza zero

Il nucleo dell'impegno Zero-Knowledge è: il server non può accedere a CEK, l'ambiente di download/decrittografia è isolato il più possibile senza script di terze parti. Pertanto, le seguenti categorie DEVONO avere la massima priorità:

XSS/Iniezione: Possibilità di eseguire script arbitrari su pagine di download/decrittografia, leggendo frammenti o materiale della chiave di memoria.
Iniezione nella catena di fornitura: Avvelenamento da dipendenze, sostituzione di artefatti di build, iniezione CDN/Edge che porta alla manomissione degli script.
Registro/monitoraggio delle perdite: frammento di URL, CEK, token o testo non crittografato accidentalmente registrato e accessibile.
Politica di caricamento delle risorse errata: Pagine di download/decrittografia che importano script di terze parti, rilassamento CSP che espande la superficie di esecuzione.

Lo smaltimento dovrebbe includere: contenimento immediato (codice rischioso offline/policy più restrittiva/vettore di divieto), rilascio rapido di soluzioni, analisi retrospettiva dell'impatto, e una chiara dichiarazione nell'annuncio su "se il materiale chiave o il testo in chiaro fosse potenzialmente esposto".

11.5 Aggiornamenti di sicurezza e verifica della regressione

MUST: Stabilire casi di regressione per modifiche relative alla sicurezza (Autenticazione, Controllo degli accessi, CSP, Filtraggio dei registri, Flussi di crittografia).
SHOULD: esegui controlli automatizzati sulle pagine critiche (download/decrittografia) per garantire che nessuno script e policy di intestazione di terze parti corrispondano alle aspettative.
SHOULD: eseguire un nuovo test degli elementi verificabili esterni (ad esempio, scansioni TLS/intestazione di sicurezza) dopo il rilascio della correzione.
SHOULD: documentare chiaramente le modifiche alla compatibilità introdotte dalle correzioni (ad esempio, vecchi collegamenti/vecchio manifest) nella documentazione.

Coerentemente con il Capitolo 12: Le scansioni di terze parti verificano alcune linee di base Web ma non possono dimostrare direttamente tutti i dettagli di implementazione di Zero-Knowledge/E2EE; pertanto la verifica della regressione dovrebbe coprire sia l'implementazione del protocollo che le linee di base visibili.

11.6 Versioning del protocollo e della crittografia (cryptoVersion)

La crittografia e l'implementazione del protocollo di FileBolt DEVE supportare il controllo delle versioni per facilitare gli aggiornamenti degli algoritmi, correggere i difetti di implementazione e introdurre un isolamento più forte. Si consiglia di utilizzare campi espliciti (ad es. cryptoVersion) associati a manifest/metadati.

Versione esplicita: Ogni trasferimento/manifesto DEVE dichiarare la propria cryptoVersion per determinare algoritmi, parametri e regole di codifica.
Nessuna inferenza implicita: Il client DEVE decidere la logica di analisi e decrittografia in base a campi manifest espliciti, senza ipotesi o euristiche di fallback.
Errore chiuso: DEVE fallire la chiusura quando si incontrano versioni sconosciute o parametri incoerenti, senza mai effettuare il downgrade a modalità non sicure.

11.7 Compatibilità, migrazione e deprecazione

11.7.1 Compatibilità con le versioni precedenti

SHOULD: supporta la lettura delle vecchie versioni di trasferimento durante i periodi di transizione per ridurre al minimo l'impatto sui collegamenti storici degli utenti.
MUST: dichiara pubblicamente i limiti di sicurezza, le limitazioni e i piani di deprecazione per le versioni precedenti.

11.7.2 Migrazione (mantenimento di conoscenza zero)

SHOULD: fornisce percorsi lato utente "Ricarica/Ricrittografa" se è necessaria la migrazione dalla versione precedente alla nuova.
MUST: Mantieni Zero-Knowledge durante la migrazione: la nuova crittografia avviene sul client, il server non può accedere a CEK o testo non crittografato.

11.7.3 Deprecazione ed EOL

MUST: Fornire una chiara sequenza temporale di fine vita per le versioni ritenute non più sicure.
SHOULD: chiedi agli utenti di ricaricare il file nell'interfaccia utente/Documenti e fornisci finestre di migrazione sufficienti.
MUST: Dopo l'EOL, i client che riscontrano versioni obsolete devono avvisare chiaramente e non devono tentare la decrittografia.

11.8 ID richiesta correlati (riservati)

Questo capitolo tratta "Canali di divulgazione delle vulnerabilità, flussi di lavoro, controllo delle versioni e deprecazione". Gli ID richiesta corrispondenti verranno aggiunti al file Appendice: Elenco principale degli ID delle richieste come unica fonte autorevole.