Analysis of server template injection attacks (SSTI)

Analysis of server template injection attacks (SSTI)

At this year's Black Hat conference, James Kettle explained "Server-Side Template Injection: RCE for the modern webapp", from the formation of Server Template Injection to detection, the verification and utilization are described in detail. Based on understanding the original content, this article analyzes the principles of server template injection and scan detection methods in combination with more specific examples.

I. template injection and common Web Injection

For injection vulnerabilities, common Web injections include SQL injection, XSS injection, XPATH injection, XML injection, code injection, and command injection. The essence of the injection vulnerability is that the server accepts user input, and does not filter or strictly execute the code that concatenates user input, resulting in various types of injection. The following code is sufficient to illustrate this point:

// SQL injection $ query = "select * from sometable where id = ". $ _ GET ['id']; mysql_query ($ query); ------------- gorgeous split line ------------- // template injection $ temp-> render ("Hello ". $ _ GET ['username']);

Server-side template injection is similar to common Web injection. It also receives user input and uses it as part of the Web Application Template content. During the target compilation and rendering process, malicious content inserted by users is executed, which may lead to problems such as sensitive information leakage, code execution, and GetShell. The impact scope mainly depends on the complexity of the template engine.

Ii. template injection principles

Template injection involves the process of rendering user requests using the template engine for Web applications on the server. Here we use the PHP template engine Twig as an example to illustrate how template injection works. Consider the following code:

<? Phprequire_once dirname (_ FILE __). '/.. /lib/Twig/Autoloader. php '; Twig_Autoloader: register (true); $ twig = newTwig_Environment (newTwig_Loader_String (); $ output = $ twig-> render ("Hello {name }}", array ("name" => $ _ GET ["name"]); // echo $ output as the value of the template variable;

Use the Twig template engine to render the page. The template contains the {name} variable. The template variable value comes from the GET request parameter $ _ GET ["name"]. Obviously, this code is okay. Even if you want to pass a piece of JavaScript code to the server for rendering through the name parameter, you may think that XSS can be performed here, however, since the template engine generally encodes and escapes the rendered variable values by default, it does not cause cross-site scripting attacks:

However, if the rendered template content is under user control, the situation will be different. Modify the code:

<? Phprequire_once dirname (_ FILE __). '/.. /lib/Twig/Autoloader. php '; Twig_Autoloader: register (true); $ twig = newTwig_Environment (newTwig_Loader_String ()); $ output = $ twig-> render ("Hello {$ _ GET ['name']}"); // echo $ output as part of the template content;

The above code concatenates user input as the template content during template construction. If JavaScript code is directly transferred to the server, the user input will be output as is, and the test result is obvious:

Compared with the above two cases, simply put, the formation of server-side template injection is still caused by the server's belief in the user's output (the true meaning of Web security: Never trust the user's input !). Of course, in the second case, attackers can not only insert JavaScript scripts, but also perform further attacks on the template framework. This part only describes the principles, detailed descriptions and demonstration of attack exploitation will be provided later.

Iii. template injection Detection

We have already explained the formation of template injection. Now let's talk about how to detect and scan it. If the server uses user input as a part of the template, the content entered by the user will be compiled and parsed for the final output during page rendering. Use the code used in the second part of this article:

<? Phprequire_once dirname (_ FILE __). '/.. /lib/Twig/Autoloader. php '; Twig_Autoloader: register (true); $ twig = newTwig_Environment (newTwig_Loader_String ()); $ output = $ twig-> render ("Hello {$ _ GET ['name']}"); // echo $ output as part of the template content;

In the Twig template engine, in addition to the variables that can be output, {var} can also execute some basic expressions and use the results as the values of the template variables, for example, if you enter name ={{ 2*10}, the following template content is spliced on the server:

Hello{{2*10}}

During template compilation, the Twig template engine calculates the expression 2*10 in {2*10} and outputs the return value 20 as the template variable value. For example:

Change the test data and insert some normal characters and the default annotator of the Twig template engine to construct the Payload:

IsVuln{# comment #}{{2*8}}OK

The actual template to be compiled on the server is constructed as follows:

HelloIsVuln{# comment #}{{2*8}}OK

Here is a brief analysis. As {# comment #} is the default annotation form of the Twig template engine, it is not displayed when the frontend outputs, {2*8}, as the template variable, will return 16 as the value for display. Therefore, the frontend will return the content Hello IsVuln16OK.

Such:

 

The above two simple examples show the general process of SSTI scan detection (Twig is used as an example here ):

Like conventional SQL Injection detection and XSS detection, template Injection Vulnerability Detection also carries specific Payload to the passed parameters and determines Based on the returned content. Every template engine has its own syntax. The construction of Payload requires different scanning rules for various template engines, just as there are different database types in SQL injection.

Simply put, the request parameter is changed to carry the Payload containing the template engine syntax, And the content returned by page rendering is used to check whether the Payload is compiled and parsed, if there is parsing, it can be determined that the template engine injection contains Payload; otherwise, SSTI does not exist.

Iv. Summary

This article briefly introduces the relationship between server-side template injection vulnerabilities, such as conventional Web injection vulnerabilities, analyzes their production principles, and uses the PHP template engine Twig as an example to explain SSTI's conventional scanning and detection methods. Although SSTI is not widely used, if developers abuse the template engine and perform insecure encoding, then SSTI may occur in Web applications, in addition, the complexity of the template engine and the features of the development language may cause serious problems.

In the subsequent articles, we will conduct a more detailed research and analysis on the popular template engines in various languages, and provide the corresponding available points and methods.