Datei-Upload-Sicherheit: Ein vollständiger Leitfaden zum Schutz Ihrer Anwendung

Veröffentlicht

20. Juli 2026

Autor

Faizan Nadeem

Inhaltsverzeichnis

Datei-Upload-Sicherheit verstehen: Die Grundlagen

Was Datei-Upload-Sicherheit tatsächlich umfasst

Datei-Upload-Sicherheit ist die Menge an Kontrollen, die zwischen „ein Nutzer hat Bytes an meinen Server geschickt“ und „diese Bytes sind sicher gespeichert und werden sicher wieder ausgeliefert“ stehen. Es ist keine einzelne Kontrolle — es ist eine mehrschichtige Pipeline, die mehrere unabhängige Fragen beantworten muss: Ist dies wirklich der Dateityp, den ich akzeptiere? Ist die Datei das, was sie vorgibt zu sein? Hat sie eine vernünftige Größe? Enthält sie schädlichen Code? Kann ihr Dateiname verwendet werden, um aus dem Verzeichnis auszubrechen, in dem ich sie speichern wollte? Und wenn sie gespeichert ist, kann dann nur der richtige Nutzer sie abrufen?

Wenn Sie auch nur eine dieser Fragen falsch beantworten, spielt der Rest keine Rolle. Ein perfekter Malware-Scanner ist nutzlos, wenn ein Angreifer eine Datei hochladen kann, die per manipuliertem Dateinamen /etc/passwd überschreibt. Ein perfekter Dateinamen-Sanitizer hilft nicht, wenn Sie munter .php-Dateien ausführen, die in Ihr Upload-Verzeichnis gelegt wurden.

Warum Uploads eine besonders wertvolle Angriffsfläche sind

Uploads sind für Angreifer aus einem einfachen Grund attraktiv: Es ist einer der wenigen Orte, an denen ein Nutzer Ihnen beliebige binäre Daten schicken und Ihr Server diese speichern, verarbeiten und oft wieder an andere Nutzer ausliefern soll. Vergleichen Sie das mit einem normalen Formularfeld, bei dem die Eingabe Text ist und gegen ein enges Schema validiert wird. Ein Datei-Upload-Feld dagegen akzeptiert oft Megabytes undurchsichtigen Binärinhalts, den Ihre Validierung aktiv inspizieren muss, statt ihn nur passiv zu parsen.

Betrachten Sie, was tatsächlich auf dem Spiel steht:

Remote Code Execution — wenn eine hochgeladene Datei vom Server ausgeführt werden kann (eine .php- oder .jsp-Datei in einem webzugänglichen Verzeichnis), führt der Angreifer nun Code auf Ihrer Infrastruktur aus.
Stored Cross-Site Scripting — eine hochgeladene SVG- oder HTML-Datei, die anderen Nutzern wieder ausgeliefert wird, kann ein eingebettetes Skript enthalten, das in deren Browser-Sitzung ausgeführt wird.
Path Traversal und Dateiúberschreibung — ein manipulierter Dateiname wie ../../config/settings.py kann einem Angreifer erlauben, außerhalb des vorgesehenen Upload-Verzeichnisses zu schreiben.
Denial of Service — übergroße Dateien, unbegrenzte ZIP-Extraktion oder eine Flut von Upload-Anfragen können Speicherplatz, Arbeitsspeicher oder CPU erschöpfen.
Datenoffenlegung — schwache Zugriffskontrollen auf gespeicherte Dateien erlauben Nutzer A, Dateien von Nutzer B zu lesen oder zu überschreiben.

Nichts davon erfordert einen ausgefeilten Exploit. In den meisten Fällen reicht nicht mehr als eine umbenannte Datei und eine fehlende serverseitige Prüfung.

Die vollständige Verteidigungsarchitektur: Wie alles zusammenpasst

Upload-Systeme in Produktion validieren eine Datei nicht einmal und erklären die Sache dann für erledigt — sie führen sie durch eine Pipeline, in der eine Datei nur dann zur nächsten Stufe gelangt, wenn sie die vorherige übersteht. Diese Pipeline sieht ungefähr so aus:

Upload request
      ↓
Authentication & authorization check
      ↓
Rate limit check
      ↓
Temporary storage (not web-accessible)
      ↓
Extension + MIME + magic byte validation
      ↓
Size and count enforcement
      ↓
Filename sanitization & randomization
      ↓
Content-specific processing (re-encode images, inspect archives)
      ↓
Malware scan
      ↓
Approved storage (object storage, outside web root)
      ↓
Available to users (via signed URL / authenticated download)

Die zentrale Architekturentscheidung dabei ist: Einer Datei wird nie vertraut, und sie wird nie öffentlich zugänglich gemacht, bevor sie nicht jede einzelne Stufe durchlaufen hat. Wenn Ihr Scanner ausfällt, bleibt die Datei in Quarantäne — sie wird nicht „nur dieses eine Mal“ trotzdem ausgeliefert. Dasselbe Prinzip macht auch Queue-basierte Systeme in anderen Teilen Ihres Stacks zuverlässig: Jede Stufe ist unabhängig für genau eine Aufgabe verantwortlich, und ein Fehler in irgendeiner Stufe blockiert das Fortschreiten, statt die Datei stillschweigend durchzuwinken.

Die zentralen Sicherheitsschichten erklärt

Gehen wir jede Schicht der Pipeline durch und verstehen genau, wogegen sie schützt — denn jede existiert, um eine konkrete, ausnutzbare Lücke zu schließen.

Dateitypen per Allowlist zulassen, niemals per Blocklist sperren

Bekannt gefährliche Erweiterungen (.exe, .php, .sh) zu blockieren, ist ein verlorenes Spiel — Sie versuchen, jede gefährliche Erweiterung über jede Serverkonfiguration hinweg aufzulisten, und Sie werden einige übersehen (.phtml, .php5, .asp, .jsp, .cgi, .htaccess). Der richtige Ansatz ist das Gegenteil: Definieren Sie die kleine Menge an Erweiterungen, die Ihre Anwendung tatsächlich benötigt, und lehnen Sie alles andere standardmäßig ab.

Allow:  .jpg  .jpeg  .png  .pdf  .docx
Reject: everything not explicitly listed

Eine Allowlist ist eine Whitelist der Sicherheit, nicht eine Blocklist bekannter Gefahren. Sie schlägt sicher fehl, statt offen fehlzuschlagen.

Tipp für Produktion: Halten Sie die Allowlist so klein, wie es das Produkt tatsächlich erfordert. Jede Erweiterung, die Sie hinzufügen, ist eine neue Dateiklasse, die Ihre Validierungs-, Speicher- und Rendering-Logik sicher behandeln muss. Ein Upload-Feld für Lebensläufe muss kein .zip akzeptieren.

Den MIME-Typ serverseitig validieren

Der Content-Type-Header, den Ihr Client bei einem Upload mitsendet, ist nur eine Zeichenkette, die der Browser oder Client gesendet hat — sie wird nicht gegen den tatsächlichen Dateiinhalt verifiziert, und ein Angreifer kann sie auf beliebige Werte setzen. Ihm zu vertrauen ist gleichbedeutend damit, einem selbst ausgestellten Ausweis zu vertrauen.

Echte MIME-Validierung erfolgt serverseitig, indem der tatsächliche Dateiinhalt untersucht und der erkannte Typ mit dem verglichen wird, was Sie für dieses Upload-Feld erwarten. Das fängt den Fall ab, dass jemand shell.php in photo.jpg umbenennt, sich aber nicht die Mühe macht, die MIME-Erkennung zu fälschen — was für sich allein immer noch nicht reicht (siehe den nächsten Abschnitt).

Dateisignaturen verifizieren (Magic Bytes)

Jedes echte Dateiformat beginnt mit einer bestimmten Byte-Sequenz — einer „Magic Number“ — die identifiziert, was die Datei tatsächlich ist, unabhängig von Dateiname oder deklariertem MIME-Typ. Das ist die Prüfung, die einen Angreifer erwischt, der malware.exe in photo.jpg umbenennt: Die Erweiterung sagt Bild, aber die ersten Bytes lügen nie.

JPEG   FF D8 FF
PNG    89 50 4E 47
PDF    25 50 44 46
ZIP    50 4B 03 04

Erweiterungsprüfung, MIME-Prüfung und Magic-Byte-Prüfung bilden drei unabhängige Schichten. Ein Angreifer muss alle drei gleichzeitig umgehen, und eine davon — die Magic Bytes — prüft den tatsächlichen Inhalt der Datei, nicht nur ein angehängtes Label.

Beschränkungen für Dateigröße und Upload-Anzahl durchsetzen

Unbegrenzte Dateigrößen sind schon für sich ein Denial-of-Service-Vektor: Genug große Uploads erschöpfen den Speicherplatz, und wenn sie vor der Validierung vollständig in den Speicher gelesen werden, erschöpfen sie den RAM. Setzen Sie explizite, typspezifische Grenzen.

Images: 5 MB
PDF:    20 MB
Video:  100 MB

Kombinieren Sie Größenlimits mit Anzahllimits — eine maximale Dateianzahl pro Anfrage und eine maximale Zahl an Uploads pro Nutzer und Tag. Ohne beides braucht ein Angreifer keine einzelne riesige Datei, um Schaden anzurichten; ein Skript, das Tausende kleiner Dateien hochlädt, erledigt denselben Job.

Vor der Veröffentlichung auf Malware scannen

Signatur- und MIME-Prüfungen bestätigen den Typ einer Datei — sie sagen nichts darüber aus, ob eine legitim aussehende PDF- oder DOCX-Datei einen eingebetteten Exploit oder ein Makro-Payload enthält. Dafür ist ein dedizierter Malware-Scanner zuständig (ClamAV ist die gängige Open-Source-Wahl; mehrere Cloud-Anbieter bieten ebenfalls Scanning-APIs an), der als eigene Pipeline-Stufe läuft, bevor eine Datei überhaupt in den freigegebenen Speicher verschoben wird. Das ist besonders wichtig für Dateitypen, die tatsächlich ausführbare Logik enthalten können — PDFs, Office-Dokumente und ZIP-Archive — aber ihn überall einzusetzen ist eine günstige Versicherung.

Dateinamen bereinigen und randomisieren

Speichern Sie eine Datei niemals unter dem Namen, den der Nutzer angegeben hat. Nutzerseitig gelieferte Dateinamen sind vom Angreifer kontrollierte Zeichenketten, und dort stecken zwei sehr unterschiedliche Probleme:

Kollisionen bei Dateinamen und Informationsleckage. Zwei Nutzer, die resume.pdf hochladen, sollten sich nicht gegenseitig überschreiben, und es gibt keinen Grund, den ursprünglichen Dateinamen in Ihrer Speicherschicht offenzulegen.

Path Traversal. Ein Dateiname wie ../../../etc/passwd oder ..\..\Windows\system32\config ist nur eine Zeichenkette, und wenn Ihr Speichercode diese naiv an einen Basispfad anhängt, hat der Angreifer Ihrem Server gerade gesagt, wohin er schreiben soll. Erzeugen Sie für jede gespeicherte Datei eine neue, zufällige Kennung, und lassen Sie Nutzereingaben niemals direkt einen Dateisystempfad berühren.

User uploads:  resume.pdf
You store as:  b8a8b39d-17fc-4fd2-a8f7-9e1c4d2a6f31.pdf

Dateien außerhalb des Web-Roots speichern und über Ihre Anwendung ausliefern

Wenn hochgeladene Dateien in einem Verzeichnis liegen, das Ihr Webserver direkt bereitstellt (/var/www/html/uploads/), dann ist alles, was dort landet — einschließlich einer Datei, die an Ihren anderen Prüfungen vorbeigerutscht ist — sofort per URL erreichbar. Speichern Sie Uploads außerhalb des Web-Roots oder, noch besser, in Object Storage (S3, GCS, Azure Blob), das vollständig von Ihren Anwendungsservern getrennt ist, und liefern Sie Dateien über Anwendungscode oder kurzlebige signierte URLs aus, die bei jeder Anfrage die Autorisierung durchsetzen.

Niemals zulassen, dass hochgeladene Dateien ausgeführt werden

Das ist die Kontrolle, die aus „Angreifer hat ein bösartiges Skript hochgeladen“ ein Nicht-Ereignis macht. Behandeln Sie jede hochgeladene Datei als Daten, niemals als Code, egal welchen Typ sie vorgibt zu haben. Konkret: Deaktivieren Sie Ausführungsrechte auf Upload-Verzeichnissen, und stellen Sie sicher, dass Ihre Webserver-Konfiguration keinen Dateityp innerhalb des Upload-Pfads an einen Interpreter übergibt (PHP, CGI oder anderweitig). Zusammen mit Allowlisting und Speicherisolierung verhindert genau das tatsächlich Remote Code Execution — selbst wenn eine bösartige Datei irgendwie auf die Platte gelangt, wird sie nie ausgeführt.

Der Weg des Uploads: Von der Anfrage bis zum freigegebenen Speicher

Es hilft, einen Upload Ende-zu-Ende nachzuverfolgen. Nehmen wir an, ein Nutzer lädt über Ihre API ein Profilbild hoch.

Schritt 1: Anfrage und Auth-Prüfung

Der Client sendet eine POST-Anfrage mit den Bilddaten. Bevor der Server den Dateiinhalt überhaupt anfasst, prüft er die Authentifizierung (ist dies ein eingeloggter Nutzer?) und die Autorisierung (darf dieser Nutzer an diesen Endpunkt hochladen?) und prüft dann die Anfrage gegen das Rate-Limit pro Nutzer. Eine Anfrage, die bei einer dieser Prüfungen durchfällt, wird sofort abgelehnt — für nicht authentifizierte oder rate-limitierte Anfragen findet keinerlei Dateiverarbeitung statt.

Schritt 2: Temporärer, nicht öffentlicher Speicher

Der rohe Upload wird an einen temporären Ort geschrieben, der niemals per Web erreichbar ist — nicht das endgültige Ziel, nicht ein öffentlicher Bucket. Das ist die „Quarantäne“-Stufe. Hier ist noch nichts vertrauenswürdig.

Schritt 3: Strukturelle Validierung

Der Server prüft die deklarierte Erweiterung gegen die Allowlist, erkennt den tatsächlichen MIME-Typ anhand des Inhalts und verifiziert, dass die Magic Bytes zu einem echten Bildformat passen. Die Größe wird gegen das Limit des Feldes geprüft. Wenn die Datei in Wahrheit etwa ein in .jpg umbenanntes .zip ist, scheitert sie hier und kommt nicht weiter.

Schritt 4: Dateinamen-Bereinigung

Es wird ein neuer zufälliger Dateiname erzeugt. Der ursprüngliche Dateiname wird bei Bedarf als Metadatum für Anzeigezwecke gespeichert, berührt aber niemals einen Dateisystempfad.

Schritt 5: Inhaltsspezifische Verarbeitung

Da es sich um ein Bild handelt, öffnet der Server es mit einer vertrauenswürdigen Bildbibliothek und kodiert es neu — er schreibt also eine frische Datei aus, statt den hochgeladenen Bytes wortwörtlich zu vertrauen. Dieser Schritt allein neutralisiert eine große Klasse von Payloads, die in Bildmetadaten oder fehlerhaften Bildstrukturen versteckt sind, und entfernt EXIF-Daten (GPS-Koordinaten, Gerätemodell, Zeitstempel), die Nutzer normalerweise nicht teilen möchten.

Schritt 6: Malware-Scan

Die neu kodierte Datei wird gescannt, bevor sie als sicher gilt. Ein sauberes Ergebnis lässt die Datei weiter; ein positiver Befund leitet sie an einen Dead-Letter-/Quarantäne-Ort zur Prüfung weiter, und der Upload des Nutzers wird abgelehnt.

Schritt 7: Freigegebener Speicher und Auslieferung

Erst jetzt wird die Datei an ihren permanenten Ort im Object Storage verschoben. Der Datenbankeintrag für das Profilbild des Nutzers wird aktualisiert, sodass er auf das neue Objekt zeigt, und die Datei wird anderen Nutzern über das CDN oder die Object-Storage-URL ausgeliefert — niemals über einen Pfad, den ein Nutzer direkt erraten oder manipulieren könnte.

Beachten Sie die Form dieses Prozesses: Bei jedem Schritt stoppt ein Fehler das Weiterkommen der Datei, statt standardmäßig auf „erlauben“ zu fallen. Das ist die gesamte Philosophie einer sicheren Upload-Pipeline in einem Satz.

Umgang mit speziellen Dateitypen

Nicht jeder Dateityp birgt dasselbe Risiko, und einige verdienen eine spezielle Behandlung zusätzlich zur allgemeinen Pipeline.

Bilder

Bilder sind der häufigste Upload-Typ und täuschenderweise einer der einfachsten Fälle, bei denen man Fehler machen kann. Das sichere Muster ist, hochgeladenen Bild-Bytes niemals direkt zu vertrauen — öffnen Sie die Datei mit einer vertrauenswürdigen Bibliothek (Pillow in Python, Sharp in Node.js, sorgfältig konfiguriertes ImageMagick), dekodieren Sie sie und kodieren Sie sie als frische Datei neu. Das hat zwei Vorteile: Es entfernt die meisten Payloads, die auf fehlerhaften Bildstrukturen oder eingebetteten Skripten beruhen, und es entfernt EXIF-Metadaten, die den Standort oder Geräteinformationen eines Nutzers preisgeben können. Wenn die Bibliothek die Datei nicht als gültiges Bild dekodieren kann, ist das ein starkes Signal dafür, dass sie keines ist — lehnen Sie sie ab.

ZIP-Archive

ZIP-Dateien verdienen besondere Aufmerksamkeit, weil sie ein Container und kein einzelnes Artefakt sind — ein kleines ZIP kann sich zu etwas viel Größerem ausdehnen, einer „ZIP-Bombe“. Ein 5-KB-Archiv, das zu 500 GB dekomprimiert wird, erschöpft den Speicherplatz in dem Moment, in dem Sie es extrahieren. Bevor Sie irgendetwas extrahieren, prüfen Sie die Metadaten des Archivs: gesamte unkomprimierte Größe, Anzahl der Einträge, Kompressionsverhältnis und maximale Verschachtelungstiefe (ein ZIP in einem ZIP in einem ZIP). Lehnen Sie Archive ab, die sinnvolle Schwellwerte vor der Extraktion überschreiten, und bereinigen Sie jeden Dateinamen innerhalb des Archivs genauso, wie Sie einen Upload-Dateinamen bereinigen würden — verschachtelte Path-Traversal-Einträge sind genauso gefährlich wie ein einzelner bösartiger Dateiname.

Office-Dokumente

DOCX, XLSX und ähnliche Formate sind selbst ZIP-Container mit eingebettetem XML, und sie können Makros enthalten, die beim Öffnen Code ausführen. Wenn Ihre Anwendung diese Dateien nur speichern und später anzeigen muss, dann lassen Sie Makros aus den Dokumenten von Endnutzern nirgendwo in Ihrer Pipeline automatisch ausführen, und lassen Sie sie wie jeden anderen Dokumenttyp durch den Malware-Scanner laufen. Wenn Sie programmatisch Inhalte daraus extrahieren müssen, tun Sie dies mit einer Bibliothek, die das Format parst, und nicht mit einer, die es in einer Umgebung öffnet, die eingebetteten Code ausführen kann.

SVG und HTML

SVG-Dateien sind XML, und XML kann <script>-Tags enthalten — ein SVG-„Bild“-Upload kann ausführbares JavaScript enthalten, das ausgeführt wird, wenn die Datei in einem Browser betrachtet wird. Der sicherste Ansatz ist entweder, SVG-Uploads grundsätzlich abzulehnen (nur Rastergrafiken), oder sie mit einem Content-Disposition: attachment-Header und einer strikten Content-Security-Policy auszuliefern, die verhindert, dass eingebettete Skripte ausgeführt werden, statt sie inline als aktiven Inhalt zu rendern.

Skalierung und Herausforderungen in Produktion

Während des Streamings validieren, nicht erst nach vollständigem Puffern

Eine gesamte große Datei in den Arbeitsspeicher zu laden, bevor Sie überhaupt etwas validiert haben, ist selbst ein Risiko für Ressourcenerschöpfung — schon eine Handvoll gleichzeitiger großer Uploads kann den verfügbaren Speicher erschöpfen, bevor Ihre Größenprüfung überhaupt läuft. Wo Ihr Framework es unterstützt, validieren Sie Größenlimits und lesen Sie Magic Bytes inkrementell aus einem Stream, sodass übergroße oder fehlerhafte Uploads abgelehnt werden, bevor die gesamte Datei gepuffert wurde.

Rate Limits auf mehreren Ebenen anwenden

Ein einzelnes globales Rate-Limit reicht nicht aus — wenden Sie Limits pro Nutzer, pro IP und pro Endpunkt an, da diese unterschiedliche Missbrauchsmuster erfassen (ein kompromittiertes Konto vs. ein verteiltes Skript vs. ein einzelner Endpunkt, der bombardiert wird). Typische Startwerte sind etwa 20 Uploads pro Minute und Nutzer sowie ein tägliches Limit pro Konto, abgestimmt auf das, was Ihr Produkt tatsächlich benötigt.

Quarantäne und Scanning in großem Maßstab

Bei hohem Upload-Volumen wird die Malware-Scanning-Stufe zum Durchsatz-Engpass, wenn sie synchron ist. Dasselbe Muster, das für Hintergrundjob-Verarbeitung funktioniert, funktioniert auch hier: Schieben Sie Dateien nach der initialen strukturellen Validierung in eine Queue, lassen Sie einen Pool von Scanning-Workern sie asynchron verarbeiten, und setzen Sie den Status einer Datei erst dann auf „verfügbar“, wenn der Scan abgeschlossen ist. Nutzer sehen dazwischen einen Zustand „in Verarbeitung“ — was ehrlich ist, weil die Datei tatsächlich noch nicht sicher genug ist, um ausgeliefert zu werden.

Object Storage und signierte URLs

Dateien direkt von Ihren Anwendungsservern auszuliefern, skaliert schlecht und hält sensible Daten näher an Ihrer Compute-Schicht, als nötig wäre. Object Storage (S3, GCS, Azure Blob) mit kurzlebigen signierten URLs löst beide Probleme: Uploads und Downloads laufen direkt zwischen Client und Storage, Ihre Anwendung stellt nur zeitlich begrenzte, eingeschränkte URLs aus, und die Zugriffskontrolle wird in dem Moment durchgesetzt, in dem eine URL erzeugt wird, statt auf Geheimhaltung zu vertrauen.

Implementierungsdetails für bestimmte Sprachen und Frameworks

Für ein Python-Backend — Django, DRF oder FastAPI — decken einige Bibliotheken den Großteil dieser Pipeline ab:

python-magic (eine Bindung um libmagic) für MIME-Typ- und Dateisignatur-Erkennung, statt dem Content-Type von request.FILES zu vertrauen.
Pillow zum Öffnen, Validieren und Neukodieren von Bildern sowie zum Entfernen von EXIF-Metadaten über image.getexif() vor dem Speichern.
zipfile (Standardbibliothek) zum Untersuchen von Archivinhalten — Anzahl der Einträge, komprimierte vs. unkomprimierte Größe und verschachtelte Pfade — bevor extractall aufgerufen wird.
uuid (Standardbibliothek) zum Erzeugen zufälliger Speicherdatennamen.
boto3 zum Hochladen validierter Dateien nach S3 und zum Erzeugen zeitlich begrenzter Presigned URLs sowohl für Upload als auch Download.

In Django lebt diese Pipeline typischerweise in einem benutzerdefinierten Validator für FileField/ImageField plus einer clean()-Methode auf dem Formular oder Serializer — die Validierung sollte laufen, bevor die Datei jemals save() erreicht. In FastAPI gehören dieselben Prüfungen in eine Dependency oder eine Validierungsfunktion, die explizit innerhalb des Endpunkts aufgerufen wird und auf die UploadFile angewendet wird, bevor sie irgendwo dauerhaft hingeschrieben wird. In beiden Fällen sollten Sie der Versuchung widerstehen, sich ausschließlich auf Hilfsfunktionen auf Framework-Ebene im Stil von FileExtensionValidator zu verlassen — diese prüfen typischerweise den Dateinamen, nicht den Inhalt, und genau diese Lücke soll die Magic-Byte-Validierung schließen.

Ihre Upload-Sicherheitspipeline aufbauen: Codebeispiele

Unten finden Sie funktionierende Implementierungen der Prüfungen, die in Python am wichtigsten sind. Diese sind dafür gedacht, in die Validierungsschicht Ihres Frameworks übernommen und angepasst zu werden, nicht unverändert eingesetzt zu werden.

Magic-Byte-Validierung — tatsächliche Dateisignaturen gegen erwartete Typen prüfen:

MAGIC_BYTES = {
    "image/jpeg": [b"\xFF\xD8\xFF"],
    "image/png": [b"\x89PNG\r\n\x1a\n"],
    "application/pdf": [b"%PDF-"],
}

def verify_magic_bytes(file_bytes: bytes, expected_mime: str) -> bool:
    signatures = MAGIC_BYTES.get(expected_mime)
    if not signatures:
        return False
    return any(file_bytes.startswith(sig) for sig in signatures)

Serverseitige MIME-Erkennung mit python-magic, verglichen mit der Angabe des Clients:

import magic

def detect_mime_type(file_bytes: bytes) -> str:
    return magic.from_buffer(file_bytes, mime=True)

def validate_upload(file_bytes: bytes, allowed_mimes: set[str]) -> bool:
    detected = detect_mime_type(file_bytes)
    if detected not in allowed_mimes:
        return False
    return verify_magic_bytes(file_bytes, detected)

Sichere Dateinamen-Erzeugung — dem Originalnamen niemals für die Speicherung vertrauen:

import uuid
from pathlib import PurePosixPath

def safe_storage_name(original_filename: str) -> str:
    extension = PurePosixPath(original_filename).suffix.lower()
    allowed_extensions = {".jpg", ".jpeg", ".png", ".pdf", ".docx"}
    if extension not in allowed_extensions:
        raise ValueError("Extension not allowed")
    return f"{uuid.uuid4()}{extension}"

Bild-Neukodierung und EXIF-Entfernung mit Pillow:

from io import BytesIO
from PIL import Image

def reencode_image(file_bytes: bytes, max_dimension: int = 4096) -> bytes:
    image = Image.open(BytesIO(file_bytes))
    image.verify()  # raises if the file isn't a valid image

    image = Image.open(BytesIO(file_bytes))  # reopen after verify()
    image.thumbnail((max_dimension, max_dimension))

    output = BytesIO()
    # Saving without the original EXIF block strips metadata by default
    image.convert("RGB").save(output, format="JPEG", quality=85)
    return output.getvalue()

ZIP-Bomben-Schutz — ein Archiv prüfen, bevor irgendetwas extrahiert wird:

import zipfile

MAX_UNCOMPRESSED_SIZE = 200 * 1024 * 1024  # 200 MB
MAX_ENTRIES = 1000
MAX_COMPRESSION_RATIO = 100

def is_zip_safe(zip_path: str) -> bool:
    with zipfile.ZipFile(zip_path) as archive:
        infos = archive.infolist()
        if len(infos) > MAX_ENTRIES:
            return False

        total_uncompressed = 0
        for info in infos:
            if ".." in info.filename or info.filename.startswith("/"):
                return False  # path traversal attempt

            total_uncompressed += info.file_size
            if total_uncompressed > MAX_UNCOMPRESSED_SIZE:
                return False

            if info.compress_size > 0:
                ratio = info.file_size / info.compress_size
                if ratio > MAX_COMPRESSION_RATIO:
                    return False

        return True

Einfaches Rate-Limiting pro Nutzer mit Redis:

import time
import redis

r = redis.Redis()

def check_upload_rate_limit(user_id: str, max_per_minute: int = 20) -> bool:
    key = f"upload_rate:{user_id}:{int(time.time() // 60)}"
    count = r.incr(key)
    if count == 1:
        r.expire(key, 60)
    return count <= max_per_minute

Jede dieser Funktionen ist eine Stufe in der zuvor beschriebenen Pipeline — sie sind dafür gedacht, verkettet zu werden, nicht isoliert verwendet zu werden.

Häufige Fallstricke und wie man sie vermeidet

Nur die Erweiterung prüfen

Fehler: Uploads nur anhand der Dateierweiterung im Dateinamen ablehnen. Ein Angreifer benennt shell.php in shell.jpg um und die Prüfung besteht.

Lösung: Kombinieren Sie Erweiterung, serverseitige MIME-Erkennung und Magic-Byte-Verifikation. Alle drei müssen übereinstimmen, bevor eine Datei akzeptiert wird.

Dem vom Client gelieferten Content-Type vertrauen

Fehler: request.headers['Content-Type'] auslesen und als Tatsachenbasis behandeln. Das ist ein Wert, den der Client gewählt hat, nicht eine validierte Tatsache über die Datei.

Lösung: Erkennen Sie den MIME-Typ serverseitig anhand der tatsächlichen Datei-Bytes und behandeln Sie den Header des Clients höchstens als Hinweis.

ZIP-Archive ohne Limits extrahieren

Fehler: extractall() auf ein hochgeladenes Archiv ohne jede Prüfung anwenden. Eine winzige Datei kann zu Hunderten von Gigabytes dekomprimieren und den Server lahmlegen.

Lösung: Prüfen Sie Anzahl der Einträge, gesamte unkomprimierte Größe und Kompressionsverhältnis, bevor Sie irgendetwas extrahieren, wie oben gezeigt. Lehnen Sie Archive ab, die sinnvolle Schwellwerte überschreiten.

Uploads aus einem webzugänglichen Verzeichnis ausliefern

Fehler: Uploads direkt in dem Verzeichnis speichern, das der Webserver bereitstellt (/var/www/html/uploads/), sodass alles, was dort landet, sofort per URL erreichbar ist.

Lösung: Speichern Sie außerhalb des Web-Roots, idealerweise in Object Storage, das vollständig von den Anwendungsservern getrennt ist, und liefern Sie über authentifizierte Anwendungslogik oder signierte URLs aus.

Autorisierung beim Download überspringen

Fehler: Annehmen, dass ein gespeicherter Dateiname als zufällige UUID ausreicht, um die Datei sicher an jeden auszuliefern, der sie anfordert. Verschleierung ist keine Autorisierung — die URL wird irgendwann durchsickern, sei es über Logs, Referrer-Header oder einen geteilten Link.

Lösung: Prüfen Sie bei jedem Download, ob der anfragende Nutzer Eigentümer der Datei ist oder Zugriff darauf erhalten hat, nicht nur beim Upload.

Validierung als einmalige Schranke behandeln

Fehler: Eine Datei einmal beim Upload validieren und annehmen, dass sie danach für immer sicher ist — auch dann, wenn sie später von einem anderen Teil des Systems verarbeitet wird (z. B. ein Hintergrundjob, der die Datei mit einer anderen Bibliothek öffnet).

Lösung: Halten Sie die Garantien der Pipeline explizit — eine Datei, die Validierung und Scan bestanden hat, ist sicher genug, um sie so wie sie ist zu speichern und auszuliefern; das ist keine pauschale Garantie für jede zukünftige Operation, die mit ihr durchgeführt wird. Nachgelagerte Verbraucher sollten Dateien weiterhin defensiv öffnen.

Best Practices für Produktion

Protokollieren Sie Upload-Aktivitäten mit genügend Details, um Vorfälle untersuchen zu können — Nutzer-ID, IP-Adresse, erzeugter Dateiname, erkannter MIME-Typ, Größe und Scan-Ergebnis. Vermeiden Sie es, den Dateiinhalt selbst zu protokollieren.

Immer erst Quarantäne, dann Veröffentlichung. Eine Datei wird niemals in den freigegebenen Speicher verschoben oder anderen Nutzern zugänglich gemacht, bevor nicht jede Stufe der Pipeline — strukturelle Validierung, Inhaltsverarbeitung und Malware-Scanning — erfolgreich abgeschlossen wurde.

Sicher geschlossen fehlschlagen, nicht offen. Wenn der Malware-Scanner vorübergehend nicht verfügbar ist, besteht das korrekte Verhalten darin, die Datei in Quarantäne zu halten, nicht den Scan zu überspringen und trotzdem zu veröffentlichen.

Testen Sie die Pipeline mit gegnerischen Eingaben, nicht nur mit gültigen. Umbenannte ausführbare Dateien, übergroße Dateien, tief verschachtelte ZIP-Archive und Path-Traversal-Dateinamen sollten alle Teil Ihrer Test-Suite sein — das Ziel ist nachzuweisen, dass jede Stufe tatsächlich das ablehnt, was sie vorgibt abzulehnen.

Führen Sie neue akzeptierte Dateitypen bewusst ein. Das Hinzufügen einer neuen Erweiterung zur Allowlist vergrößert Ihre Angriffsfläche; behandeln Sie dies mit derselben Sorgfalt wie jede andere sicherheitsrelevante Änderung, einschließlich einer Prüfung, wie dieser Dateityp validiert, verarbeitet und ausgeliefert wird.

Überprüfen Sie Speicher- und Aufbewahrungsrichtlinien für hochgeladene Inhalte, insbesondere für alles, was personenbezogene Daten enthält — legen Sie fest, wie lange Dateien aufbewahrt werden, und stellen Sie sicher, dass ihre Löschung sie tatsächlich aus jeder Speicherebene entfernt, nicht nur aus dem primären Datenbankeintrag.

Zum Schluss

Datei-Upload-Sicherheit ist keine einzelne Validierungsfunktion — sie ist eine Pipeline, in der jede Stufe dafür verantwortlich ist, eine ganz bestimmte Lücke zu schließen, und eine Datei verdient sich Vertrauen nur, indem sie alle Stufen überlebt. Legen Sie per Allowlist fest, was Sie akzeptieren, verifizieren Sie Inhalte statt Dateinamen, lassen Sie hochgeladene Dateien niemals ausführen, isolieren Sie den Speicher vom Web-Root, und betrachten Sie eine Datei erst dann als sicher, wenn sie tatsächlich gescannt wurde.

Die meisten Upload-Schwachstellen in Produktionssystemen lassen sich darauf zurückführen, dass eine dieser Schichten ausgelassen wurde, nicht auf irgendeine exotische Angriffstechnik — und das sind gute Nachrichten, denn das bedeutet, dass die Lösung fast immer unkompliziert umzusetzen ist, sobald Sie wissen, welche Schicht fehlt.

Sind Sie in einem System, an dem Sie gearbeitet haben, schon einmal auf eine Upload-Schwachstelle gestoßen oder auf eine Validierungsschicht, die sich als wichtiger herausgestellt hat als erwartet? Ich würde mich freuen, davon zu hören.