Test di sicurezza condotti internamente #
Si tratta di test di prima parte. Sono eseguiti dall’operatore, non da un valutatore indipendente, e non sostituiscono il penetration test esterno indipendente riportato su Trust. Vengono pubblicati perché il contenuto è utile a chi lo esamina, anche in assenza di indipendenza.
Ultimo aggiornamento: 2026-10-18.
Test eseguiti #
| Data | Tipo | Ambito | Esito |
|---|---|---|---|
| 2026-05-26 | Valutazione di sicurezza a livello di codice | Analisi statica, audit delle dipendenze e revisione manuale di autenticazione, autorizzazione e gestione dei file | La gestione dei caricamenti è stata individuata come l’area a rischio più elevato. Rilievi tracciati nel gestore delle segnalazioni e risolti: limite lato server al numero di allegati, autorizzazione dei caricamenti diretti e ripulitura di parametri e indirizzi IP nei log |
| 2026-05-26 | Test esterno in produzione, non distruttivo | Header di risposta, configurazione TLS, pagine pubbliche e sonde sui metadati verso l’host di produzione | Lacune nella copertura degli header di risposta e assenza dei metadati del contatto di sicurezza; la dipendenza da CDN di terze parti per gli asset è stata valutata a rischio medio. Risolto il 2026-05-27: metadati del contatto di sicurezza pubblicati e protezione dal content-type sniffing estesa agli asset statici |
| 2026-06-09 | Revisione dell’autenticazione | Gestione dei cookie, ciclo di vita della sessione, flussi di magic link e di invito | Due rilievi di gravità informativa. Risolti il 2026-06-14: il cookie di autenticazione in sospeso è stato spostato in un archivio cifrato, così l’indirizzo non è leggibile lato client; la scadenza dichiarata del cookie di sessione corrisponde ora al timeout di inattività lato server di 14 giorni. Un rilievo di gravità bassa: gli indirizzi dei canali di segnalazione erano derivati da identificatori sequenziali, per cui era possibile enumerare l’insieme delle organizzazioni clienti. Risolto il 2026-08-12: ogni canale di segnalazione ha un indirizzo privato casuale e la pagina mostrata per un canale di segnalazione inattivo non indica più il nome dell’organizzazione |
| 2026-08-27 | Test graybox autenticato | Accesso tra organizzazioni, elevazione di privilegi, mass assignment, accesso alle segnalazioni all’interno della stessa organizzazione, riservatezza degli allegati, isolamento SCIM, fiducia nelle asserzioni SAML | Nessun difetto di autorizzazione rilevato. I confini di organizzazione e di ruolo hanno retto in tutti i casi provati |
| 2026-08-27 | Revisione dell’esposizione in produzione | Esposizione di rete, hardening dell’host, gestione degli header di proxy e gestione dei segreti | Gli header di inoltro forniti dal client venivano considerati attendibili su un’origine direttamente esposta a internet, il che avrebbe consentito di aggirare i limiti di frequenza per IP. Corretto lo stesso giorno. È stato inoltre rimosso un header che esponeva il tempo di elaborazione del server per richiesta. L’header superato Feature-Policy è stato sostituito da Permissions-Policy il 2026-09-05 |
| 2026-09-08 | Revisione autenticata della consegna dei file e della conservazione nel browser | Download diretto delle esportazioni di dati e delle registrazioni vocali, accesso con URL di file noti tra organizzazioni diverse e dopo la rimozione di un membro, pulsante Indietro del browser dopo la disconnessione | Tre rilievi, ciascuno dei quali richiedeva un utente già autorizzato in possesso di un URL di file firmato, oppure un browser condiviso. Un’esportazione di dati scaduta poteva ancora essere scaricata da un URL conservato senza una nuova autenticazione. Un gestore poteva scaricare una registrazione vocale originale prima del completamento della sua anonimizzazione. Dopo la revoca di una sessione, il pulsante Indietro del browser poteva mostrare di nuovo una segnalazione dalla propria cache. Risolti il 2026-09-10: la consegna dei file applica ora le stesse regole di scadenza, riautenticazione ed elaborazione della pagina che vi rimanda, e le pagine sensibili e i file privati non vengono più memorizzati dal browser. L’accesso tra organizzazioni e quello di membri rimossi è stato rifiutato in tutti i casi provati |
| 2026-09-26 | Revisione a livello di codice della gestione delle sessioni | Identificazione delle sessioni e loro comportamento dopo un ripristino del database | Le sessioni erano identificate dal loro identificatore nel database. Un ripristino riporta indietro gli identificatori, per cui un nuovo accesso poteva ricevere un identificatore ancora detenuto da un cookie superstite e riprendere la sessione di quell’utente. Risolto lo stesso giorno: le sessioni sono identificate da un token casuale e tutte le sessioni esistenti sono state terminate |
| 2026-09-28 | Revisione dei log del canale di segnalazione | Log lato applicazione scritti mentre un segnalante utilizza il canale di segnalazione | Due componenti scrivevano ancora gli indirizzi IP dei segnalanti: il log delle richieste del server web e l’avviso della protezione antispam. In entrambi la scrittura è stata rimossa lo stesso giorno. Il log delle richieste proprio del proxy TLS, che registra l’indirizzo IP di ogni richiesta, è invariato ed è descritto su Security#ip-addresses |
| 2026-10-16 | Revisione a livello di codice alla luce delle ricerche attuali sugli attacchi a Rails | Elaborazione dei caricamenti, decodifica delle immagini, gestione dei messaggi firmati, log delle richieste, messaggi in tempo reale archiviati, codice di autorizzazione generato | La rimozione dei metadati sceglieva il metodo in base al tipo dichiarato dal browser, per cui una foto caricata come file generico conservava i metadati di posizione e del dispositivo. Il decoder SVG della libreria di immagini, bloccato all’avvio, veniva riattivato per l’intero processo non appena era stata generata un’immagine di anteprima di un link. I messaggi firmati e cifrati accettavano ancora un formato di serializzazione che trasforma un segreto applicativo trapelato in esecuzione di codice. I log delle richieste registravano i nomi dei file allegati e token di download a breve durata. Le notifiche in tempo reale, che contengono l’ID del caso della segnalazione, venivano archiviate non cifrate per un giorno. Il modello per le nuove policy di autorizzazione ometteva il filtro per organizzazione; nessuna policy esistente era interessata. Tutto risolto lo stesso giorno |
| 2026-10-16 | Verifica forense in produzione (CVE-2026-66066) | Ispezione in sola lettura di ogni file archiviato prima della correzione, alla ricerca di header di immagine manipolati, immagini i cui pixel si decodificano come file del server e metadati identificativi residui | Nessuna evidenza di sfruttamento nei dati conservati e nessuna immagine di segnalazione che contenga ancora metadati identificativi. I file che avrebbero potuto essere caricati tramite il percorso di caricamento diretto esposto, aperto dal 2026-04-13 al 2026-05-12, sono stati eliminati dalla pulizia giornaliera dei file non collegati e non possono più essere esaminati |
| 2026-10-17 | Revisione dell’esposizione in produzione | Log delle richieste del reverse proxy, limiti di dimensione delle richieste, scansione delle vulnerabilità dell’immagine del container | Il reverse proxy registra il percorso di ogni richiesta e i percorsi di download degli allegati contenevano il nome del file. I corpi delle richieste fino a 1 GB venivano bufferizzati su disco prima che l’applicazione li convalidasse. L’immagine del container veniva scansionata mensilmente alla ricerca di vulnerabilità del sistema operativo, a fronte di un impegno di 7 giorni per le correzioni critiche. Risolti lo stesso giorno: nessuno dei due passaggi del download di un allegato contiene il nome del file nel proprio percorso, i corpi delle richieste sono limitati appena al di sopra della segnalazione legittima più grande e l’immagine viene scansionata settimanalmente |
| 2026-10-17 | Mutation testing delle regole di autorizzazione | Le policy di accesso alle segnalazioni, ai documenti delle segnalazioni e ai canali di segnalazione, con ogni regola deliberatamente alterata per verificare che la suite di test rilevi la modifica | Ogni alterazione di quelle policy è stata rilevata. Nessun difetto di autorizzazione rilevato |
| 2026-10-18 | Revisione del codice prima della valutazione indipendente | Campi di caricamento e accesso ai file, rimozione dei metadati, blocco fino alla scansione antimalware, ruoli sui casi, amministrazione della piattaforma, registrazione dell’autenticazione, segnalazione degli errori, password dei segnalanti | Dieci rilievi. Nove corretti in giornata: un campo di caricamento accettava l’identificativo di un file già archiviato, per cui un utente poteva allegare un file che non aveva caricato e poi aprirlo (i link ai file ora scadono anche dopo un’ora); dopo la rimozione dei metadati da un PDF, l’autore originale restava recuperabile da una revisione precedente del file; l’esportazione dei dati includeva file che non avevano superato la scansione antimalware, e un file la cui scansione non era mai stata accodata veniva servito senza scansione; un Visualizzatore assegnato a un caso poteva intervenire su di esso; il pannello di amministrazione della piattaforma non richiedeva un secondo fattore; i codici monouso di login e le asserzioni SAML arrivavano al servizio di monitoraggio degli errori; gli accessi falliti, le ricerche di casi fallite e i limiti di richieste raggiunti non lasciavano traccia; i segnalanti sceglievano da soli la propria password di sei cifre, quindi veniva accettata anche una scelta comune come 123456 (le nuove segnalazioni ricevono una password di 16 cifre generata dal sistema; le segnalazioni inviate prima mantengono la propria, vedi Rilievi aperti noti). Un controllo in sola lettura della produzione non ha trovato alcun PDF di segnalazione archiviato né alcun account Visualizzatore, quindi nessuno di questi due problemi ha toccato un caso. Il rimanente è elencato tra i rilievi aperti noti |
Rilievi aperti noti #
| Rilievo | Posizione |
|---|---|
| Nessun web application firewall né CDN davanti all’origine applicativa | Scelta deliberata. L’hosting diretto dell’applicazione e dei file è nell’UE, mentre la catena di email e telemetria può comportare trattamenti a valle al di fuori del SEE. La protezione DDoS a livello di rete presso il fornitore di hosting, unita alla limitazione di frequenza applicativa, è il compromesso attuale. |
| Le foto del profilo del personale sono archiviate con i metadati originali del file | Intenzionale. La rimozione dei metadati protegge i segnalanti e le loro prove. Una foto del profilo è scelta e caricata dalla persona che ritrae. |
| Le segnalazioni inviate prima del 18 ottobre 2026 mantengono la password di 6 cifre scelta al momento dell’invio, dal segnalante o, per una segnalazione registrata dal personale, dal gestore del caso | Accettato. Queste password continuano a funzionare e non vengono sostituite. L’accesso consente 10 tentativi di password per ID del caso ogni 10 minuti, da qualsiasi IP. |
Che cosa questo non dimostra #
- L’operatore ha scelto l’ambito, eseguito i test e riportato i risultati. Nulla di ciò è stato verificato in modo indipendente.
- Una sessione senza rilievi è una prova sui casi provati, non su quelli non provati.
- Il controllo A.5.35 dell’autovalutazione ISO/IEC 27001:2022, il riesame indipendente della sicurezza delle informazioni, resta aperto per questo motivo. È l’unico controllo dell’Allegato A di quella pagina registrato come in trattamento, e lo stesso limite mantiene il capitolo 9.2 (audit interno) a parziale — si veda il registro degli audit interni.
Ultimo aggiornamento: