Sicherheit

Die Engine: Chromium, V8, Skia

Im Lauf des Jahres 2026 wurden in Chrome Dutzende Speichersicherheitslücken geschlossen, darunter sechs Zero-Days, die aktiv ausgenutzt wurden. Diesen Code schreiben wir nicht, und wir können ihn nicht reparieren; die einzige Verteidigung besteht hier darin, die Engine aktuell zu halten.

Deshalb ist unsere Regel unmissverständlich: Der Girginos Browser wird nicht auf einer Electron-Version ausgeliefert, deren Lebenszyklus beendet ist. Electron unterstützt nur seine letzten drei Hauptversionen, und die festgelegte Version wird vor jeder Veröffentlichung geprüft. Derzeit setzen wir Electron 44.2.0 mit Chromium 152.0.7977.76 ein.

Die Shell: der Code, den wir geschrieben haben

Das sind die Architekturentscheidungen auf der Shell-Seite:

• Jeder Tab ist eine eigene WebContentsView. Seiteninhalte laufen mit sandbox: true, contextIsolation: true und nodeIntegration: false und erhalten kein Preload-Skript.
• Auch das Oberflächenfenster läuft in der Sandbox und teilt sich eine Sitzung mit den Tabs; so laufen die eigenen Anfragen der Oberfläche ebenfalls durch den Blocker und tragen die DNT-Header.
• IPC-Kanäle werden nur aus dem Hauptframe des Oberflächenfensters angenommen. Schreibzugriffe auf Einstellungen durchlaufen eine Prüfung von Schlüssel und Typ.
• Downloads werden über eine Kennung angesprochen; ein roher Dateipfad aus der Oberfläche wird niemals geöffnet.
• Von der Seite ausgelöste Navigation ist auf http(s) und view-source:http(s) beschränkt. file: und chrome: öffnen sich nur, wenn der Nutzer sie selbst in die Adressleiste eingibt.
• Die Übergabe an eine externe Anwendung ist auf eine enge Liste von Schemata begrenzt: mailto:, tel:, sms:, magnet:, ftp(s):, webcal:. Es kann immer nur ein Bestätigungsdialog offen sein.
• Opake Herkünfte — solche, deren Origin null ist, etwa data: und about: — werden bei Berechtigungsanfragen immer abgelehnt.
• Die Rechtschreibprüfung ist abgeschaltet, weil Chromium seine Wörterbuchdateien von einem Google-Server herunterlädt.
• Daten werden atomar geschrieben, über eine temporäre Datei und ein anschließendes Umbenennen.

Angriffsvektoren und Gegenmaßnahmen

Die signierte Update-Kette

Das Bedrohungsmodell geht davon aus, dass der Update-Server bereits übernommen sein kann. Der Ablauf ist dieser:

1. Das signierte Manifest und die danebenliegende Signaturdatei werden abgerufen.
2. Die Signatur wird über die rohen Bytes des Manifests mit dem in der Anwendung eingebetteten öffentlichen Ed25519-Schlüssel geprüft. Schlägt sie fehl, wird kein einziges Feld gelesen.
3. Es greifen Versionsschranken: Downgrades werden abgelehnt; ein Manifest, dessen eigenes Ablaufdatum überschritten ist, wird abgelehnt — das schützt davor, dass ein Angreifer ein altes Manifest endlos ausliefert und Updates so einfriert; wo nötig, wird eine Zwischenversion verlangt; und die Downloadadresse muss https sein.
4. Version und Paketprüfsumme, die der Downloader ermittelt, müssen exakt mit dem signierten Manifest übereinstimmen.
5. Ist der Download abgeschlossen, wird die sha512-Prüfsumme des Pakets in konstanter Zeit mit der signierten Prüfsumme verglichen.
6. Die Installation beginnt erst, wenn der Nutzer zustimmt.

Schlägt ein Schritt fehl, findet kein Update statt. Der private Schlüssel liegt nie auf dem Server; selbst wenn der Server übernommen würde, könnte ein Angreifer kein gültiges Manifest erzeugen.

Tests

118 Unit-Tests, 73 Regressionstests zu Angriffsvektoren und 46 Tests zur Update-Prüfung laufen gegen den Code, und der IPC- und DOM-Vertrag zwischen Oberfläche und Hauptprozess wird gesondert getestet. Daneben laufen vor und nach jeder Veröffentlichung Ende-zu-Ende-Skripte gegen die echten Ausgabedateien und den laufenden Server.