Daten, Datenschutz & Sicherheit › Datei-Upload-Absicherung
Datei-Upload-Absicherung
SicherheitTeilweiseQuelle geändert seit PrüfungJede hochgeladene Datei wird an ihrem tatsächlichen Inhalt erkannt, nicht an dem, was der Browser behauptet. Erlaubt sind nur gängige Fotoformate und PDF, standardmäßig bis 12 MB je Datei. Der vom Browser gelieferte Dateiname wird verworfen und durch einen eigenen ersetzt, und jeder Speicherpfad wird gegen Ausbrüche aus dem vorgesehenen Ordner geprüft.
Bild folgt
Beim Hochladen liest das System zuerst die ersten Bytes der Datei und vergleicht sie mit einer kurzen Liste erlaubter Formate — Fotoformate und PDF. Was der Browser als Typ meldet und wie die Datei heißt, wird bewusst ignoriert: Eine umbenannte Programmdatei mit passend gesetztem Typ käme sonst durch. Passt die Signatur nicht, lehnt das System die Datei ab. Danach vergibt es selbst einen Zufallsnamen mit der erkannten Endung; der Name vom Gerät des Nutzers wird verworfen und kann deshalb keinen Schaden anrichten. Jeder Speicherpfad läuft durch eine gemeinsame Prüfstelle, die alles abweist, was aus dem Datenordner hinausführt: Rücksprünge in übergeordnete Ordner, absolute Pfade, Laufwerksbuchstaben, abgeschnittene Namen und verschleierte Schreibweisen. Beim Herunterladen aller Anhänge eines Auftrags als Paket wird zusätzlich fest auf den Ordner genau dieses Auftrags gebunden, damit eine fehlerhafte Zeile in der Datenbank nicht auf fremde Dateien zeigen kann. Die Größe ist je Datei gedeckelt. Optional lässt sich das Neuberechnen der Bilder einschalten: Es verkleinert, rechnet neu und entfernt dabei alle Zusatzangaben aus dem Foto, darunter den Aufnahmeort. Standardmäßig ist das aus. Die geprüften Dateien landen bei den Belegen des Auftrags (Dokumente, Prüfungen & Fotos).
- „Dateityp nicht erlaubt", obwohl es ein Foto ist → das Format steht nicht auf der Liste, etwa eine Bildschirmaufnahme in einem Sonderformat; als JPEG oder PNG erneut speichern und hochladen.
- Eine PDF-Rechnung wird abgewiesen → die Datei ist beschädigt oder in Wahrheit kein PDF; erst öffnen und prüfen, dann neu erzeugen.
- Der Upload bricht bei großen Fotos ab → über Chat, Kontaktformular und Terminbuchung meldet schon der Browser bei mehr als 8 MB oder mehr als fünf Dateien; auf dem Server liegt die Grenze standardmäßig bei 12 MB je Datei.
- Ein GIF wird im Chat-Anhang abgelehnt, im Büro aber angenommen → die Vorprüfung im Browser ist enger als die des Servers; das ist so gewollt und kein Fehler.
- Ein Anhang fehlt im heruntergeladenen Paket → er zeigt auf einen Ort außerhalb dieses Auftrags und wird deshalb absichtlich weggelassen; den Anhang neu hochladen.
- Eine Datei ist geschrieben, wird aber später nicht gefunden → Schreib- und Leseweg zeigen auf verschiedene Datenordner; das ist eine Betriebseinstellung, kein Fehler beim Hochladen.
Schützt
- Ob die Bildneuberechnung in Produktion eingeschaltet ist, sagen die gelesenen Quellen nicht. Solange sie aus ist, bleiben Aufnahmeort und Kameradaten in den Fotos erhalten - das ist auch eine Datenschutzfrage.
- Ob der Größendeckel in Produktion beim Standardwert liegt, wurde nicht geprüft.
- Symbolische Verknüpfungen werden beim Auflösen nicht gegengeprüft. Die Upload-Wege legen selbst keine an, ein Beleg für alle Lesewege fehlt aber.
- lib/path-safe.ts
- lib/upload
- lib/upload-client.ts
- CLAUDE.md
- docs/upload-security.md
- lib/upload/magic-bytes.ts
| mechanismus | Magic-Byte-Pruefung der ersten 4-16 Bytes gegen eine kurze Allowlist (JPEG, PNG, GIF, WEBP, HEIC, PDF); Dateiname wird serverseitig neu vergeben als Zufallsname mit erkannter Endung; alle Schreibwege loesen ueber resolveDataPath() unterhalb von DATA_DIR auf und lehnen Traversal, absolute Pfade, Laufwerksbuchstaben, Nullbytes und prozentkodierte Segmente ab; der ZIP-Export pinnt zusaetzlich auf den Ordner genau dieses Auftrags |
|---|---|
| groessengrenze | 12 MB je Datei (Standard, einstellbar 1-200 MB) |
| erlaubte_formate | JPEG, PNG, GIF, WEBP, HEIC, PDF |
Beleg: docs/upload-security.md (Sprint D4): Magic-Byte-Allowlist JPEG/PNG/GIF/WEBP/HEIC/PDF, file.type wird nie gelesen, Ablehnung 400, sieben nennende Routen; lib/path-safe.ts weist .., absolute Pfade, Laufwerksbuchstaben, Nullbytes und prozentkodierte Segmente ab; lib/upload/limits.ts MAX_UPLOAD_SIZE_MB Standard 12 (1-200); Bildneuberechnung nur mit IMAGE_PROCESSING aktiv; Hausregel 4 in CLAUDE.md (DATA_DIR statt process.cwd())
Tiefer fragen
Kontext aus dem KFZ-Bozo-Handbuch
Knoten: sec-upload-guard (Sicherheit · Daten, Datenschutz & Sicherheit · teilweise · geprüft Sat Sep 05 2026 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit) @ 0f0406a1)
Kurz: Jede hochgeladene Datei wird an ihrem tatsächlichen Inhalt erkannt, nicht an dem, was der Browser behauptet. Erlaubt sind nur gängige Fotoformate und PDF, standardmäßig bis 12 MB je Datei. Der vom Browser gelieferte Dateiname wird verworfen und durch einen eigenen ersetzt, und jeder Speicherpfad wird gegen Ausbrüche aus dem vorgesehenen Ordner geprüft.
Lies zuerst (Lesebereich, nicht der ganze Baum):
lib/path-safe.ts
lib/upload
lib/upload-client.ts
CLAUDE.md
docs/upload-security.md
lib/upload/magic-bytes.ts
Hängt zusammen mit:
data-belege (lib/db/schema.ts)
Offene Fragen der Seite:
Ob die Bildneuberechnung in Produktion eingeschaltet ist, sagen die gelesenen Quellen nicht. Solange sie aus ist, bleiben Aufnahmeort und Kameradaten in den Fotos erhalten - das ist auch eine Datenschutzfrage.
Ob der Größendeckel in Produktion beim Standardwert liegt, wurde nicht geprüft.
Symbolische Verknüpfungen werden beim Auflösen nicht gegengeprüft. Die Upload-Wege legen selbst keine an, ein Beleg für alle Lesewege fehlt aber.
Hausregel 2: Vault-Daten sind für diese Session unsichtbar; Quellpfade auf Vault-Code sind keine Freigabe.
Frage: {{DEINE FRAGE}}
Antworte nur mit Belegen: nenne Datei und Zeile für jede Aussage.
Wenn die Quellen die Frage nicht beantworten, sag das und nenne, was du zusätzlich lesen müsstest.
Weicht die Seite vom Code ab, schlage den Seiten-Patch vor (wiki/seiten/daten-recht-sicherheit/sec-upload-guard.md).