SSTI (Server Side Template Injection)
Last updated
Last updated
https://miro.medium.com/v2/resize:fit:640/format:webp/1*3RO051EgizbEer-mdHD8Kg.jpeLerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
RootedCON ist die relevanteste Cybersecurity-Veranstaltung in Spanien und eine der wichtigsten in Europa. Mit der Mission, technisches Wissen zu fördern, ist dieser Kongress ein brodelnder Treffpunkt für Technologie- und Cybersecurity-Profis in jeder Disziplin.
Server-Side Template Injection ist eine Schwachstelle, die auftritt, wenn ein Angreifer schädlichen Code in eine Vorlage injizieren kann, die auf dem Server ausgeführt wird. Diese Schwachstelle kann in verschiedenen Technologien gefunden werden, einschließlich Jinja.
Jinja ist eine beliebte Template-Engine, die in Webanwendungen verwendet wird. Lassen Sie uns ein Beispiel betrachten, das einen anfälligen Code-Snippet mit Jinja demonstriert:
In diesem anfälligen Code wird der name
-Parameter aus der Benutzeranfrage direkt mit der render
-Funktion in die Vorlage eingefügt. Dies kann einem Angreifer potenziell ermöglichen, schädlichen Code in den name
-Parameter einzufügen, was zu einer Server-seitigen Template-Injection führt.
Zum Beispiel könnte ein Angreifer eine Anfrage mit einem Payload wie diesem erstellen:
Der Payload {{bad-stuff-here}}
wird in den Parameter name
injiziert. Dieser Payload kann Jinja-Template-Direktiven enthalten, die es dem Angreifer ermöglichen, unbefugten Code auszuführen oder die Template-Engine zu manipulieren, wodurch potenziell die Kontrolle über den Server erlangt wird.
Um Server-seitige Template-Injection-Schwachstellen zu verhindern, sollten Entwickler sicherstellen, dass Benutzereingaben ordnungsgemäß bereinigt und validiert werden, bevor sie in Templates eingefügt werden. Die Implementierung von Eingabevalidierung und die Verwendung kontextsensitiver Escape-Techniken können helfen, das Risiko dieser Schwachstelle zu mindern.
Um Server-Side Template Injection (SSTI) zu erkennen, ist zunächst Fuzzing des Templates ein einfacher Ansatz. Dies beinhaltet das Injizieren einer Sequenz von Sonderzeichen (${{<%[%'"}}%\
) in das Template und das Analysieren der Unterschiede in der Serverantwort auf reguläre Daten im Vergleich zu diesem speziellen Payload. Anzeichen für Schwachstellen sind:
Ausgelöste Fehler, die die Schwachstelle und potenziell die Template-Engine offenbaren.
Abwesenheit des Payloads in der Reflexion oder Teile davon fehlen, was darauf hindeutet, dass der Server ihn anders verarbeitet als reguläre Daten.
Plaintext-Kontext: Unterscheidung von XSS, indem überprüft wird, ob der Server Template-Ausdrücke auswertet (z. B. {{7*7}}
, ${7*7}
).
Code-Kontext: Bestätigung der Schwachstelle durch Ändern der Eingabeparameter. Zum Beispiel, indem greeting
in http://vulnerable-website.com/?greeting=data.username
geändert wird, um zu sehen, ob die Serverausgabe dynamisch oder fest ist, wie in greeting=data.username}}hello
, das den Benutzernamen zurückgibt.
Die Identifizierung der Template-Engine erfolgt durch die Analyse von Fehlermeldungen oder manuelles Testen verschiedener sprachspezifischer Payloads. Häufige Payloads, die Fehler verursachen, sind ${7/0}
, {{7/0}}
und <%= 7/0 %>
. Die Beobachtung der Serverantwort auf mathematische Operationen hilft, die spezifische Template-Engine zu bestimmen.
Weitere Informationen unter https://medium.com/@0xAwali/template-engines-injection-101-4f2fe59e5756
ein effizienter SSTI + CSTI-Scanner, der neuartige Polyglots nutzt.
eine interaktive Tabelle, die die effizientesten Template-Injection-Polyglots sowie die erwarteten Antworten der 44 wichtigsten Template-Engines enthält.
In dieser Wortliste finden Sie definierte Variablen in den Umgebungen einiger der unten genannten Engines:
Java - Grundlegende Injection
Java - Abrufen der Umgebungsvariablen des Systems
Java - Abrufen von /etc/passwd
Sie können Ihre Payloads unter https://try.freemarker.apache.org ausprobieren.
{{7*7}} = {{7*7}}
${7*7} = 49
#{7*7} = 49 -- (legacy)
${7*'7'} Nichts
${foobar}
Freemarker - Sandbox-Umgehung
⚠️ funktioniert nur mit Freemarker-Versionen unter 2.3.30
Mehr Informationen
Im FreeMarker-Bereich von https://portswigger.net/research/server-side-template-injection
Mehr Informationen
Im Velocity-Bereich von https://portswigger.net/research/server-side-template-injection
In Thymeleaf ist ein häufiger Test für SSTI-Schwachstellen der Ausdruck ${7*7}
, der auch für diese Template-Engine gilt. Für potenzielle Remote-Code-Ausführung können Ausdrücke wie die folgenden verwendet werden:
SpringEL:
OGNL:
Thymeleaf erfordert, dass diese Ausdrücke innerhalb spezifischer Attribute platziert werden. Allerdings wird expression inlining für andere Template-Standorte unterstützt, unter Verwendung von Syntax wie [[...]]
oder [(...)]
. Daher könnte eine einfache SSTI-Testpayload wie [[${7*7}]]
aussehen.
Die Wahrscheinlichkeit, dass diese Payload funktioniert, ist jedoch im Allgemeinen gering. Die Standardkonfiguration von Thymeleaf unterstützt keine dynamische Template-Generierung; Templates müssen vordefiniert sein. Entwickler müssten ihren eigenen TemplateResolver
implementieren, um Templates aus Strings zur Laufzeit zu erstellen, was ungewöhnlich ist.
Thymeleaf bietet auch expression preprocessing, bei dem Ausdrücke innerhalb doppelter Unterstriche (__...__
) vorverarbeitet werden. Diese Funktion kann beim Aufbau von Ausdrücken genutzt werden, wie in der Dokumentation von Thymeleaf demonstriert: