Ein Logo, das Code ausführen kann: warum SVG-Uploads ein unterschätztes Risiko sind

Ein SVG ist keine Bilddatei im gewohnten Sinn, sondern ein Textdokument, das Skripte enthalten kann — und damit ist jedes hochgeladene Logo im Zweifel ausführbarer Code. Das SVG-Format sieht ein eigenes script-Element ausdrücklich vor; es dient dazu, einem SVG-Dokument Skripte hinzuzufügen. Genau deshalb gehört die Bereinigung solcher Dateien in das Fundament und nicht in die Zuständigkeit der Person, die gerade ein Logo hochlädt.

Ich schreibe das nicht als Panikmache. Ich schreibe es, weil ich diese Lücke seit Jahren in Projekten sehe, die sonst sauber gebaut sind — und weil sie zu den wenigen Sicherheitsproblemen gehört, die man einmal richtig löst und danach nie wieder anfassen muss.

Warum ein SVG etwas kann, was ein JPG nicht kann

Ein JPG oder PNG ist ein Raster: eine Tabelle aus Bildpunkten. Ein Browser kann daraus nichts anderes machen als Farbe auf dem Schirm. Ein SVG dagegen ist eine Zeichenanweisung in Textform — strukturiert wie ein Dokument, mit Elementen, Attributen und Verschachtelung. Diese Struktur ist der Grund, warum SVGs beliebig scharf skalieren und winzig klein sind. Sie ist zugleich der Grund für das Problem.

Denn in diese Struktur passt mehr als Geometrie. Ein SVG kann ein Skript-Element enthalten. Es kann Ereignis-Attribute tragen, die bei Ladevorgängen oder Klicks Code auslösen. Es kann fremde Inhalte einbetten und auf externe Adressen verweisen. Ein Logo mit einem eingebauten Skript sieht dabei exakt aus wie ein Logo ohne. Weder im Vorschaubild noch im Dateimanager ist der Unterschied sichtbar. Sichtbar wird er erst, wenn jemand die Datei im Texteditor öffnet — und das tut in der Praxis niemand.

Wo aus dem Risiko ein Vorfall wird

Gefährlich wird es an einer bestimmten Stelle: wenn die hochgeladene Datei anschließend unter deiner eigenen Adresse ausgeliefert wird. Ruft jemand sie direkt auf, läuft das enthaltene Skript im Kontext deiner Domain — mit allem, was der Browser dort an angemeldeter Sitzung, Berechtigung und Vertrauen mitbringt.

Das ist kein theoretisches Konstrukt. Es ist eine dokumentierte, laufend wiederkehrende Schwachstellen-Klasse. Ein öffentlich nachlesbares Beispiel: In einer quelloffenen Zwei-Faktor-Anwendung wurden SVGs als gültiger Bildtyp akzeptiert und beim direkten Abruf ohne schützende Header ausgeliefert. Ein Angreifer konnte ein SVG mit JavaScript hochladen; wer die Datei danach direkt aufrief, gab damit seine Sitzung preis. Das Ganze läuft als CVE-2024-52597, veröffentlicht am 20. November 2024, eingestuft mit CVSS 6.1 und behoben in Version 5.4.1 (GitHub Security Advisory).

Der Ablauf ist immer derselbe: hochladen dürfen, ungeprüft speichern, unter eigener Adresse ausliefern. Drei Schritte, die für sich genommen alle harmlos aussehen.

Der Trugschluss „wir zeigen das doch nur als Bild an"

Ein häufiger Einwand lautet: Wir binden Bilder ohnehin nur als Bild ein, da passiert nichts. Der erste Teil stimmt sogar. Wird ein SVG als Bild eingebunden — über ein Bild-Element oder als Hintergrund per Gestaltungsregel —, gelten in der Regel Einschränkungen: JavaScript wird nicht ausgeführt, und externe Ressourcen werden nicht geladen. Diese Einschränkungen gelten aber ausdrücklich nur für den Bild-Kontext. Wird dieselbe Datei direkt aufgerufen oder als Dokument eingebettet, entfallen sie — dann verhält sich das SVG mit vollem Funktionsumfang, inklusive Skript-Ausführung.

Und genau das ist der Punkt, den der Einwand übersieht: Wie du die Datei auf deiner Seite einbindest, entscheidest du. Ob jemand ihre Adresse direkt im Browser öffnet, entscheidest du nicht. Sobald eine Datei eine öffentliche Adresse hat, ist der direkte Aufruf immer möglich.

Wer eigentlich SVGs hochlädt

Die Antwort erklärt, warum das Thema so hartnäckig ist: fast alle, und fast nie mit Prüfung. Das Logo kommt von der Grafikerin, das Icon-Set aus einer Bibliothek, die Kartengrafik vom Tourismusverband, das Partner-Logo per E-Mail vom Partner selbst. Diese Dateien wandern durch mehrere Hände, bevor sie in einem Redaktionssystem landen. Niemand in dieser Kette hat den Auftrag, in den Dateiinhalt zu schauen — und niemand hätte dafür ein Werkzeug zur Hand.

Deshalb ist „einfach aufpassen" hier keine Lösung. Eine Regel, die von der Wachsamkeit der Person abhängt, die gerade unter Zeitdruck ein Logo austauscht, ist keine Regel. Sie ist eine Hoffnung.

Die Lösung gehört an die Tür, nicht ans Fenster

Der wirksame Ansatz heißt Upload-Bereinigung: Die Datei wird geprüft und gesäubert, bevor sie überhaupt gespeichert wird — und gespeichert wird die gesäuberte Fassung, nicht das Original. Vier Regeln stecken dahinter:

• Erlauben statt verbieten. Nicht „alles außer Skripten" wird durchgelassen, sondern nur das bekannte Zeichen-Vokabular: Pfade, Formen, Farben, Verläufe, Filter. Alles, was nicht auf dieser Liste steht, fällt raus. Verbotslisten kann man umgehen; Erlaubnislisten nicht.
• Skripte und eingebettete Fremdinhalte fliegen raus. Das Skript-Element ebenso wie der Mechanismus, mit dem sich beliebiges HTML in eine Grafik schmuggeln lässt.
• Ereignis-Attribute fliegen raus. Alles, was bei Laden, Klick oder Fehler Code auslösen könnte.
• Verweise dürfen nur nach innen zeigen. Referenzen innerhalb derselben Datei sind erlaubt — sie sind normale Zeichentechnik. Verweise nach außen nicht, unabhängig davon, wie sie geschrieben sind. Denn genau hier wird typischerweise getrickst: mit ungewöhnlicher Schreibweise, anderem Namensraum, kreativer Verschachtelung.

Der Grund, warum das beim Hochladen passieren muss und nicht beim Anzeigen, ist banal und entscheidend: Eine Datei wird einmal gespeichert und tausendfach ausgeliefert. Sitzt die Bereinigung an der Tür, erbt jeder spätere Ausgabeweg automatisch die saubere Datei — die Website, der Zwischenspeicher, ein Export, ein externer Auslieferungsdienst. Sitzt sie am Fenster, musst du sie an jedem Fenster einzeln nachrüsten und wirst eines vergessen.

Zwei Details, die man erst in der Praxis merkt

Beim Bauen zeigt sich, dass an dieser Stelle zwei unscheinbare Dinge über Erfolg oder Ärger entscheiden.

Erstens die Größenangabe. Wenn eine Datei beim Bereinigen kleiner wird, stimmt die ursprünglich gemeldete Dateigröße nicht mehr. Wird sie nicht mitgezogen, bricht das Speichern an einer völlig anderen Stelle ab — mit einer Fehlermeldung, die nichts mit Sicherheit zu tun hat. Solche Nebenwirkungen sind der Grund, warum Sicherheitsmaßnahmen still wieder ausgebaut werden: nicht weil sie falsch sind, sondern weil sie an der falschen Stelle Schmerzen verursachen.

Zweitens die Liste der erlaubten Dateitypen. Eine Pauschale nach dem Muster „alle Bilder" ist bequem und gefährlich, weil sie stillschweigend jedes künftige Format einschließt. Eine ausdrückliche, endliche Liste ist unbequemer und richtig. Dazu gehört ein eigenes, knappes Größenlimit für Grafiken dieser Art — ein Logo braucht keine 25 Megabyte, und ein enges Limit begrenzt nebenbei, wie viel sich in einer solchen Datei überhaupt verstecken lässt.

Ehrliche Grenzen

Drei Dinge, die ich nicht behaupten will.

Keine Bereinigung ist zu hundert Prozent. Das Wettrennen zwischen Filtern und findigen Umgehungen läuft weiter, und deshalb ist Bereinigung eine Schicht in einem gestaffelten Schutz, nicht der ganze Schutz.

Sie wirkt ab dem Zeitpunkt, an dem sie eingebaut ist. Dateien, die vorher im System gelandet sind, werden davon nicht rückwirkend sauber — wer so eine Maßnahme nachrüstet, sollte den Bestand einmal gesondert anschauen.

Und es ist eine völlig legitime Entscheidung, SVG-Uploads für Redakteure gar nicht erst zuzulassen und Logos einmalig durch eine technisch verantwortliche Person einpflegen zu lassen. Weniger Komfort, weniger Angriffsfläche. Bei uns ist SVG erlaubt und wird beim Speichern bereinigt, weil scharfe Logos in jeder Bildschirmgröße ein echter Alltagsvorteil sind — aber das ist eine Abwägung, keine Naturkonstante.

Was du als Entscheider damit anfängst

Du musst das nicht selbst bauen. Du musst nur wissen, wonach du fragst. Drei Fragen an jeden, der dein digitales Fundament betreut:

1. Werden hochgeladene Dateien beim Speichern bereinigt — oder unverändert abgelegt?
2. Welche Dateitypen sind überhaupt erlaubt: eine ausdrückliche Liste oder eine Pauschale?
3. Was passiert mit Dateien, die vor dieser Regel hochgeladen wurden?

Wenn die Antwort auf Frage 1 „das macht eine zugekaufte Erweiterung" lautet, ist die nächste Frage, wer diese Erweiterung pflegt und was passiert, wenn sie nicht mehr gepflegt wird. Bei uns steckt diese Art Absicherung im Fundament selbst — nicht als Zusatzmodul, das man aktivieren oder vergessen kann. Was sonst noch serienmäßig dazugehört, steht auf der Funktions-Übersicht; wie sich das von einem erweiterungsbasierten System unterscheidet, haben wir im Vergleich aufgeschrieben.

Wenn du unsicher bist, wie dein aktuelles System mit Uploads umgeht: Melde dich kurz — das ist eine Frage, die man in einem Gespräch klärt, nicht in einem Angebot.