Template-Injection

Viele Webseiten werden nicht Buchstabe für Buchstabe von Hand geschrieben. Stattdessen gibt es Textvorlagen mit Lücken, etwa « Hallo {}, du hast {} neue Nachrichten ». Der Server füllt diese Lücken kurz vor dem Versenden mit echten Werten. Solche Vorlagen heißen Templates, und das Programm, das die Lücken füllt, ist die Template-Engine. Eine Template-Injection liegt vor, wenn ein Nutzer nicht nur einen Wert, sondern selbst eine solche Lücke in die Vorlage einschmuggeln kann. Die Engine unterscheidet nicht zwischen der Vorlage des Entwicklers und dem eingeschmuggelten Text – sie rechnet beides aus.

Warum ein Rechenzeichen im Namensfeld gefährlich ist

Template-Engines sind mehr als Lückenfüller. Sie können rechnen, Bedingungen prüfen, Listen durchlaufen und auf Objekte des Programms zugreifen. Wer Anweisungen in die Vorlage bekommt, bekommt damit Zugriff auf diese Fähigkeiten. Der klassische Test ist harmlos und aussagekräftig: Man gibt {} in ein Eingabefeld ein. Erscheint auf der Seite die Zahl 49, hat der Server gerechnet – und damit ist die Lücke bewiesen.

Von dort ist der Weg oft kurz. In vielen Engines lässt sich über verschachtelte Objekte auf Systemfunktionen zugreifen, etwa auf Befehle des Betriebssystems. Das Ergebnis nennt man Remote Code Execution: fremder Programmcode läuft auf dem Server des Betreibers. Damit sind Datenbanken, Passwörter und Kundendaten erreichbar. Template-Injection gilt deshalb als eine der schwerwiegendsten Lücken in Webanwendungen.

Wichtig ist die Abgrenzung zu Cross-Site-Scripting, kurz XSS. Dort wird eingeschmuggelter Code im Browser des Besuchers ausgeführt, also auf dessen Gerät. Bei der Server-Side Template Injection läuft er auf dem Server selbst. Der Schaden trifft damit nicht einen einzelnen Nutzer, sondern die gesamte Anwendung.

Wie die Verwechslung von Vorlage und Inhalt entsteht

Der Fehler liegt fast immer an derselben Stelle. Ein Entwickler baut Nutzereingaben nicht in die Lücke einer Vorlage ein, sondern in die Vorlage selbst. Statt das Template « Hallo {} » mit dem Wert zu füllen, setzt er den eingegebenen Namen direkt in den Vorlagentext ein und lässt das Ergebnis erst danach von der Engine verarbeiten. Enthält der Name geschweifte Klammern, werden sie als Anweisung gelesen.

Ein Vergleich macht es deutlich. Ein Formularbrief hat vorgedruckte Sätze und Felder zum Ausfüllen. Normalerweise schreibt man nur in die Felder. Bei einer Template-Injection darf der Absender auch den vorgedruckten Teil ändern – etwa den Satz « Bitte legen Sie das Original bei » hinzufügen. Wer den Brief später abarbeitet, befolgt das genauso wie den echten Text.

Der Schutz besteht darum nicht in Filtern für verdächtige Zeichen. Filter lassen sich fast immer umgehen. Richtig ist, Vorlagen ausschließlich als feste Dateien zu speichern und Nutzereingaben nur als Werte zu übergeben. Zusätzlich hilft eine Sandbox, also eine Umgebung, in der die Engine nur wenige, klar erlaubte Funktionen nutzen darf.

Von Rechnungsvorlagen bis zu Prompt-Templates

Betroffen sind vor allem Anwendungen, in denen Nutzer selbst Texte gestalten dürfen. Typische Beispiele sind Newsletter-Werkzeuge, Shop-Systeme mit anpassbaren Rechnungen, Wikis und Baukästen für Webseiten. Dort ist die freie Bearbeitung von Vorlagen ein Feature, und genau dieses Feature muss streng eingezäunt werden. Bekannte Engines wie Jinja2, Twig, Freemarker oder Handlebars tauchen deshalb regelmäßig in Sicherheitsmeldungen auf.

In News liest man von Template-Injection meist im Zusammenhang mit einer CVE-Nummer, also einem offiziell registrierten Sicherheitsproblem. Solche Meldungen betreffen häufig weit verbreitete Standardsoftware. Für Firmen bedeutet das: zügig aktualisieren, denn nach der Veröffentlichung suchen Angreifer automatisiert nach ungepatchten Servern.

Der Begriff wird inzwischen auch bei KI-Systemen verwendet. Anwendungen mit Sprachmodellen arbeiten mit Prompt-Templates, also Vorlagen für die Anweisung an das Modell. Auch hier wird Nutzertext in eine Vorlage eingesetzt. Das verwandte Problem heißt Prompt Injection und betrifft die Anweisungen an das Modell statt den Code auf dem Server. Das Grundmuster ist aber dasselbe: Daten und Anweisungen liegen im selben Text, und das System kann sie nicht auseinanderhalten.