Server-Side Template Injection (SSTI): Komplettleitfaden 2025

Das versteckte Risiko in modernen Webanwendungen verstehen

Im Bereich der Webanwendungssicherheit stellt Server-Side Template Injection (SSTI) eine der kritischsten, aber oft übersehenen Schwachstellen dar. Wenn Angreifer die native Syntax einer Template verwenden und schädliche Payloads in Templates injizieren, wird das kompromittierte Template serverseitig ausgeführt, was Angreifern potenziell die vollständige Kontrolle über einen Zielserver ermöglicht. Diese Schwachstellenklasse ist in den letzten Monaten zunehmend verbreitet: Jede/r 16. Organisation ist wöchentlich von SSTI-Angriffen betroffen.

Was ist Server-Side Template Injection?

Template-Engines sind das Rückgrat der dynamischen Webseitengenerierung. Sie kombinieren feste Templates mit variablen Daten, um Webseiten zu erstellen. Beliebte Template-Engines sind Jinja2 (Python), Handlebars (JavaScript), Thymeleaf (Java), Twig (PHP) und viele andere. Diese leistungsstarken Werkzeuge trennen Präsentationslogik von Geschäftslogik, was die Entwicklung beschleunigt und den Code wartbarer macht.

Doch diese Macht hat ihren Preis. SSTI-Schwachstellen entstehen, wenn unsanitierte Benutzereingaben direkt an Template-Engines angehängt werden, was Angreifern ermöglicht, schädliche Template-Syntax zu injizieren, die serverseitig ausgewertet wird. Anstatt Benutzereingaben als reine Daten zu behandeln, verarbeitet die Anwendung sie als ausführbaren Template-Code – eine gefährliche Fehlbehandlung, die katastrophale Folgen haben kann.

Wie funktionieren Template-Engines?

Template-Engines generieren Webseiten, indem sie statische Templates mit dynamischen Daten zusammenfügen. Ein einfaches Beispiel:

<h1>Willkommen, {{ username }}!</h1>

In einer sicheren Implementierung wird die Variable username als Datenparameter übergeben und korrekt escaped. Wird jedoch Entwickler:innen erlaubt, Benutzereingaben direkt in den Template-String einzufügen, kann es gefährlich werden:

# Anfälliger Code
template = "Willkommen, " + user_input + "!"
render_template_string(template)

Dieses scheinbar harmlose Beispiel öffnet die Tür für Angreifer, Template-Ausdrücke zu injizieren, die die Engine ausführt.

Das Bedrohungsszenario: SSTI in 2024-2025

Hochkarätige Plattformen wie Atlassian Confluence, CrushFTP und Rejetto HTTP File Server wurden gezielt angegriffen und erfolgreich durch SSTI-Schwachstellen ausgenutzt. CISA hebt diese Vorfälle hervor, um ihre kritische Bedeutung zu unterstreichen. Neue Schwachstellen tauchen ständig auf, z.B. CVE-2024-56085 in Logpoint-Versionen vor 7.5.0, bei denen authentifizierte Nutzer Payloads beim Erstellen von Search Template Dashboards injizieren konnten.

Die Statistiken sind alarmierend: Während der letzten drei Monate war die Retail/Wholesale-Branche am stärksten betroffen, mit SSTI-Angriffen auf jede 11. Organisation pro Woche. Diese Anfälligkeit resultiert aus hohen Transaktionsvolumina, wertvollen Kundendaten und komplexen Drittanbieter-Integrationen.

Außerdem sind Cloud-basierte Organisationen etwa 30 % häufiger von SSTI-Angriffen betroffen als On-Premises-Organisationen, was auf Fehlkonfigurationen, Drittanbieter-Integrationen und Sicherheitslücken zwischen Cloud-Anbietern und Kunden zurückzuführen ist.

Beliebte Template-Engines und ihre Schwachstellen

Jinja2 (Python/Flask)

Jinja2 wird häufig in Python-Webframeworks, insbesondere Flask, eingesetzt. Ein klassisches Beispiel:

@app.route("/page")
def page():
    name = request.values.get('name')
    output = Jinja2.from_string('Hallo ' + name + '!').render()
    return output

Ein Angreifer könnte dies ausnutzen, indem er {{7*7}} als name-Parameter sendet, was zu 49 ausgewertet wird, anstatt den Text anzuzeigen. Dieses Muster zeigt sowohl XSS- als auch SSTI-Schwachstellen, da die Benutzereingabe direkt in das Template eingebettet wird, ohne ordnungsgemäß zu sanitieren.

Für Remote-Code-Ausführung können Angreifer Python-Objekt-Inspektion nutzen, um gefährliche Module zu erreichen:

{{ self._TemplateReference__context.cycler.__init__.__globals__.os }}

Dieses Payload navigiert durch die Python-Objekt-Hierarchie, um das os-Modul zu erreichen und Befehle auf dem Server auszuführen.

Handlebars (JavaScript/Node.js)

Handlebars ist eine beliebte, logiklose Template-Engine für JavaScript. Obwohl sie so konzipiert ist, dass sie sicherer ist, können Fehlkonfigurationen dennoch zu Schwachstellen führen. Angreifer:innen können Helper-Funktionen oder Prototyp-Pollution ausnutzen, um Code auszuführen.

Thymeleaf (Java/Spring)

Thymeleaf erfordert, dass Ausdrücke in bestimmten Attributen platziert werden, unterstützt aber Inline-Ausdrücke mit Syntax wie [[…]] oder [(…)], z.B. [[${7*7}]] für SSTI-Tests. Standardmäßig unterstützt Thymeleaf keine dynamische Template-Erstellung, da Templates vordefiniert sein müssen. Entwickler:innen müssen einen eigenen TemplateResolver implementieren, um Templates aus Strings on-the-fly zu generieren.

Wenn ausnutzbar, kann SSTI in Thymeleaf verheerend sein:

${T(java.lang.Runtime).getRuntime().exec('malicious_command')}

Twig (PHP)

Twig folgt ähnlicher Syntax wie Jinja2 und wird häufig in PHP-Anwendungen eingesetzt. Anfällige Implementierungen erlauben Angreifern, beliebigen PHP-Code auszuführen:

{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("id")}}

Warum ist SSTI gefährlicher als SQL-Injection?

Während SQL-Injection nach wie vor eine kritische Schwachstelle ist, stellt SSTI oft ein noch größeres Risiko dar. Hier die Gründe:

1. Direkter Serverzugriff

SQL-Injection beschränkt Angreifer:innen meist auf Datenbankoperationen – Lesen, Ändern oder Löschen von Daten. Bei schweren SSTI-Fällen können Angreifer:innen Code remote ausführen und den Backend-Server vollständig übernehmen, um weitere Angriffe auf die interne Infrastruktur zu starten. Dieser direkte Zugriff auf die Ausführungsumgebung des Servers ist mächtiger als Datenbankzugriffe allein.

2. Umgehung von Sicherheitskontrollen

SQL-Injection-Angriffe müssen mit Datenbankberechtigungen, gespeicherten Prozeduren und Sicherheitskontrollen kämpfen. SSTI läuft im Kontext der Webanwendung selbst, oft mit vollen Anwendungsrechten. Das bedeutet, Angreifer:innen erben alle Berechtigungen des Anwendungsprozesses.

3. Mehrstufige Angriffsplattform

Selbst wenn Angreifer:innen keinen Code remote ausführen können, können sie dennoch sensible Daten oder Dateien auf dem Server lesen, SSTI als Basis für weitere Angriffe nutzen. SQL-Injection erfordert meist Datenexfiltration über Datenbankkanäle, während SSTI direkten Zugriff auf das Dateisystem, Credential-Diebstahl aus Konfigurationsdateien und Pivoting ins interne Netzwerk ermöglicht.

4. Schwerer zu erkennen

Traditionelle Sicherheitswerkzeuge erkennen SQL-Injection-Muster gut. Bei SSTI ist das anders: Betriebssystem-Ereignisse werden von EDRs und CWPPs überwacht, aber die Ebene, auf der SSTI beginnt, liegt außerhalb ihrer Sichtweite. Bestehende WAF-Signatur-basierte Erkennungen sind meist handgefertigt für bekannte Payloads und Muster, die selten auf die Syntax verschiedener Template-Engines passen.

5. Komplexe Exploitationspfade

Sandboxing erschwert, aber verhindert Exploits kaum. Dokumentierte Fluchtwege nutzen Reflection-APIs oder Serialisierungsfehler, um die Isolierung zu durchbrechen. Moderne Exploitation-Tools generieren automatisch Hunderte von Payloads, um Verteidigungen zu überwinden, was SSTI-Angriffe immer ausgefeilter macht.

Szenarien realer Angriffe

Szenario 1: E-Greetings-Karten-Anwendung

Stellen Sie sich eine Webanwendung vor, die Nutzern erlaubt, personalisierte Grußkarten zu erstellen. Nutzer:innen geben ihre Nachricht ein, die in ein HTML-Template gerendert wird. Wenn die Anwendung Benutzereingaben direkt in den Template-String einfügt, könnte ein Angreifer injizieren:

{{config.items()}}

Dieses Payload würde alle Konfigurationsvariablen der Anwendung offenlegen, inklusive Datenbank-Zugangsdaten, API-Schlüssel und andere sensible Informationen.

Szenario 2: PDF-Rechnungs-Generierung

Generierte PDFs, Rechnungen und E-Mails verwenden meist Templates, was sie zu idealen Zielen für SSTI macht. Ein Angreifer könnte schädlichen Code in Rechnungsfelder injizieren, der beim serverseitigen Generieren des PDFs ausgeführt wird, was zu Remote-Code-Ausführung mit den Rechten des PDF-Generators führt.

Szenario 3: Marketing-E-Mail-Kampagnen

Da Template-Engines oft für transaktionale E-Mails genutzt werden, verschärfen Fehlkonfigurationen wie offene SMTP-Relays oder falsche MX-Einträge das Risiko. Angreifer:innen, die SSTI in E-Mail-Templates ausnutzen, können interne Nachrichten lesen, Kundendaten exfiltrieren oder Phishing-E-Mails über legitime Infrastruktur versenden.

Erkennung von SSTI-Schwachstellen

Erste Erkennung

Die Erkennung erfordert eine Kombination aus statischer Anwendungssicherheitstests, dynamischer Analyse und Laufzeitüberwachung, um Schwachstellen vor der Produktion zu erkennen.

Der häufigste Ansatz ist Fuzzing mit polyglotten Payloads:

${{c%[%'"}}%\

In den meisten Fällen löst dieses polyglotte Payload einen Fehler bei einer SSTI-Schwachstelle aus. Die Hackmanit Template Injection Table bietet eine interaktive Referenz mit effizienten Template-Injection-Polyglots für 44 große Template-Engines.

Mathematische Ausdruckstests

Ein einfacher erster Test ist die Injection mathematischer Ausdrücke:

{{7*7}}
${7*7}
<%= 7*7 %>
${{7*7}}
#{7*7}

Wenn der Server 49 zurückgibt statt des Literal-Ausdrucks, ist die Template-Injection bestätigt.

Identifikation der Template-Engine

Nach Bestätigung der Injection identifizieren Angreifer:innen die spezifische Template-Engine durch Tests verschiedener Syntaxmuster:

Jinja2/Twig: {{7*7}} ergibt 49
Smarty: {7*7} ergibt 49
Thymeleaf: [[${7*7}]] ergibt 49
FreeMarker: ${7*7} ergibt 49
Velocity: #set($x=7*7)$x ergibt 49

Verschiedene Template-Engines haben unterschiedliche Syntax, Funktionen und Exploit-Potenziale, was diese Schritt zur Identifikation essenziell macht.

Fortgeschrittene Exploitationstechniken

Ausbruch aus Sandboxes

Viele Template-Engines implementieren Sandboxing, um gefährliche Operationen zu beschränken. Angreifer:innen haben jedoch ausgeklügelte Techniken entwickelt, um diese Beschränkungen zu umgehen.

In Jinja2 können Angreifer:innen beispielsweise Python-Objekt-Hierarchien durchqueren, um eingeschränkte Module zu erreichen:

{{''.__class__.__mro__[1].__subclasses__()}}

Dieses Payload listet alle Python-Klassen auf, sodass Angreifer:innen Klassen mit gefährlichen Methoden wie os.system() oder subprocess.Popen() finden können.

Lesen sensibler Dateien

Angreifer:innen können beliebige Dateien vom Server lesen:

{{''.__class__.__mro__[1].__subclasses__()[40]('/etc/passwd').read()}}

Remote-Code-Ausführung

Befehlsausführung ermöglicht Persistenz und laterale Bewegungen, z.B. durch Schreiben von SSH-Schlüsseln in authorized_keys, Planen von Cron-Jobs oder Deployen von Webshells in beschreibbaren Verzeichnissen.

Beispiele für RCE-Payloads:

Jinja2:

{{config.__class__.__init__.__globals__['os'].popen('whoami').read()}}

Thymeleaf:

__${T(java.lang.Runtime).getRuntime().exec("touch /tmp/pwned")}__::.x

Ruby ERB:

<%= system('whoami') %>

Automatisierte Exploitation-Tools

Tools wie Tplmap wählen automatisch passende Payloads, handhaben Kodierungsanforderungen und liefern Shells in Sekunden. KI-gesteuerte Frameworks können Hunderte von einzigartigen SSTI-Payloads generieren, um Signatur-basierte Abwehrmaßnahmen zu überwinden.

Beliebte Tools sind: - Tplmap: Automatische SSTI-Erkennung und -Ausnutzung - SSTImap: Interaktiver SSTI-Scanner mit Multi-Engine-Unterstützung - Tinja: Effiziente SSTI-Erkennung mit neuartigen Polyglots

Prävention und Abwehrmaßnahmen

1. Niemals Benutzereingaben konkatenieren

Die goldene Regel: Benutzereingaben niemals direkt in Template-Strings einfügen. Stattdessen Daten als Parameter übergeben:

Anfällig:

template = "Hallo " + user_input + "!"
render_template_string(template)

Sicher:

render_template('hello.html', username=user_input)

Durch Verwendung von render_template mit vordefinierten Templates übergibt Flask den Variablennamen an das Template, das automatisch escaped wird, was es vor Injection-Angriffen schützt.

2. Logiklose Template-Engines verwenden

Drei Schutzmaßnahmen: Validieren Sie alle Eingaben, wechseln Sie zu logiklosen oder sandboxed Templates und halten Sie Template-Engines aktuell. Logiklose Engines wie Mustache oder Handlebars (bei richtiger Konfiguration) minimieren die Angriffsfläche, indem sie ausführbare Logik einschränken.

3. Eingabekontrolle implementieren

Static Application Security Testing (SAST) ist die erste Verteidigungslinie. Konfigurieren Sie es so, dass Funktionen erkannt werden, die Templates mit untrusted input bauen oder gefährliche Render-Helper aufrufen. Musterregeln, die render_template_string(request.*) in Flask oder String-Konkatenation in Template-Renderings erkennen, fangen die meisten Probleme.

4. Content Security Policy

Implementieren Sie strenge Content Security Policies (CSP), um die Ausführung schädlicher Skripte zu verhindern. Das erhöht die Sicherheit, selbst wenn SSTI-Schwachstellen bestehen.

5. Web Application Firewalls

Setzen Sie WAFs mit SSTI-spezifischen Regeln ein, um Template-Syntaxmuster wie {{...}}, ${...} oder <%...%> in Benutzereingaben zu erkennen. Beachten Sie jedoch, dass Angreifer:innen WAF-Regeln mit kleinen Änderungen bei Variablennamen, Leerzeichen oder Kodierung umgehen können.

6. Laufzeit-Application Self-Protection

Moderne Sicherheitslösungen überwachen die Ausführung beim Rendern der Templates, erkennen bösartiges Verhalten am Ursprung und verhindern es, noch bevor es sich ausbreitet. Das bietet Zero-Day-Schutz, da die Erkennung auf Laufzeitverhalten basiert.

7. Prinzip der minimalen Rechte

Führen Sie Template-Render-Prozesse mit minimalen notwendigen Rechten aus. Bei Ausnutzung einer SSTI-Schwachstelle reduziert dies die potenziellen Schäden.

8. Regelmäßige Sicherheitsüberprüfungen

Entwickler:innen überspringen oft den Abschnitt “Sicherheitsüberlegungen” in der Template-Engine-Dokumentation, der nützliche Sicherheitshinweise enthalten kann. Regelmäßige Code-Reviews, die sich auf Template-Nutzung konzentrieren, helfen, Schwachstellen frühzeitig zu erkennen.

Häufige Schwachstellenmuster vermeiden

Muster 1: Benutzerkontrollierte Template-Auswahl

# Gefährlich
template_name = request.args.get('template')
return render_template(template_name)

Muster 2: Dynamische Template-Erzeugung

// Gefährlich
String template = "Hallo " + userInput;
templateEngine.process(template, context);

Muster 3: Debug-Endpunkte in Produktion

Debug- und Vorschau-Endpunkte sind häufige Angriffsvektoren, da sie auf Wunsch beliebige Templates kompilieren und so Angreifern den Zugriff auf das System erleichtern.

Muster 4: Eingebettete Geschäftslogik

Geschäftslogik direkt in Templates zu integrieren, beschleunigt die Entwicklung, erhöht aber auch das Risiko. Jede zusätzliche Fähigkeit – wie Daten-Schleifen, Berechnungen oder API-Aufrufe – bietet Cyberkriminellen mehr Möglichkeiten, die Template-Ausführung zu manipulieren und Systemressourcen zu nutzen.

Geschäftliche Auswirkungen und Risikobewertung

Das unmittelbare Risiko umfasst Credential-Diebstahl, Datenexfiltration und den Ausfall kritischer Dienste. Organisationen sind betroffen von:

Finanziellen Verlusten durch Datenpannen und Ausfallzeiten
Regulatorischen Strafen nach GDPR, CCPA und anderen Datenschutzgesetzen
Reputationsschäden durch Sicherheitsvorfälle
Rechtlicher Haftung bei Kundendatenverletzungen
Betrieblichen Störungen während Incident-Response und Behebung

Der Retail/Wholesale-Sektor ist besonders anfällig, da hier hohe Transaktionsvolumina mit wertvollen Kundendaten wie persönlichen Informationen und Zahlungsdetails vorliegen, die Hacker:innen attraktiv finden.

SSTI in der Entwicklungsphase testen

Code-Review-Checkliste

✅ Werden alle Template-Render-Funktionen mit Parametern aufgerufen?
✅ Werden Benutzereingaben jemals in Templates direkt konkatenisiert?
✅ Sind Debug-Template-Endpunkte in Produktion deaktiviert?
✅ Haben Templates Zugriff auf sensible Funktionen oder Module?
✅ Wird die Eingabe vor dem Rendern validiert?

Automatisierte Tests

Integrieren Sie SSTI-Erkennung in CI/CD-Pipelines:

# Beispiel mit SSTImap
python3 sstimap.py -u 'https://example.com/page?name=test' --level 5

Manuelle Testmethoden

Das Vorgehen bei SSTI ähnelt anderen Injection-Angriffen: Eingabepunkte identifizieren, fuzzing durchführen und Ergebnisse prüfen:

Eingabefelder in Serverantworten erkennen
Polyglotte Payloads oder mathematische Ausdrücke injizieren
Serververhalten beobachten (Fehler, Auswertung, Verzögerungen)
Template-Engine identifizieren
Exploitations-Payloads erstellen
Ergebnisse dokumentieren und melden

Branchenstandards und Compliance

SSTI-Schwachstellen fallen unter verschiedene Compliance-Rahmen:

OWASP Top 10 2021: Kategorie A03 (Injection)
CWE-1336: Unsachgemäße Neutralisierung spezieller Elemente in Template-Engines
NIST: Sichere Programmierpraktiken und Eingabekontrolle
PCI DSS: Anforderung 6.5.1 (Injection-Schwachstellen)

Fazit: Die zunehmende Bedrohung durch SSTI

Server-Side Template Injection ist eine kritische Schwachstellenklasse, die die Macht der Code-Ausführung mit der Tarnung legitimer Template-Verarbeitung verbindet. Die Tests auf serverseitige Template-Injections im Jahr 2025 bleiben essenziell, da Entwickler:innen weiterhin Schwierigkeiten haben, Benutzereingaben ausreichend zu validieren.

Das wichtigste Fazit: Template-Engines sind mächtige Werkzeuge, die mit äußerster Vorsicht behandelt werden müssen. Benutzereingaben sollten niemals als Template-Code behandelt werden. Durch sichere Programmierpraktiken, Defense-in-Depth-Strategien und regelmäßige Sicherheitstests können Organisationen sich vor diesem verheerenden Angriffsschutz schützen.

Die Behebung von SSTI-Schwachstellen ist eine zentrale Priorität für Organisationen, die Webanwendungen entwickeln und warten, insbesondere wegen der weiten Verbreitung von Template-Engines und der häufigen Notwendigkeit, dynamische Inhalte basierend auf Benutzereingaben zu generieren. Die Risiken sind hoch, aber mit Bewusstsein und Best Practices im Sicherheitsbereich lassen sich SSTI-Schwachstellen effektiv verhindern und mindern.

Weitere Ressourcen

OWASP Web Security Testing Guide: Server-Side Template Injection
PortSwigger Web Security Academy: SSTI Tutorials
PayloadsAllTheThings: Umfangreiche SSTI-Payload-Datenbank
Hackmanit Template Injection Table: Interaktive Referenz für 44 Template-Engines
James Kettle’s Whitepaper: “Server-Side Template Injection: RCE for the Modern Web App”

Bleiben Sie sicher, validieren Sie Eingaben und denken Sie daran: Ihre Template-Engine ist ein mächtiges Werkzeug – geben Sie Angreifern nicht die Schlüssel zum Königreich durch unvalidierte Benutzereingaben.