flawopen.com/SSTI/Erklärt
Was ist serverseitige Template-Injection?
Serverseitige Template-Injection entsteht, wenn nicht vertrauenswürdige Eingaben als Template-Quelltext statt als Daten interpretiert werden. Die Auswirkungen hängen von Engine, Konfiguration und zugänglichen Funktionen ab: von der Auswertung eines Ausdrucks bis zur Codeausführung auf dem Server. Nicht jeder SSTI-Fall ermöglicht Codeausführung.
# Python / Jinja2 template = f"Hello {name}!" return render_template_string(template) # Input: {{ 7*7 }} renders as "49" # This confirms expression evaluation; # impact still depends on engine access. // Java / Freemarker String tpl = "Welcome " + userName; new Template("t", tpl, cfg) .process(model, out);
# The template is a fixed string the # developer wrote. The user value is # passed in as a variable. return render_template( "greeting.html", name=name ) # Or with a literal template string: return render_template_string( "Hello {{ name }}!", name=name ) // Java equivalent: template from file, // user value in the model map.
Der entscheidende Unterschied
Jede Template-Engine erhält zwei Eingaben: das Template und Kontextdaten. Das Template ist ein Programm; die Daten sind Werte, die dieses Programm liest. SSTI entsteht, wenn Benutzereingaben aus der Datenebene in den Template-Quelltext gelangen.
Das ist derselbe strukturelle Fehler wie bei SQL-Injection, bei der Daten an Abfragetext angehängt werden, und wie bei Log4Shell, bei dem Daten über eine Lognachricht einen Ausdrucksauswerter erreichten. Die Abhilfe folgt demselben Prinzip: Das Programm bleibt fest; nicht vertrauenswürdige Werte werden über einen Parameterkanal übergeben.
Wann die Auswirkungen Codeausführung einschließen können
Wenn eine Engine leistungsfähige Objekte oder Methoden im Template verfügbar macht, kann ein Angreifer möglicherweise sensible Anwendungsmöglichkeiten erreichen. Ob daraus Codeausführung folgt, hängt von Engine, Version, Konfiguration, Sandbox und Datenmodell ab. Weitere Folgen sind Datenoffenlegung oder Ressourcenerschöpfung. Behandeln Sie benutzerkontrollierten Template-Quelltext als aktive Logik; verlassen Sie sich nicht allein auf eine Sandbox, ohne zugängliche Objekte und Renderressourcen zu begrenzen.
Erkennung
{{7*7}}
${7*7}
<%= 7*7 %>
#{7*7}
Enthält die Antwort 49 statt des wörtlichen Texts, wird die Eingabe als Template-Syntax ausgewertet. Solche kurzen Rechenausdrücke helfen bei der Erkennung in einer autorisierten Testumgebung; die Syntax unterscheidet sich je nach Engine und identifiziert sie allein nicht zuverlässig.
Häufige Fragen
Nein. Clientseitige Template-Injection läuft im Browser des Opfers und kann eine XSS-Variante sein. SSTI wird serverseitig im Anwendungsprozess ausgewertet. Die Auswirkungen hängen von Engine und verfügbaren Funktionen ab; manche Konfigurationen ermöglichen serverseitige Codeausführung, aber nicht automatisch jeder SSTI-Fall.
Nein. Auto-Escaping bereinigt ausgegebene Werte; es verhindert nicht, dass ein Wert zunächst als Template-Syntax geparst wird. Es schützt vor XSS in der Ausgabe, nicht vor Injection in den Template-Quelltext.
Behandeln Sie vom Nutzer gelieferte Template-Quellen als ausführbare Logik und verarbeiten Sie sie standardmäßig nicht im Hauptkontext der Anwendung. Falls die Funktion nötig ist, verwenden Sie eine Engine für eingeschränkte Templates, geben Sie nur minimale inerte Daten frei und begrenzen Sie CPU, Speicher, Ausgabegröße und Laufzeit. Eine Sandbox kann den Zugriff einschränken, ist allein aber keine vollständige Sicherheitsgrenze.
Quellen
- CWE-1336 — Improper Neutralization of Special Elements Used in a Template Engine
- PortSwigger Web Security Academy — server-side template injection
- OWASP Testing Guide — testing for SSTI
- Is Jinja2's render_template_string() safe?
- Are Freemarker and Velocity templates safe with user input?
- Jinja documentation — Sandbox security considerations