Logo

Whitepaper zu Sicherheit und Datenschutz (Übersicht)Kapitel 11

Kapitel 11: Offenlegung von Sicherheitslücken und Sicherheitsupdates

FileBolt fördert eine verantwortungsvolle Offenlegung und schafft Vertrauen durch vorhersehbare Abhilfe- und Kommunikationsmechanismen. Gleichzeitig müssen Sicherheitsfunktionen weiterentwickelt werden können: einschließlich Web-Sicherheitsrichtlinien, serverseitigen Authentifizierungsmechanismen und End-to-End-Verschlüsselungs-/Protokollimplementierungen (z. B. cryptoVersion Upgrades). In diesem Kapitel werden öffentliche Kontaktkanäle, Verarbeitungsworkflows, Korrekturfreigabe- und Ankündigungsprinzipien beschrieben und versionierte Entwicklungs- und Abwertungsstrategien erläutert.

11.0 Zusammenfassung

  • MUST: Stellen Sie öffentliche Kanäle zur Meldung von Schwachstellen bereit (z. B. security.txt und Support-E-Mail).
  • SHOULD: Stellen Sie verschlüsselte Übermittlungsmechanismen (z. B. PGP-Schlüssel) für eine sichere Detailübermittlung bereit.
  • SHOULD: Definieren Sie einen klaren Reaktions- und Abhilferhythmus (SLA/Zielzeitpläne) und kommunizieren Sie bei Bedarf über die Statusseite.
  • MUST: Behandeln Sie Schwachstellen, die sich möglicherweise auf Zero-Knowledge-Verpflichtungen auswirken (XSS, Supply-Chain-Injection, Log-Fragment-Leckage), mit höchster Priorität.
  • MUST: Versionierte Evolution implementieren (cryptoVersion) und definieren Sie Kompatibilitäts-, Migrations- und Einstellungsstrategien.

11.1 Kanäle und Kontakt zur Meldung von Sicherheitslücken

11.1.1 Öffentliche Einstiegspunkte

  • MUST: Stellen Sie Kanäle zur Meldung von Schwachstellen, Ablauf und Richtlinienlinks bereit /.well-known/security.txt.
  • MUST: Geben Sie eine erreichbare Sicherheitskontakt-E-Mail an (z. B. support@filebolt.net oder gewidmet security@filebolt.net).
  • SHOULD: Stellen Sie kurze Anweisungen und Einreichungsrichtlinien zur Verfügung Sicherheit und Datenschutz page.

11.1.2 Verschlüsselte Übermittlung und Umgang mit vertraulichen Informationen

  • SHOULD: Stellen Sie Forschern einen öffentlichen PGP-Schlüssel (oder einen gleichwertigen Schlüssel) zur Verfügung, damit sie Reproduktionsdetails sicher übermitteln können.
  • MUST: Erzwingen Sie intern die Sichtbarkeit der Schwachstellendetails nach dem Prinzip der geringsten Rechte und geben Sie diese nur an das für die Behebung erforderliche Personal weiter.
  • MUST: Forschern verbieten, Benutzer-Klartext, CEK, URL-Fragmente oder ableitbares Schlüsselmaterial in Berichte aufzunehmen; Bei versehentlicher Aufnahme MUSS das Team den Vorfall als sensiblen Vorfall behandeln und die Verbreitung begrenzen.

11.2 Reaktionsfristen und Kommunikationsgrundsätze

Die Zeitpläne hängen von der Größe und Komplexität des Teams ab, aber das Projekt SOLLTE einen vorhersehbaren Zielrhythmus bieten und umgehend kommunizieren, wenn Ziele verfehlt werden. Empfohlene Ziele (je nach Realität anpassbar und in /security oder security.txt veröffentlicht):

  • Erste Antwort: Z. B. Empfang bestätigen und Tracking-ID innerhalb von 48 Stunden zuweisen.
  • Erste Einschätzung: Z. B. vollständige Schweregradeinstufung und Folgenabschätzung innerhalb von 7 Tagen.
  • Fix-Release: Fortschritt basierend auf dem Schweregrad; P0/P1 priorisiert für schnelle Reparatur und Freigabe.

SHOULD: Halten Sie die notwendige Kommunikation während der Verarbeitung aufrecht (z. B. reproduziert/nicht reproduziert, weitere Informationen erforderlich, geschätztes Reparaturfenster) und vermeiden Sie die öffentliche Offenlegung verwertbarer Details.

11.3 Offenlegungsprozess

  1. Receipt: Berichtsinformationen, Reproduktionsschritte, Auswirkungen und Forscherkontakt aufzeichnen; Besitzer und Tracking zuweisen.
  2. Verification: Vermehrung in isolierter Umgebung; Bewerten Sie den Umfang der Auswirkungen, die Ausnutzbarkeit und die betroffenen Komponenten (Frontend/Backend/Edge/Storage).
  3. Remediation: Patch implementieren, Test-/Regressionsfälle hinzufügen, ggf. Schutzregeln hinzufügen (WAF/Ratenbegrenzung/Richtlinienverschärfung).
  4. Release: Canary veröffentlicht und überwacht wichtige Kennzahlen; Vollständige Freigabe nach Bestätigung, dass keine Rückschritte oder neue Risiken vorliegen.
  5. Announcement: Erläutern Sie öffentlich die Auswirkungen, beheben Sie Inhalte und erforderliche Benutzeraktionen (falls vorhanden), ohne die Angriffsfläche zu vergrößern.

Bei kritischen Schwachstellen oder Ereignissen mit großer Benutzerauswirkung: SHOULD Veröffentlichen Sie Veranstaltungsaktualisierungen oder Post-Mortems über /status im Einklang mit Kapitel 10 IR-Prozess.

11.4 Schwachstellen, die sich auf Zero-Knowledge-Grenzen auswirken

Der Kern des Zero-Knowledge-Engagements ist: Der Server kann nicht auf CEK zugreifen, die Download-/Entschlüsselungsumgebung ist so weit wie möglich ohne Skripte von Drittanbietern isoliert. Daher MÜSSEN die folgenden Kategorien mit höchster Priorität behandelt werden:

  • XSS / Injektion: Möglichkeit, beliebige Skripte auf Download-/Entschlüsselungsseiten auszuführen und dabei Fragmente oder Speicherschlüsselmaterial zu lesen.
  • Supply-Chain-Injektion: Abhängigkeitsvergiftung, Ersetzen von Build-Artefakten, CDN/Edge-Injection, was zu Skriptmanipulationen führt.
  • Leckage protokollieren/überwachen: URL-Fragment, CEK, Token oder Klartext versehentlich protokolliert und zugänglich.
  • Falsche Richtlinie zum Laden von Ressourcen: Download-/Entschlüsselungsseiten zum Importieren von Skripten von Drittanbietern, CSP-Entspannung zur Erweiterung der Ausführungsoberfläche.

Die Entsorgung sollte Folgendes umfassen: Sofortige Eindämmung (Offline-Risikocode/Verschärfungsrichtlinie/Verbotsvektor), schnelle Fehlerbehebungsfreigabe, retrospektive Auswirkungsanalyse, und klare Aussage in der Ankündigung darüber, „ob möglicherweise Schlüsselmaterial oder Klartext offengelegt wurde“.

11.5 Sicherheitsupdates und Regressionsüberprüfung

  • MUST: Regressionsfälle für sicherheitsrelevante Änderungen festlegen (Authentifizierung, Zugriffskontrolle, CSP, Protokollfilterung, Verschlüsselungsflüsse).
  • SHOULD: Führen Sie automatisierte Prüfungen auf kritischen Seiten durch (Download/Entschlüsselung), um sicherzustellen, dass keine Skripte und Header-Richtlinien von Drittanbietern den Erwartungen entsprechen.
  • SHOULD: Führen Sie nach der Fixveröffentlichung externe, überprüfbare erneute Tests der Elemente durch (z. B. TLS-/Sicherheits-Header-Scans).
  • SHOULD: Kompatibilitätsänderungen, die durch Fixes eingeführt wurden (z. B. alte Links/altes Manifest), klar in der Dokumentation dokumentieren.

Im Einklang mit Kapitel 12: Scans von Drittanbietern überprüfen einige Web-Baselines, können jedoch nicht direkt die vollständigen Zero-Knowledge/E2EE-Implementierungsdetails nachweisen; Daher sollte die Regressionsüberprüfung sowohl die Protokollimplementierung als auch sichtbare Basislinien abdecken.

11.6 Protokoll- und Kryptografieversionierung (cryptoVersion)

Die Verschlüsselung und Protokollimplementierung von FileBolt MUSS die Versionierung unterstützen, um Algorithmus-Upgrades zu erleichtern, Implementierungsfehler zu beheben und eine stärkere Isolation einzuführen. Es wird empfohlen, explizite Felder zu verwenden (z. B. cryptoVersion) in Manifest/Metadaten gebunden.

  • Explizite Version: Jede Übertragung/jedes Manifest MUSS deklarieren cryptoVersion um Algorithmen, Parameter und Kodierungsregeln zu bestimmen.
  • Keine implizite Schlussfolgerung: Der Client MUSS über die Parsing- und Entschlüsselungslogik auf der Grundlage expliziter Manifestfelder entscheiden, nicht auf der Grundlage von Vermutungen oder Fallback-Heuristiken.
  • Fehler geschlossen: Das Schließen MUSS fehlschlagen, wenn unbekannte Versionen oder inkonsistente Parameter festgestellt werden. Es darf niemals auf unsichere Modi heruntergestuft werden.

11.7 Kompatibilität, Migration und Einstellung

11.7.1 Abwärtskompatibilität

  • SHOULD: Unterstützt das Lesen alter Übertragungsversionen während Übergangsperioden, um die Auswirkungen auf historische Benutzerlinks zu minimieren.
  • MUST: Geben Sie öffentlich Sicherheitsgrenzen, Einschränkungen und Einstellungspläne für alte Versionen an.

11.7.2 Migration (Aufrechterhaltung von Zero-Knowledge)

  • SHOULD: Stellen Sie benutzerseitige Pfade zum erneuten Hochladen/Neuverschlüsseln bereit, wenn eine Migration von der alten auf die neue Version erforderlich ist.
  • MUST: Zero-Knowledge während der Migration beibehalten: Die Neuverschlüsselung erfolgt auf dem Client, der Server kann nicht auf CEK oder Klartext zugreifen.

11.7.3 veraltet und EOL

  • MUST: Stellen Sie einen klaren End-of-Life-Zeitplan für Versionen bereit, die als nicht mehr sicher gelten.
  • SHOULD: Benutzer zum erneuten Hochladen in UI/Docs auffordern und ausreichende Migrationsfenster bereitstellen.
  • MUST: Nach EOL sollten Clients, die auf veraltete Versionen stoßen, deutlich darauf hinweisen und dürfen keinen Entschlüsselungsversuch unternehmen.

11.8 Zugehörige Anspruchs-IDs (reserviert)

In diesem Kapitel werden „Kanäle, Arbeitsabläufe, Versionierung und Veraltung zur Offenlegung von Sicherheitslücken“ behandelt. Entsprechende Anspruchs-IDs werden dem hinzugefügt Anhang: Hauptliste der Anspruchs-IDs als alleinige maßgebliche Quelle.