TINJA Template Injection Analyzer Banner
TINJA Template Injection Analyzer Banner

Many web applications make use of template engines to employ the MVC (Model-View-Controller) pattern. While web developers benefit greatly from their powerful features and simplicity, it is essential to focus on their security. An insecure configuration can result in template injection vulnerabilities causing severe risks for the web application, its data, and its users.


What are Template Engines?

Template engines allow static template files or strings containing template language to be used in web applications. The function of a template engine is to dynamically interpret the template language at runtime and generate an output format, such as HTML, from the template. Single instructions to a template engine are called template expressions; these expressions usually consist of an opening tag, a statement, and a closing tag, for example:


    {{             7*7            }}
opening tag     statement     closing tag


The template engine recognizes the beginning and ending of a statement based on these tags. The processing flow of a template engine is depicted in Figure 1. The template engine interprets a template containing template statements and combines it with a data model, such as a relational database or other data source.
Many web frameworks that simplify the programming of dynamic web applications by default use a third-party template engine or even provide a custom template engine. In addition, template engines can often be integrated easily into an existing project. As a result, template engines are widely used in web applications. For example, the top seven Python template engines have been downloaded more than 5.4 billion times combined [1].

Processing flow of a template engine TINJA Hackmanit

Template Engine – Example of the processing flow. (Figure 1)


Template engines can be used on either the client or server side, as shown in Figure 2. A client-side template engine is included in the web page using a <script>-tag. Therefore, only JavaScript template engines can be used on the client side. The browser executes the script after receiving the HTTP response, and the template expressions are interpreted. A server-side template engine is executed directly on the server. This means that the template expressions are interpreted before the HTTP response is sent to the client.


Template engines executed on the client or server side TINJA Hackmanit

Template Engines – Executed on the client or server side. (Figure 2)



What is a Template Injection Attack?

It is dangerous to insert untrusted and unchecked user input into a template. In this case, attackers can inject malicious template expressions. The impact of such an attack, called “template injection”, depends on whether a client-side or server-side template engine is used. With client-side template injection (CSTI), arbitrary JavaScript can be executed in the victim's browser—this is called cross-site scripting (XSS). Server-side template injection (SSTI) is even more serious because, in addition to XSS, it can also be used to execute code on the server—remote code execution (RCE)—or to read and write arbitrary files on the server’s filesystem.

How such template injection payloads look depends on the template engine in use, its implementation, and its specific configuration. For example, in the Ruby template engine “ERB”, code can be executed on the server by using a very simple template expression, such as:

<%= system("whoami") %>

However, with the “Jinja2” template engine for Python, this is not as simple as just calling a specific method. Instead, various objects have to be accessed before methods of the Python module "os" can be called. An example of such a template expression is: 

{{ self._TemplateReference__context.cycler.__init__.__globals__.os.
popen("whoami").read() }}



How to Detect and Exploit a Template Injection Vulnerability?

Kettle has established a template injection methodology that can be used to detect and exploit template injection vulnerabilities [2]. It consists of three main steps: Detect, Identify, and Exploit.

  1.  Detect:
    The first step is to find out if template injection is possible, in other words, if unsafe user input is being inserted into a template. To do this, it is helpful to use special template expressions that can be interpreted by as many template engines as possible in order to reduce the amount of necessary requests. These expressions are called “polyglots”. For this step, we developed universal polyglots, which are interpreted by more than 40 of the most popular template engines for various programming languages. You can find these polyglots in our Template Injection Table, which is part of Hackmanit’s cheat sheet series. More details about the table can be found in the next section of this blogpost.

  2. Identify:
    Once the possibility of a template injection has been detected, the next step is to verify it and identify which template engine is used for processing the template. For example, {{7*'7'}} is interpreted as 7777777 by some template engines and as 49 by others. Again, our Template Injection Table can be utilized for this step. It allows the use of polyglots in an iterative manner and the filtering of possible template engines based on the response to each polyglot. This process can be iterated until only one possible template engine is left.

  3. Exploit:
    After identifying the template engine in use, the next step is to exploit the template injection vulnerability. Nowadays, there are many cheat sheets that show possible template injection payloads for different template engines (see Hacktricks and PayloadsAllTheThings).



Is There a More Efficient Way to Do This?

In order to detect template injection possibilities and identify template engines as efficiently as possible, we have created polyglots based on the 44 most relevant template engines. These are published in an interactive table together with the responses of the various template engines examined—our free-to-use Template Injection Table

Four polyglots are particularly noteworthy: the "error" polyglot  <%'${{/#{@}}%>{{  is the only polyglot we know that produces an error message for all 44 template engines examined. It is also quite concise at 16 characters. However, there is a possibility that errors will be caught by the web application in question, rendering error polyglots useless.
The three "non-error" polyglots p  ">[[${{1}}]], <%=1%>@*#{1},  and {##}/*{{.}}*/ are constructed in such a way that at least one of them does not throw an error, but renders the polyglot modified for all template engines we examined.

Altogether, these four polyglots can detect template injection possibilities for the 44 template engines examined. Furthermore, additional polyglots can be found in the interactive Template Injection Table and filtered according to the possible responses to quickly and efficiently identify a template engine. 
This greatly accelerates the first two steps of the methodology.

We also released the open-source Template INjection Analyzer “TInjA”, which uses the novel polyglots to scan for template injection possibilities. Due to its features, TInjA is perfectly suited for scanning single URLs, as well as for large-scale scans. Figure 3 shows an example of TInjA's output. More information about the features and usage of TInjA can be found in its public Github repository.

TINJA Template Injection Example Output Hackmanit

TInjA – Example output. (Figure 3)



Template injection vulnerabilities can have severe consequences. Therefore, untrusted user input must not be inserted into a template. The first two steps of the template injection methodology can be used to detect template injection possibilities and identify the template engine in use. These two steps can now be performed even more efficiently thanks to the polyglots we have created. The Template Injection Table can be used for the manual procedure, and the novel scanner TInjA can be used for automated scanning. To get familiar with template injection possibilities, the polyglots, and TInjA, we have published the Template Injection Playground, which allows you to play around with more than 40 template engines.



[1] M. Hildebrand. Improving the Detection and Identification of Template Engines for Large-Scale Template Injection Scanning. 2023. URL: https://www.hackmanit.de/images/download/thesis/Improving-the-Detection-and-Identification-of-Template-Engines-for-Large-Scale-Template-Injection-Scanning-Maximilian-Hildebrand-Master-Thesis-Hackmanit.pdf.

[2] J. Kettle. Server-Side Template Injection: RCE for the modern webapp. Black Hat USA, 2015. URL: https://www.blackhat.com/docs/us-15/materials/us-15-Kettle-Server-Side-Template-Injection-RCE-For-The-Modern-Web-App-wp.pdf



Our Experts Develop the Optimal Solution for You

Template Injection – Cross-Site Scripting (XXS) – Web Security

Are you using template engines in your web application and want to make sure they are used in a secure way? Or do you want to ensure your application's users and data is protected against other threats?

We will be glad to advise you; contact us for a no-obligation initial consultation. Thus, we are at your side with the following services and solutions:

IT Security Consulting  |  Training   |  Penetration Tests

Don't hesitate and find your way to secure web applications with us. We look forward to supporting you with your projects.


Your Contact for Web Security

Prof. Dr. Marcus Niemietz