Il software è costituito da due componenti principali, un Backend e un Client:
il Backend è un backend python che viene eseguito su un backend fisico ed espone un'API REST
il Client è un'applicazione web JavaScript lato utente che interagisce con il backend solo tramite XHR (XMLHttpRequest)
L'intera applicazione evita la registrazione di metadati sensibili che potrebbero portare all'identificazione dei segnalanti.
La riservatezza dell'autenticazione è protetta da TLS versione 1.2+, eventualmente anche mediante da Tor Onion Services v3 su richiesta del cliente.
Il sistema gestisce i flussi via container gestiti con docker in modalità rootless. I flussi passano per un reverse proxy che gestisce la connessione TLS (mediante certificati Let's Encrypt rinnovati automaticamente) e vengono analizzati da un container dedicato, Coraza.
Il sistema è basato sull’applicativo open source Globaleaks mantenendo piena coerenza con il canale main del progetto, così da garantire che le attività di patching e updating, anche a seguito dei penetration test e dei vulnerability assessment effettuati periodicamente, siano immediatamente applicabili alle istanze dei clienti.
Di seguito sono indicati i metodi di autenticazione implementati dal sistema.
Accedendo all'interfaccia web di login, gli amministratori e i gestori delle segnalazioni devono inserire i rispettivi nome utente e password. Se la password inserita è valida, il sistema consente l'accesso alle funzionalità disponibili per quell'utente. Il sistema implementa le seguenti misure di sicurezza per le password:
le password non vengono mai memorizzate in chiaro ma il sistema ne mantiene a riposo solo un hash. Questo vale per ogni parola segreta, password o equivalente informazione di autenticazione, comprese le ricevute dei segnalanti
la piattaforma memorizza le password degli utenti con un hash casuale avente un salt a 128 bit, unico per ogni utente. Le password vengono sottoposte a hash utilizzando Argon2. L'hash prevede un seme generato su base utente specifico per ciascun utente e un seme generato a partire dall’istanza della singola piattaforma
il sistema impone l'uso di password complesse implementando un algoritmo personalizzato necessario per garantire un'entropia ragionevole di ogni segreto di autenticazione
il sistema implementa l'autenticazione a due fattori (2FA) basata su TOTP, con algoritmo RFC 6238 e segreti a 160 bit. Gli utenti possono attivare la 2FA tramite le proprie preferenze e il cliente può indicare la volontà di imporre questo requisito all’atto dell’attivazione e, se necessario, in corso di erogazione del servizio
il sistema impone agli utenti di cambiare la propria password al primo accesso. Per impostazione predefinita, il sistema impone agli utenti di cambiare la propria password almeno ogni anno. Il cliente può indicare la volontà di modificare tale tempistica all’atto dell’attivazione e, se necessario, in corso di erogazione del servizio
I segnalanti accedono alle loro segnalazioni utilizzando una ricevuta anonima, che è una sequenza di 16 cifre generata in modo casuale e creata dal backend quando la segnalazione viene inviata per la prima volta
Il sistema implementa una prova di lavoro automatica su ogni login che impone a ogni client di richiedere un token e di risolvere un problema computazionale prima di poter eseguire un login o presentare una segnalazione. Inoltre, il sistema implementa una limitazione della velocità delle sessioni dei whistleblower impedendo l'esecuzione di più di 5 richieste al secondo
Il sistema identifica più tentativi di accesso falliti e implementa una procedura di rallentamento in cui un client che si autentica deve attendere fino a 42 secondi per completare l'autenticazione. Questa funzione ha lo scopo di rallentare eventuali attacchi che richiedono maggiori risorse agli utenti in termini di tempo, calcolo e memoria
La sicurezza delle applicazioni Web è implementata in conformità con le linee guida di sicurezza OWASP Session Management Cheat Sheet. I cookie non vengono utilizzati intenzionalmente per ridurre al minimo gli attacchi XSRF e ogni possibile attacco basato su di essi. Invece di utilizzare i cookie, l'autenticazione si basa su un'intestazione di sessione HTTP personalizzata inviata dal client sulle richieste autenticate
Il backend integra AppArmor per impostazione predefinita e implementi un profilo di sandboxing rigoroso che consente all'applicazione di accedere solo ai file strettamente necessari. Inoltre, l'applicazione viene eseguita sotto un utente dedicato e un gruppo con privilegi ridotti
Il backend implementi un database locale SQLite protetto a cui si accede tramite l'ORM SQLAlchemy. Questa scelta progettuale è stata fatta per garantire all'applicazione il pieno controllo della sua configurazione, implementando un'ampia serie di misure di sicurezza in linea con le raccomandazioni di sicurezza di SQLite (quali cancellazione sicura, auto-vacuum, livelli di trust del database limitati, disattivazione di funzionalità non strettamente necessarie)
Ogni istanza è gestita in container docker dedicati, creati e mantenuti in modalità rootless, al fine di ulteriormente limitare le possibilità di successo di eventuali tentativi di attacco, imepdendo l’escalation dei privilegi dal container al server
Le connessioni vengono analizzati da un container dedicato, Coraza, prodotto da OWASP quale successore di ModSecurity, con aggiornamento giornaliero delle regole (Owasp Core Ruleset), settato a PARANOIA-LEVEL=1
Se Coraza restituisce HTTP code 200, il flusso viene inoltrato all'istanza destinataria mediante analisi del TAG TLS Server Name Identifier (SNI)
La piattaforma su cui si basa la nostra soluzione è soggetta a periodici controlli di sicurezza indipendenti per verificare e migliorare la sicurezza del sistema
Inoltre, è attivo un progetto di bug bounty, ospitato su HackerOne
Maggiori informazioni sono disponibili cliccando qui
L’infrastruttura hardware è hostata dal fornitore tedesco Hetzner Online GmbH:
i container docker rootless vengono istanziati all’interno di Virtual Private Servers
è attivo un ulteriore firewall perimetrale fornito da Hetzner stessa
l’accesso fisico all’infrastruttura Hetzner è monitorato mediante controllati di guardiania e videosorveglianza attiva
Molteplici connessioni ridondanti al più grande punto di scambio internet tedesco, DE-CIX, assicurano un trasferimento dati senza problemi
Tutti gli upstream e i peering esistenti sono integrati nella dorsale tramite router all'avanguardia di Juniper Networks, per aumentare la capacità della rete
Per salvaguardare le applicazioni web, i siti web, i server e l'infrastruttura IT dagli attacchi DDoS, Hetzner Online utilizza il suo sistema automatico di protezione DDoS
È presente un server di back-up centrale per salvare i dati di backup. Il sistema di dischi rigidi RAID-1 riduce la probabilità di perdita dei dati
I backup vengono effettuati su base giornaliera con le seguenti retention:
7 giorni per i backup completi del sistema virtuale
30 giorni per i backup completi dei dati utili al ripristino completo dell'istanza
Su richiesta, possibilità di implementare un sistema di cold storage con fornitore europeo terzo