Sicherheit

Diese Seite listet die tatsächlich implementierten technischen Maßnahmen — und ebenso ehrlich die noch offenen Lücken. Für datenschutzrechtliche Fragen siehe die Datenschutzerklärung.

Datei-Upload

  • ZIP-Bombs, Path Traversal, Symlink-AngriffeImplementiert

    Kompressionsverhältnis- und Größenlimits, Ablehnung von Pfad-Escapes und Symlink-Einträgen in Archiven, verschachtelte Archive werden abgelehnt.

  • FormaterkennungImplementiert

    Basiert auf der tatsächlichen Treiber-Erkennung (GDAL/OGR), nicht auf der Dateiendung — eine manipulierte Endung täuscht die Analyse nicht.

  • Malware-Scan des DateiinhaltsNicht vorhanden

    Kein Virenscanner integriert.

Kommandoausführung (GDAL/OGR)

  • Command-/Shell-InjectionImplementiert

    Kein shell=True, keine Nutzereingabe als Rohstring. Ziel-Koordinatensystem nur als geprüftes EPSG:<Zahl>, Zielformat nur über eine feste Registry-Whitelist auswählbar — keine frei durchgereichten GDAL-Kommandozeilenoptionen.

Integrität

  • PrüfsummenImplementiert

    Jede hoch- und heruntergeladene Datei wird per SHA-256 geprüft.

  • NachvollziehbarkeitImplementiert

    Ein Processing Manifest dokumentiert jeden Verarbeitungsschritt einer Konvertierung.

Downloads & Transport

  • DownloadsImplementiert

    Nur über zeitlich begrenzte, signierte Links — keine öffentlich erreichbaren Speicher-Buckets.

  • Verschlüsselter Transport (TLS)Noch nicht live

    Vorbereitet (Certbot-Service steht bereit), wird erst mit der echten Domainzuweisung beim Produktivdeploy aktiviert.

Größte bekannte offene Lücken

  • Keine Sandbox-Isolation pro Konvertierungsjob. Der Worker läuft aktuell als langlebiger Prozess ohne Kurzlebig-Isolation zwischen einzelnen Jobs. Vor einem Produktivstart mit Fremd-Uploads ist das der wichtigste offene Punkt.
  • Kein wiederkehrender externer Penetrationstest und kein automatisiertes Dependency-/Container-Scanning bisher eingerichtet.
  • Backups noch nicht implementiert.