Server-Side Template Injection

Server-Side Template Injection by drop organization

What is Server-Side Template Injection?

Server-Side Template Injection attack (SSTI) is a critical vulnerability in web applications, where a threat actor exploits a template’s native syntax and employs malicious payloads into the template. By injecting harmful code into the server-side templates, they enable unauthorized access, data breaches or even complete takeover. The compromised template is then executed server-side. 

SSTs (Server-Side Templates) facilitate dynamic generation, but they are susceptible to SSTI attacks. The SSTs enhance web page customization and performance by processing user information directly on the server. Their vulnerability underscores the importance of robust security measures in web development.

SSTI is a bit different from other client-like templating that affects end-user experience only. Whereas SSTI occurs within the server, making it different from cross-site scripting vulnerabilities. SSTs, having great usefulness, in feature-rich web applications can unintentionally expose sensitive user data. This creates emphasis on the need for proactive security measures to reduce SSTI risks.

Impact of Server-Side Template Injection

Server-Side Template Injection payloads can lead to various attacks on a website. This depends on the type of template engine and the way it works with the application. It is very rare that these vulnerabilities do not pose a real security risk, but in most cases SSTI attacks can cause severe impact.

In most severe cases, the threat actors remotely execute code and take over the whole control of the backend servers. They then use these servers to execute additional attacks on internal infrastructure. And in cases where the threat actors cannot execute code remotely, they might be able to read sensitive information or files stored on the server. Here, the attackers with access to read only, can still use SSTI as the basis for many other attacks.

Working of Server-Side Template (SST)

Server-Side Template (SST) is the most common method for web frameworks to dynamically create HTML, using templates. It consists of both the static parts of HTML output, along with the syntax that describes how it will place dynamic content.

These basic server-side template injection systems are unsafe from suspicious template authors. For example, a website should not permit its users to supply their own templates, as a template author can execute cross-site scripting attacks and can obtain properties of these template variables that may include sensitive data.

Thereafter, these template engines process template files that support in populating dynamic information into web pages. The template engine generates the HTML output response when an HTTP request arrives.

The most commonly used Server-Side Template engines are Jinja2 or Jinja, Freemaker, Mako, Velocity, Smarty, Tornado, Genshi, Twig and Mustache.

Working of Server-Side Template Injection (SSTI)

Server-Side Template Injection (SSTI) happens when a malicious attacker uses the native template syntax to deploy a harmful payload into a template, which is then executed on the server-side. 

Template engines are designed to make web pages by merging fixed templates with dynamic data. SSTI attacks take place when a user inputs information and it is then integrated into the template, instead of passing it in the form data. It permits the malicious users to inject random template commands that distort the template engine and allows them to take full control over the server.

How can you detect SSTI Vulnerabilities?

The SSTI vulnerabilities may occur in two contexts based on different detection techniques.

Plain text SSTI detection

Testers can detect SSTI payloads in a plain text context by using template expressions as the payload used by different template engines. Thereafter, the basic server-side template injection can view the server’s HTTP responses in an error message.

Code-based SSTI detection

Testers can test for SSTI vulnerabilities in a code context by creating payloads to retrieve an error or blank server response. For example, a tester can employ a GET parameter in a HTTP request using the personal_greeting variable in the template statement. The payload server will respond with a blank “Hello”.

Thereafter, the tester can inject an HTML tag to break out the statement. When the tester identifies the injection point, it is possible to identify the template engine based on the relevant template expressions.

The malicious payload used in the input determines whether the tester will identify an SSTI. The server may display an error message or flag the exception. If there is vulnerability in the server, the server will respond with an error message reflecting the template engine.

Identify the Template Engine

As the testers detect the template injection, they must identify which template engine is used. This may be a simple step, where the testers submit an invalid syntax that induces the template engine to identify itself in the resulting error message. However, this technique is insufficient in some cases, as something suppresses the error messages. It is not suitable for automation. 

Beside, the testers can automate the identification step with a decision tree in Burp Suite. The tree can direct language-specific payloads, with red and green arrows representing failed and successful responses. At times, a single payload may result in several successful responses, such as the {{7*7}} probe resulting in 7777777 in Jinja2 and 49 in Twig.

Vulnerability Exploitation

Once the template injection and the underlying template engine is identified, the testers must try to read the documentation. This is an important step for identifying zero-day exploits and verifying if an attacker could exploit the SSTI vulnerability.

If there is no apparent exploit at this stage, then, the tester should check the extent of the environment’s accessibility. In this step, you will get to know about the default objects that are provided by the template engine and application-specific objects that the developer passed to the template. Some template systems may expose a namespace or “self” object that allows the developer to list the methods and attributes of the object.

As the developer supplies the objects, they are more likely to have sensitive data and can vary between multiple templates in the application. Testers should therefore apply this process separately to each such template. 

At this stage, the tester should get a clear understanding of the available attack surface. The final step comprises the application of conventional security auditing methods to review every function and identify vulnerabilities that an attacker could exploit. Testers shall go for this approach as a part of the overall application security. Some functions may allow attackers to exploit features specific to the application.

Prevention techniques for Server-Side Template Injection attacks

You cannot completely remove the template engine from a server as it supports application changes without disrupting ongoing operations. Hence, it is important to learn how to use templates securely while preventing SSTI.

Sanitize Inputs

Sterilization can steadily mitigate the risk of  SSTI attack. A template should check all expected inputs for disruptive elements. The template should use an allow list approach to only allow inputs that are expected by users and restrict others. A common way to do this is to use regular expressions to create a list of allowed input patterns. Input sanitization is essential, but limited, and attackers have many creative ways of circumventing it. This, in turn, creates a malicious input that fits the allowed pattern. Hence, this solution cannot assure complete protection.

Restrict ‘Edit’ Access

Templates that can be used by everyone, are the easy targets for attackers. Thus, it is best to restrict access by applying access rules to template files. It is difficult to prevent templates from being modified by anyone other than developers and administrators. However, templates used in production should only be accessed by the specific administrator in charge of the server or application, not by developers. This can lower the risk of supply chain attacks and insider threats.

Sandboxing

Sandboxing is a more secure approach than sanitization. It is a precautionary approach that creates a safe, isolated environment for users. In this environment, there are no hazardous functions or modules and access to other data is prohibited. This means that if a vulnerability is discovered or a user attempts an attack, the damage is limited. Sandboxing a template is a very effective measure but is difficult to execute. Along with this, the attackers can sidestep sandboxing by taking advantage of misconfigurations or attempting privilege escalation to intrude outside the sandboxed environment.

Logic-less Templates

The most secure approach is to use logic-less templates. These templates completely separate code interpretation from visual representation. An example of a logic-less template engine is Mustache. Logic-less templates make use of control flow statements to ensure that controls are data-driven by default, enabling integration with application logic. Here, the probability of remote code execution becomes quite remote.

Want to start your learning journey on Cyber Security and Ethical Hacking field?

contact with drop organization
Categories:

Leave a Reply

Your email address will not be published. Required fields are marked *