Sicurezza

Il motore: Chromium, V8, Skia

Nel corso del 2026 in Chrome sono state corrette decine di falle di sicurezza della memoria, sei delle quali zero-day già sfruttati in attacchi reali. Questo codice non lo scriviamo noi e non possiamo correggerlo: qui l'unica difesa è tenere il motore aggiornato.

Per questo la nostra regola è netta: Girginos Browser non viene pubblicato su una versione di Electron a fine ciclo di vita. Electron supporta soltanto le sue ultime tre versioni principali e il vincolo di versione viene verificato prima di ogni rilascio. Al momento usiamo Electron 44.2.0 con Chromium 152.0.7977.76.

Il guscio: il codice che abbiamo scritto noi

Queste sono le scelte architetturali dal lato del guscio:

• Ogni scheda è una WebContentsView separata. I contenuti delle pagine girano con sandbox: true, contextIsolation: true e nodeIntegration: false, e non ricevono alcun preload.
• Anche la finestra dell'interfaccia gira in sandbox e condivide la sessione con le schede: così pure le sue richieste passano dal blocco e portano le intestazioni DNT.
• I canali IPC sono accettati solo dal frame principale della finestra dell'interfaccia. Le scritture delle impostazioni passano da una convalida di chiave e di tipo.
• I download sono indirizzati tramite identificatore; un percorso di file grezzo proveniente dall'interfaccia non viene mai aperto.
• Le navigazioni avviate dalla pagina possono essere solo http(s) e view-source:http(s). file: e chrome: si aprono solo se è l'utente a scriverli nella barra degli indirizzi.
• Il passaggio a un'applicazione esterna è limitato a un elenco ristretto di schemi: mailto:, tel:, sms:, magnet:, ftp(s):, webcal:. Può restare aperta una sola finestra di conferma per volta.
• Le origini opache — quelle il cui origin è null, come data: e about: — vengono sempre rifiutate nelle richieste di permesso.
• Il controllo ortografico è disattivato, perché Chromium scarica i file dei dizionari da un server Google.
• I dati si scrivono in modo atomico, tramite un file temporaneo e una rinomina.

Vettori d'attacco e contromisure

La catena di aggiornamento firmata

Il modello di minaccia presume che il server degli aggiornamenti possa essere già compromesso. La sequenza funziona così:

1. Si scaricano il manifest firmato e il file di firma che lo accompagna.
2. La firma viene verificata sui byte grezzi del manifest con la chiave pubblica Ed25519 incorporata nell'applicazione. Se non passa, non viene letto nemmeno un campo.
3. Si applicano i controlli di versione: il ritorno a una versione precedente è rifiutato; un manifest oltre la propria data di scadenza è rifiutato — questo protegge dall'attacco che serve all'infinito un vecchio manifest per congelare gli aggiornamenti; dove serve, si impone una versione intermedia; e l'indirizzo di download deve essere https.
4. La versione e l'hash del pacchetto trovati dal downloader devono coincidere esattamente con quelli del manifest firmato.
5. A download concluso, l'hash sha512 del pacchetto viene confrontato in tempo costante con quello firmato.
6. L'installazione parte solo dopo la conferma dell'utente.

Se uno dei passaggi fallisce, l'aggiornamento non avviene. La chiave privata non risiede mai sul server: anche se il server venisse compromesso, un aggressore non potrebbe produrre un manifest valido.

Test

Sul codice girano 118 test unitari, 73 regressioni sui vettori d'attacco e 46 test di verifica degli aggiornamenti; il contratto IPC e DOM fra l'interfaccia e il processo principale è collaudato a parte. Accanto a questi, prima e dopo ogni rilascio girano script di verifica end-to-end sugli output reali e sul server in funzione.