Was ist SSTI?

Server-Side Template Injection, kurz SSTI, betrifft Anwendungen, die Seiten, Nachrichten oder Dokumente mit einer Template Engine erzeugen. Wird eine nicht vertrauenswürdige Eingabe Teil des Template-Quelltexts, kann ein Angreifer Template-Ausdrücke einschleusen. Die Folgen reichen vom Lesen von Variablen über Funktionsaufrufe bis zur Codeausführung auf dem Server.

SSTI unterscheidet sich von Cross-Site Scripting. XSS wird im Browser eines Besuchers ausgeführt; SSTI wertet die serverseitige Template Engine aus. Die konkrete Syntax und Auswirkung hängen von der Engine und ihrer Sandbox ab.

Wie lässt sich SSTI verhindern?

• - Den Template-Quelltext fest halten und Benutzerinhalte nur als Datenvariablen übergeben.
• - Vom Benutzer bearbeitbare Templates vermeiden, sofern die Funktion nicht bewusst dafür entworfen und stark isoliert ist.
• - Sandboxing als zusätzliche Kontrolle verstehen, nicht als Freigabe für beliebige Ausdrücke.
• - Die Verarbeitung mit minimalen Rechten ausführen und die Template Engine aktuell halten.

Codebeispiel: Template-Quelltext und Daten trennen

Verwundbar mit Twig:

// Nutzereingabe wird selbst zum ausführbaren Template
$template = $twig->createTemplate($request->input('message'));
return $template->render(['user' => $user]);

Sicher:

// notification.html.twig stammt aus dem vertrauenswürdigen Deployment
return $twig->render('notification.html.twig', [
    'message' => $request->input('message'),
    'user' => $user,
]);

Die Template Engine kodiert die Variable entsprechend ihrem Kontext. Soll ein Nutzer wirklich Vorlagen gestalten, braucht die Funktion eine streng begrenzte eigene Ausdruckssprache und Isolation; eine allgemeine Produktions-Template-Engine ist dafür zu mächtig.

Wo findet man SSTI häufig?

Typische Stellen sind E-Mail-Vorschauen, Dokumentgeneratoren, frei anpassbare Benachrichtigungen und Anwendungen, die Templates über String-Verkettung zusammenbauen. Fehlermeldungen mit dem Namen der Template Engine erleichtern einen Angriff häufig.

SSTI oder Cross-Site Scripting?

Bei XSS interpretiert der Browser eine unsichere Ausgabe als aktiven Inhalt. Bei SSTI wertet der Server den eingeschleusten Ausdruck schon während des Renderings aus. Ein einfacher mathematischer Ausdruck kann deshalb zunächst nur eine veränderte Zahl in der Antwort erzeugen. Erreicht der Ausdruck aber Objekte, Funktionen oder Klassen der Laufzeit, sind Dateizugriff, interne Requests oder vollständige Codeausführung möglich.

Wie verläuft ein Test?

1. Eingaben identifizieren, die in E-Mails, PDFs, Vorschauen oder dynamischen Templates erscheinen.
2. Mit harmlosen, enginespezifischen Ausdrücken feststellen, ob der Server interpretiert statt nur ausgibt.
3. Engine und verfügbaren Kontext bestimmen, ohne Dateien oder Daten zu verändern.
4. Den Nachweis auf die kleinste Aussage zu Auswirkungen und erreichbaren Funktionen begrenzen.

Unterschiedliche Engines verwenden ähnliche Zeichenfolgen, interpretieren sie aber verschieden. Ein einzelner fehlgeschlagener Payload schließt SSTI daher nicht aus. Code-Review ist besonders aussagekräftig: Sobald Benutzereingaben Teil des Template-Quelltexts werden oder Funktionen wie „render from string“ erreichen, ist die Vertrauensgrenze falsch gesetzt.

Sichere benutzerdefinierte Templates

Muss ein Produkt anpassbare Vorlagen anbieten, sollte es eine bewusst begrenzte Sprache mit wenigen erlaubten Platzhaltern verwenden. Der Renderer läuft in einem isolierten Prozess ohne Geheimnisse, Dateisystemzugriff oder freie Netzwerkverbindungen. CPU-Zeit, Speicher und Ausgabegröße werden begrenzt. Eine Sandbox der allgemeinen Template Engine ist hilfreich, bleibt aber abhängig von Version und Konfiguration und sollte nicht die einzige Sicherheitsgrenze sein.