Dateiuploads sind kein Formularfeld: So wird aus Uploads eine sichere Pipeline

Ein Bewerbungsformular akzeptiert PDFs. Ein Kundenportal erlaubt Rechnungen und Screenshots. Die Datei landet im Storage, der Virenscanner meldet sauber – und das Team betrachtet den Upload als erledigt.

Genau hier entsteht eine gefährliche Abkürzung. Ein Dateiupload ist kein Formularfeld, sondern eine Pipeline für vollständig nutzerkontrollierten Inhalt. Sicher ist sie erst, wenn Annahme, Validierung, Verarbeitung, Speicherung, Auslieferung, Zugriff und Löschung zusammenpassen.

OWASP empfiehlt bei Uploads ausdrücklich Defense in Depth. Erweiterung, MIME-Typ, Dateisignatur, Größenlimit, Berechtigungen, Speicherort und gegebenenfalls Malware- oder Content-Prüfung ergänzen sich. Keine einzelne Maßnahme ist ein Sicherheitsbeweis.

Mythos 1: Wir erlauben nur PDF und JPG

Eine Allowlist ist sinnvoll, reicht aber nicht. Ein Dateiname kann täuschen, doppelte Erweiterungen können schlechte Filter umgehen und der vom Client gelieferte Content-Type ist manipulierbar. OWASP empfiehlt deshalb, mehrere Signale zu kombinieren und nur Dateitypen zuzulassen, die der Geschäftsprozess wirklich braucht.

Ein solider Eingangspfad prüft mindestens:

• erlaubte und normalisierte Erweiterung,
• serverseitig ermittelten Typ,
• charakteristische Dateisignatur,
• maximale Größe und gegebenenfalls Bilddimensionen,
• Authentifizierung und Berechtigung des Uploaders.

Bei komplexen Formaten kommt Parser- oder Inhaltsvalidierung hinzu. Auch eine passende Signatur reicht laut OWASP nicht allein.

Mythos 2: Der MIME-Typ kommt doch vom Browser

Bei Multipart-Uploads sendet der Client häufig Werte wie image/jpeg oder application/pdf. Dieser Header ist nützlich als Plausibilitätscheck, aber nicht vertrauenswürdig genug für eine Sicherheitsentscheidung. OWASP weist ausdrücklich darauf hin, dass er leicht gefälscht werden kann.

Wenn Dateiendung, gemeldeter MIME-Typ und tatsächlicher Inhalt widersprechen, sollte die Anwendung nicht raten, sondern kontrolliert ablehnen oder in Quarantäne halten.

Mythos 3: Der Virenscanner sagt sauber

Malware-Scanning ist wertvoll, besonders wenn Mitarbeitende hochgeladene Dokumente später öffnen. Es kennt aber nicht jede zukünftige Parser-Lücke und entscheidet nicht, ob ein Format im Browserkontext aktive Inhalte erzeugen kann. OWASP beschreibt deshalb keinen einzelnen Silver Bullet, sondern eine mehrschichtige Absicherung.

Ein Scan-Ergebnis sollte ein Status im Workflow sein, nicht die Definition von sicher.

Der übersehene Teil: Dateien werden verarbeitet

Auch wenn die Anwendung eine Datei nie direkt ausführt, passiert oft viel damit:

• Bilder werden skaliert,
• PDFs gerendert,
• Office-Dateien analysiert,
• Archive entpackt,
• Metadaten gelesen,
• OCR- oder KI-Dienste aufgerufen,
• Vorschauen erzeugt.

Jeder Parser erweitert die Angriffsfläche. Hinzu kommen Ressourcenrisiken wie sehr große Dateien oder stark komprimierte Archive. Deshalb brauchen Verarbeitungsschritte eigene Timeouts, Speicher- und CPU-Grenzen sowie einen sichtbaren Fehlerzustand.

Erst Quarantäne, dann Freigabe

Für sensible Uploads ist ein expliziter Lebenszyklus robuster als direktes Schreiben in den finalen öffentlichen Storage. Ein praktikables Modell ist:

1. accepted – Request und Berechtigung sind gültig,
2. quarantined – Datei ist gespeichert, aber nicht regulär abrufbar,
3. validated – Typ und Geschäftsregeln passen,
4. scanned – vorgesehene Malware- oder Content-Prüfung ist abgeschlossen,
5. ready – die Datei darf im Produkt verwendet werden,
6. rejected/failed – Zugriff bleibt gesperrt, Retry oder Bereinigung ist definiert.

So meldet die Oberfläche nicht vorschnell Erfolg, obwohl ein Hintergrundschritt später scheitert.

Speicherort ist eine Sicherheitsentscheidung

OWASP empfiehlt einen separaten Host oder zumindest Speicherung außerhalb des Webroots. Nutzerdateien sollten nicht deshalb zu ausführbarem Anwendungscode werden können, weil sie in einem öffentlich bedienten Verzeichnis landen.

In modernen Systemen heißt das häufig:

• Object Storage oder separater Mediendienst,
• serverseitig erzeugte Objekt-Keys statt Originalnamen als Pfad,
• private Buckets für private Inhalte,
• minimale Berechtigungen,
• autorisierte oder zeitlich begrenzte Downloadwege,
• getrennte Rechte für Upload, Verarbeitung und Auslieferung.

Ein zufälliger Dateiname ersetzt dabei keine Autorisierung. Eine UUID kann schwer zu erraten sein und trotzdem in Logs, Referrern oder geteilten Links auftauchen.

Auch die Auslieferung muss geprüft werden

RFC 9110 beschreibt Content-Type als zentrale Information darüber, wie eine HTTP-Repräsentation verarbeitet werden soll. Historisches MIME-Sniffing kann jedoch zu Sicherheitsproblemen führen.

Der WHATWG MIME Sniffing Standard nennt nutzerhochgeladene Dateien ausdrücklich als kritischen Fall: Wenn ein Server Inhalt als harmlosen Typ ausliefert, der Browser ihn aber als HTML interpretiert, kann aus einem Upload aktiver Inhalt werden.

Deshalb gehören zu geschützten Download- und Preview-Routen:

• korrekter Content-Type,
• X-Content-Type-Options: nosniff,
• bewusste Entscheidung zwischen Inline-Anzeige und Download,
• Autorisierungsprüfung bei jedem Abruf,
• passende Cache-Regeln für private Dateien.

MDN erklärt, dass nosniff den Browser anweist, den deklarierten MIME-Typ zu respektieren statt die Antwort in einen anderen Typ umzudeuten.

Größenlimits müssen reale Kosten begrenzen

Ein einzelnes 20-MB-Limit ist besser als nichts, aber die Verarbeitung kann trotzdem teuer werden. Relevant sind je nach Produkt zusätzlich:

• Request- und Dateigröße,
• Anzahl paralleler Dateien,
• Bilddimensionen,
• entpackte Größe von Archiven,
• Verarbeitungszeit,
• Nutzer- oder Workspace-Quota,
• Rate Limits.

Limits schützen nicht nur Storage, sondern auch Worker, Bandbreite und Verfügbarkeit.

Der Upload-Audit, der mehr als den Happy Path testet

Ein aussagekräftiger Test versucht die Annahmen bewusst zu brechen:

• erlaubte Endung mit falschem Inhalt,
• erlaubter MIME-Header mit unpassender Signatur,
• doppelte oder ungewöhnliche Erweiterungen,
• Datei knapp über dem Limit,
• abgebrochene und parallele Uploads,
• Ausfall von Scanner oder Parser,
• Retry desselben Uploads,
• Zugriff ohne Berechtigung oder nach Berechtigungsentzug,
• direkte Objekt-URL statt Anwendungsroute,
• private Datei über CDN oder Cache,
• Löschung inklusive Vorschaubildern und Derivaten.

Entscheidend ist nicht nur der HTTP-Status. Prüfen Sie, wo die Datei gelandet ist, ob sie abrufbar ist, welche Hintergrundjobs noch laufen und ob der Nutzer einen ehrlichen Status sieht.

Was Website-Pflichtencheck prüfen würde

Ein technischer Upload-Check kann Dateitypregeln, Extension-, MIME- und Signaturprüfung, Parser, Malware-Scanning, Quarantäne, Dateinamen, Storage-Berechtigungen, Größen- und Rate-Limits, Authentifizierung, Autorisierung, CSRF-Schutz, Preview- und Downloadrouten, Content-Type, nosniff, Cache/CDN-Verhalten, Fehler, Retries, Retention und Löschung untersuchen.

Das Ziel ist nicht maximale Reibung. Es ist eine schmale, nachvollziehbare Pipeline, die nur die Dateien und Verarbeitung erlaubt, die das Produkt tatsächlich braucht.

Wenn Ihr Upload-Sicherheitsmodell aus Dateiendung plus Virenscanner besteht, haben Sie zwei nützliche Kontrollen. Sie haben noch keine sichere Upload-Pipeline.