Server-Side Template Injection (SSTI) is an attack that allows an attacker to inject malicious input into a templating engine, leading to code execution on the server. While this vulnerability can be quite impactful, understanding and exploiting it requires a good understanding of templating engines and how they work.
What is Server-Side Template Injection?
Template engines are often used in web applications to generate dynamic HTML responses. They allow us to embed variables within HTML templates, which get filled in with real values when the page is rendered. SSTI occurs when an attacker can control some or all of these template variables, potentially leading to code execution on the server.
A Simple SSTI Scenario:
- Imagine a web application that allows users to send customized e-greeting cards. The message from one user to another might be “Happy Birthday {{username}}!” where “username” is a variable taken from user input.
- An attacker uses the payload “{{4 * 4}}” and, instead of seeing the input rendered as text, they see “16” on the e-greeting card. This indicates that the server is evaluating the input using a template engine.
- The attacker can now try to exploit this behavior further by using the templating syntax to make the server reveal more information or execute commands
There are many reported cases of SSTI similar to this simple scenario, such as this SSTI in rider.uber.com.
Common Payloads for SSTI:
First, we can use basic evaluations: As demonstrated above, try maths calculations like:
* `{{4*4}}`
* `{{7+3}}`
Second we can try to retrieve application classes or objects:
* `{{ ”.__class__ }}`
* `{{ ”.__class__.__mro__ }}`
We can also look to read Files from the server:
* `{{ ‘/etc/passwd’ | read }}`
* `{{ ‘file:///etc/passwd’ | urlize }}`
And finally, often we can execute system commands:
* `{{ ‘ls’ | shell_exec }}`
* `{{ ‘id’ | system }}`
The syntax of these can vary depending on the templating engine in use, and part of exploiting SSTI will verifying this. For a list of other potential payoloads to explore, the PayloadsAllTheThings repository is worth exploring.
Detecting Server-Side Template Injection
The approach to detecting SSTI is similar to other injection attacks. We need to find points of input, fuzz, and then review the results. Below are the high level steps to acieve this.
- Identify potential points of input: We begin by identifying where user input is being reflected in the server’s response. For example, this could be search boxes, URL parameters, form fields, etc.
- Fuzz with teamplting syntax: Use common template syntax or characters for input, such as `{{` or `{%%}`. If the server responds differently to these inputs (either with an error, by executing the template command, or by reflecting the input differently), it may be vulnerable. It’s crutial here to pay attention to the application behaviour.
- Test built-in functions: Many template engines provide built-in functions or filters. For example, injecting `{{ ‘test’ | length }}` might return `4` if the server is evaluating it as a template.
- Stay on the lookout for error messages: A server error after inputting template syntax might indicate an improper handling of user input and a potential SSTI vulnerability. However, not all errors mean the application is vulnerable, and not all SSTI vulnerabilities will produce errors so ensure you verify your findings.
- Deplayed responses: Just line in blind sqli attacks, some SSTI payloads can cause deliberate delays. If the server’s response is delayed after sending such a payload, this is a good indicator of vulnerability.
Wrapping up
Server-Side Template Injection can be a high-severity vulnerability, potentially leading to full server compromise. However, exploiting it requires a nuanced understanding of different template engines and their quirks. Whether you’re a developer or a pentester, understanding SSTI is essential. Developers must be aware of this vulnerability to prevent it, while pentesters should know how to detect and exploit it to ensure the applications they test are secure.