File Uploads richtig absichern und testen: Ein Kriterienkatalog aus der Praxis

Datei-Uploads sind einer der klassischsten und gefährlichsten Angriffspunkte einer Webanwendung: Der Nutzer schiebt beliebige Bytes auf Ihren Server, und ab dann entscheidet allein Ihre Verarbeitung darüber, ob daraus ein harmloses Profilbild oder eine Remote-Code-Execution wird. Dieser Beitrag fasst 18 Prüfkriterien zusammen, mit denen sich Upload-Funktionen systematisch absichern und testen lassen.

Veröffentlicht: 05.05.2026 · Lesezeit: 11 Min · Autor: Niclas Zillmanns

Warum Uploads gefährlich sind

Ein Upload-Endpunkt verletzt eine zentrale Sicherheitsannahme: Er akzeptiert von Haus aus nutzergesteuerte Inhalte und persistiert sie. Geht dabei etwas schief, reicht das Spektrum von lästig bis katastrophal:

• Remote Code Execution, wenn eine hochgeladene Datei als Skript ausgeführt wird (z. B. eine .php-Datei in einem vom Webserver interpretierten Verzeichnis).
• Stored XSS über HTML, SVG oder manipulierte Metadaten, die später im Browser eines anderen Nutzers gerendert werden.
• Path Traversal, bei dem ein manipulierter Dateiname aus dem Upload-Verzeichnis ausbricht und bestehende Dateien überschreibt.
• Denial of Service durch riesige Dateien, Zip-Bombs oder rekursive Archive.
• Malware-Verteilung, wenn Ihre Plattform ungewollt zum Hoster für Schadsoftware wird.

Die gute Nachricht: Praktisch alle dieser Risiken lassen sich mit einer überschaubaren Menge klar benennbarer Kontrollen adressieren. Genau die haben wir in einem Kriterienkatalog zusammengefasst.

Zwei Perspektiven: absichern und testen

Der Katalog funktioniert in beide Richtungen. Als Entwickler:in lesen Sie ihn als Anforderungsliste – jedes Kriterium ist eine Kontrolle, die implementiert sein sollte. Als Tester:in lesen Sie ihn als Prüfplan – jedes Kriterium liefert Evidenzhinweise, an denen sich beobachten lässt, ob die Kontrolle greift oder umgehbar ist. Die folgenden Abschnitte gruppieren die 18 Kriterien thematisch; der komplette Katalog steht weiter unten als Referenz.

Zugang & Anfrage (K1–K4)

Bevor auch nur ein Byte verarbeitet wird, muss klar sein, wer hochladen darf und wie viel.

• K1 – Zugriffskontrolle: Upload-Endpunkte erfordern Authentisierung und eine rollen- bzw. kontextbasierte Autorisierung. Ein Upload „aus Versehen öffentlich" ist einer der häufigsten Befunde.
• K2 – Schutz vor Request-Manipulation: Zustandsbehaftete Uploads brauchen CSRF-Schutz bzw. eine Tokenbindung, damit sie nicht im Namen eines eingeloggten Opfers ausgelöst werden können.
• K3 – Serverseitige Größenlimits: Feste Limits für Datei- und Request-Größe, die vor der aufwendigen Verarbeitung greifen. Ein Client-seitiges Limit ist kein Limit.
• K4 – Quoten und Rate-Limiting: Begrenzung von Anzahl und Frequenz pro Nutzer und Zeitfenster, um Missbrauch und DoS zu verhindern.

Dateivalidierung (K5–K9)

Das Herzstück. Hier entscheidet sich, ob eine Datei das ist, was sie vorgibt zu sein – und ob ihr Inhalt unschädlich ist.

• K5 – Allowlist für Dateiendungen: Nur die tatsächlich benötigten Endungen sind erlaubt. Eine reine Denylist („alles außer .exe") wird praktisch immer umgangen.
• K6 – Serverseitige MIME-/Typvalidierung: Der Typ wird serverseitig geprüft. Der vom Client gesendete Content-Type-Header ist ein Wunsch, keine Tatsache.
• K7 – Signatur-/Strukturprüfung: Prüfung der Magic-Bytes bzw. eine formatbasierte Validierung, bevor die Datei gespeichert oder weiterverarbeitet wird.
• K8 – Inhaltsneutralisierung: Re-Encoding bzw. Transcoding (z. B. Bilder neu rendern) oder Content Disarm & Reconstruction (CDR) für Dokumente entfernt eingebettete aktive Inhalte.
• K9 – Archiv- und Dekompressionssicherheit: Archive werden vor dem Entpacken geprüft – mit Pfadkontrolle und Limits gegen Zip-Bombs und rekursive Archive.

Wichtig: Diese Prüfungen sind kumulativ, nicht alternativ. Endung, MIME-Typ und Signatur müssen zusammenpassen – und selbst dann ist eine strukturell valide Datei nicht automatisch ungefährlich (siehe Polyglots und eingebettete Skripte).

Speicherung & Namen (K10–K13)

Selbst eine valide Datei kann Schaden anrichten, wenn sie am falschen Ort mit den falschen Rechten landet.

• K10 – Dateinamenhärtung: Serverseitig generierte, nicht vorhersagbare Namen; Sanitization und Längenlimits. Der ursprüngliche Dateiname wird höchstens als Anzeige-Metadatum gespeichert, nie als Pfadbestandteil übernommen.
• K11 – Pfad- und Speicherortkontrolle: Kanonisierung oder Whitelisting der Zielpfade, um Path Traversal (../) zu verhindern.
• K12 – Speichertrennung: Ablage außerhalb des Webroots oder in separatem Storage (z. B. Objektspeicher), damit hochgeladene Dateien nicht direkt ausgeliefert oder ausgeführt werden können.
• K13 – Rechte- und Ausführungskontrolle: Restriktive Dateirechte, keine Execute-Handler auf dem Upload-Verzeichnis, konsequentes Least-Privilege-Prinzip.

Bereitstellung & Abwehr (K14–K15)

• K14 – Sichere Bereitstellung/Downloads: Kontrolliertes Serving mit Content-Disposition: attachment, korrektem Content-Type und X-Content-Type-Options: nosniff. Ziel: keine Inline-Ausführung im Browser-Kontext der Anwendung.
• K15 – Malware-Abwehr: Malware-Scan oder eine mehrstufige Prüfung vor der Freigabe – bei großen Dateien gern asynchron, mit einem „Quarantäne"-Status bis zum Scan-Ergebnis.

Betrieb & Nachvollziehbarkeit (K16–K18)

• K16 – Logging und Audit-Trail: Uploads, Ablehnungen und Auffälligkeiten werden mit Kontext protokolliert – wer, was, wann, mit welchem Ergebnis.
• K17 – Fehler- und Informationskontrolle: Keine sensitiven Pfade oder Stacktraces in Fehlermeldungen; reduzierte, generische Rückmeldungen an den Client.
• K18 – Temporärdaten- und Lebenszyklusmanagement: Sichere Temp-Speicherung, zuverlässiges Cleanup und Schutz vor TOCTOU-Zuständen (Time-of-Check-to-Time-of-Use) zwischen Prüfung und endgültiger Ablage.

Der vollständige Kriterienkatalog

Zum Abhaken – in Reviews, Abnahmen und Pentests gleichermaßen nutzbar:

Wie man Uploads testet

Ein Test verifiziert nicht, ob eine Kontrolle existiert, sondern ob sie sich umgehen lässt. Bewährt hat sich, jeden Katalogpunkt aktiv anzugreifen. Die folgenden Testfälle decken die häufigsten Umgehungen ab:

1. Endungs- und Typ-Bypässe (K5–K7): Doppelendungen (shell.php.jpg), Groß-/Kleinschreibung (.PhP), Null-Byte-Tricks in Altsystemen, alternative ausführbare Endungen (.phtml, .phar, .svg), sowie gefälschte Content-Type-Header bei gleichzeitig manipuliertem Inhalt.
2. Magic-Byte-Polyglots (K6–K8): Eine Datei, die valide Magic-Bytes eines Bildes trägt, aber im Anhang auslösbaren Code enthält (z. B. PHP nach den JPEG-Headern). Prüft, ob die Signaturprüfung durch Re-Encoding ergänzt wird.
3. SVG/HTML-XSS (K8, K14): Ein <svg> mit eingebettetem <script> oder onload-Handler – wird es beim Download inline im Browser gerendert oder als Attachment ausgeliefert?
4. Path Traversal (K10, K11): Dateinamen wie ../../var/www/html/shell.php oder mit kodierten Sequenzen, um aus dem Zielverzeichnis auszubrechen.
5. Ausführbarkeit am Speicherort (K12, K13): Nach dem Upload die Datei direkt über ihre URL aufrufen – wird sie interpretiert oder nur ausgeliefert?
6. Archiv-Angriffe (K9): Zip-Bombs, tief verschachtelte Archive und Archive mit Traversal-Pfaden in den enthaltenen Dateinamen.
7. Ressourcen & Limits (K3, K4): Übergroße Dateien, sehr viele parallele Uploads und wiederholte Requests, um Größenlimits und Rate-Limiting zu prüfen.
8. Race Conditions (K18): Eine Datei hochladen und im engen Zeitfenster zwischen Prüfung und finaler Ablage aufrufen bzw. ersetzen (TOCTOU).
9. Fehler- und Info-Leaks (K17): Absichtlich fehlerhafte Uploads provozieren und prüfen, ob Pfade, Stacktraces oder interne Details zurückkommen.

Ein Proxy wie OWASP ZAP oder Burp Suite ist dabei Pflicht: Fast alle interessanten Bypässe entstehen, indem man die Anfrage nach der clientseitigen Validierung abfängt und manipuliert. Client- seitige Prüfungen dienen der Usability, nicht der Sicherheit.

Faustregel: Vertraue nichts, was aus dem Request kommt – nicht dem Dateinamen, nicht der Endung, nicht dem Content-Type, nicht der Größenangabe. Prüfe serverseitig, speichere getrennt, liefere kontrolliert aus.

Fazit

Sichere Datei-Uploads sind kein einzelnes Feature, sondern eine Kette von Kontrollen entlang des gesamten Lebenszyklus – von der Zugriffskontrolle über die Validierung und Speicherung bis zur kontrollierten Bereitstellung. Der Kriterienkatalog macht diese Kette überprüfbar: Als Anforderungsliste für die Entwicklung und als Prüfplan für den Test. Wer alle 18 Punkte belastbar erfüllt, hat die überwiegende Mehrheit realer Upload-Angriffe bereits abgeräumt.

Sie möchten Ihre Upload-Funktion überprüfen lassen? Sprechen Sie uns an – wir testen sie entlang genau dieses Katalogs.

← Zurück zur Blog-Übersicht