Server-Side Template Injection

Tram Ho

1. What is server-side template injection?

  • Template engines (tools that help us split HTML code into smaller parts that we can reuse on many HTML files) are widely used by web applications to present data through web pages. and emails. Embedding user input in an insecure manner into templates leads to Server-Side Template Injection – a critical vulnerability often easily confused with Cross-Site Scripting (XSS), or completely ignored.
  • Unlike XSS, Template Injection can be used to attack directly inside web servers and often includes Remote Code Execution (RCE) – remote code execution, turning any vulnerable application into attacks. potential pivot point Template Injection can arise not only through developer-side errors, but also through purposeful behavior of the template to try to provide rich functionality – often done by wikis, blogs, Marketing applications and content management systems.

2. When does server-side template injection occur?

  • Server-side template injection occurs when content that is entered by the user is insecurely embedded into the server-side template, allowing the user to inject the template directly. By using malicious templates, an attacker can execute arbitrary code and take full control of the web server. The severity of this problem varies depending on the type of template engines used. Template engines can range from easy to almost impossible to exploit.
  • Consider the following example:
    • A marketing application sends out a series of emails, and uses the Twig template to send greetings to customers. If only the username was passed to the template as in the following example, everything would work fine:
      $output = $twig->render("Dear {first_name},", array("first_name" => $user.first_name) );
    • However, if users are allowed to customize these emails, the problem will arise:
      $output = $twig->render($_GET['custom_email'], array("first_name" => $user.first_name) );
    • In this case, the user controls the content of the template via the GET customemail parameter, instead of the value passed to it. This leads to an XSS vulnerability. However, XSS is only a manifestation of a more sophisticated and serious error. This code shows a wide range of surface attacks that are easily overlooked.
    • The output from the following 2 messages shows the server-side vulnerability:

  • This vulnerability is often caused by the intentional developers allowing users to submit or edit templates. Moreover, unintentional injection templates are extremely easy to miss because there is usually no visible sign.
  • Template injection vulnerabilities can be very serious and harm the entire functionality or data of the application. It is also possible that it uses the server as a platform for subsequent attacks on other systems. In addition, some template injection vulnerabilities may not pose significant security risks.

3. Process of an attack


This vulnerability can appear in two separate contexts, each requiring its own detection method.

  1. Plaintext context
  • The error will usually appear by one of the following methods:

  • To detect the error, we need to call the template engine by embedding a command. There are a large number of template languages ​​but most of them share basic syntax characteristics. We can take advantage of this by sending payloads using basic operators to detect multiple template engines with a single HTTP request.

  1. Code context
  • User input can also be placed in a template statement, usually the variable name

  • This variable is even easier to overlook during the evaluation process, since it does not explicitly lead to XSS. Changing the username value will usually return an empty result or cause an application error. This situation can be detected by verifying the parameters that cannot be XSS directly, then exiting the template statement and adding the HTML tag after it:


  • After discovering template injection, the next step is to determine which template engine is being used. The green and red arrows, respectively, respond to ‘success’ and ‘failure’. In some cases, a payload can have many different successful responses
  • for example, testing with input {{7 * ‘7’}} will result
    • 49 in Twig
    • 7777777 in Jinja2
    • Returns nothing if no template engine is used.


  1. Read

After defining the template engine, read the related document. The main areas of interest are:

  • Basic syntax of template engine
  • List of methods, functions, filters and variables built in
  • List of extensions / plugins
  1. Explore

At this stage, what we need to do is find out exactly what is accessible.

  • Consider both the default objects provided by the template engine and application-specific objects passed into the template by the developers.
  • Bruteforce the variable names. Objects provided by the developer may contain sensitive information.
  1. Attack

Look through each function to find exploitable vulnerabilities. Types of attacks can include creating arbitrary objects, reading / writing arbitrary files (including remote files), or exploiting privilege escalation vulnerabilities.

4. Example of Server-Side Template Injection

  • This function uses ajax in jquery to send data from the client to the server:
    • url: serviceUrl (send data to url: / web-serveur / ch41 / check)
    • type: “POST” (using the POST method)
    • data: postData (the data to be sent is in the postData variable)
  • If the request is successful, it will return the data in “data” and fill in the div tag with id “result”, otherwise it will return an error message “An error occurs!”.
  • First, it is necessary to determine the type of template engine used:

=> If the error message as the picture, guess the engine used may be FreeMarker

  • <#assign> allows you to define variables right in the template ( ). The above code creates a variable name “ex”, using the built-in "freemarker.template.utility.Execute"?new() that allows creating an arbitrary object, which is the object of the “Excute” Class implemented from “TemplateModel”.
  • Use the above payload to correct the input in the “nickname” when capturing packets with Burp Suite:

  • The website responds again:

change “ls” to “cat SECRET_FLAG.txt”, get Flag:

5. Conclusion

Server-side template injection-related vulnerabilities are often overlooked. To limit and prevent unnecessary risks, programmers should be careful about allowing user input to be inserted into the template as well as carefully checking the template used in their Website.


Chia sẻ bài viết ngay

Nguồn bài viết : Viblo