Server side template injection - SSTI Vulnerability

What is Server Side Template Injection?

Most web app owners prefer using Twig, Mustache, and FreeMarker like template engines for the seamless embedding of dynamic & rich data in HTML parts of of e-mails or webpages. When the user input is introduced to the template unsafely or with the presence of malicious elements, an SSTI attack takes place. 

SSTI is the insertion of the malicious elements into the famous template engines via built-in templates that are used on the server-side. Here, the main aim of this act by the actor is to get a hold of server-side operations.

The easy way to understand the process of SSTI is by explaining it via real-world examples. Now consider the scenario; you’re using a marketing app for sending customer emails in build and use Twig template system to address the email receivers by name.

If the name is added in the template without granting any modification abilities to the receivers then things will be smooth. As soon as receiver-end customization of the emails is permitted, the sender starts losing the hold over the template content.

Threat actors can use the user-end customization facility as an opportunity and perform an SSTI attack by figuring out the template-generation engine used in customization and altering the featured payload as per their preferences.

Not always SSTI attacks are planned; at times, it occurs unknowingly when the user-side input contracts with the template directly. This situation creates an opportunity for the threat actors to introduce template engine distorting commands and operate servers as per their will. In each case, the outcomes of an SSTI attack are destructive mostly.

How Do Server-Side Templates Work?

Developers often use these templates to create a pre-populated web page featuring customized end-user data directed to the server. The use of these templates reduces the browser-to-server commute during the server-side request processing. 

As server-side templates offer great flexibility and shortcuts to the pre-embedded user inputs, it’s often mistaken with XXS or cross-site scripting.

Template-creation engines are the most preferred resources to create dynamic HTML for web frameworks. On a structural level, a template features the static portion of the intended HTML user output and specific rules explaining the dynamic content insertion process. 

Despite adopting best practices, template systems are not well-guarded and are prone to get into the hands of threat actors or ill-intended template creators. 

Web applications granting the freedom of supplying or introducing user-created templates are likely to become a target of SSTI attacks. Suppose, an author edits data for a variable in this context. It will trigger the engine to use template files for adding dynamic components on the web app. 

Furthermore, the engine automatically starts generating HTML output responses as soon as an HTTP request takes place. 

To check, you may use an HTTP POST request:

For example:

POST /endpoint-detail HTTP/1.1
Host: example.com
parameter=test_data

Here are a few ways to test this vulnerability. We will use different parameter values for this purpose here.

1. You may send a polyglot value, e.g. ${{<%[%'"}}%\., which is a particular pattern used in general for such tests. After the engine displays an error message, you may diagnose the URL in the alert text and figure out the right syntax to try for the template engine.
2. When the error message do not reveal engine details, use the known syntax that are useful for various template engines, e.g.:

=${7*3}

=<%= 7*3 %>

={{7*3}}

Next, read the debug output (e.g., for Django). Different template engines will have slightly-different ways of doing so.

POST /endpoint-detail HTTP/1.1
Host: example.com
parameter={% debug %}

This request will fetch you a list of readable objects, available for debugging. From here, objects like ‘settings’ might be accessible too. So, try reading the secret key and see if you could succeed:

POST /endpoint-detail HTTP/1.1
Host: example.com
parameter={{settings.SECRET_KEY}}

‍

The impact of Server Side Template Injection

Just like any other cyber vulnerability, the SSTI impairs the target. For instance, its introduction makes the website prone to multiple attacks. 

The affected template engine type and the way an application utilizes it are two aspects determining the consequence of the SSTI attack. 

Mostly, the result is highly devastating for the target such as:

• Remote code execution.
• Unauthorized admin-like access enabled for back-end servers;
• Introduction of random files and corruption into your server-side systems;
• Numerous cyberattacks on the inner infrastructure. 

All these actions can cause havoc beyond one’s imagination. In very rare cases, SSTI remains less bothersome.

How to Detect SSTI?

The above-mentioned consequences of SSTI are a sign for developers and defenders to become foresighted and identify the injection in the early stage. However, that is not as easy as it sounds as SSTIs are complicated to understand, seems very similar to XSS attacks, and often remain unseeable. Hence, one has to make extra efforts for the earlier and precise detection of SSTI.

As this is the case with any other attacks, the beginning detection step is to find its presence. The most viable way for this to happen is fuzzing out the template via familiarizing generally-used expressions with special character sequences. 

If the tester isn’t able to execute the character sequence, it implies the presence of SSTI.

Additionally, one can look for the existence of web pages featuring extensions like .stm, .shtml, and .shtm. Websites having pages with these extensions are likely to be impacted by the SSTI attack. 

However, not all these approaches are enough to do 100% precise SSTI detection, because there exists 2 contexts for its presence: plain text and code text. 

Here is a detailed explanation of the most common approaches for detecting SSTI in both the contexts separately:

1. Plaintext
   

In this detection method, XSS input-like plain text is used to check for presence of the vulnerability. To verify whether or not this is a favorable situation for SSTI, you may also use mathematical expressions in your parameter.

To check a site, http://example.com/?username=${7*7} URL can help in SSTI detection. Here, you need to replace ‘example.com’ with the name of the site. If the URL search result features any mathematical value, it shows the presence of SSTI vulnerability. 

2. Code context
   

It concerns constructing a payload that can procure error or blank responses present on the server. Also, it can be done by ensuring zero-probability for the XSS vulnerability. You may try injecting arbitrary HTML in the value to do so.

When XSS is absent, the first approach, constructing a payload, should be used in this SSTI detection method.

How to Identify SSTI?

Upon successful detection of SSTI injection, emphasis must be upon recognizing the template engine that has been influenced. 

There are varied templating languages, but most of them use alike syntax. These syntaxes are created in a way that they won’t contradict with used HTML elements. This makes probing payload creation for impacted template engine testing an easy task.

Submitting invalid syntax is also a viable way to identify SSTI compromise. Your submission will enforce  error messages from server-side systems to give out crucial particulars. 

In most cases, this works. Testers looking for alternative ways must manually test the numerous payloads and analyze their interception procedure through the template-creator engines. To narrow down your options, you may try eliminating syntax patterns as per your trials during the process. 

Also, injecting arbitrary arithmetical operations as per the syntax followed by assorted template enginesis a very common approach.

The above-mentioned logic tree can be followed for accurate identification. While aiming at precise SSTI identification, keep in mind that similar payloads can deliver efficacious responses in multiple languages like Twig or Jinja2. So, testers should always accumulate multiple successful responses to reach a substantial conclusion.

‍

Server Side Template Injection Attack Prevention

After comprehending the consequence of an SSTI attack, it’s not intelligent to disregard it and not to learn about the preventive ways. Ditching the use of a template engine is not a consider-worthy alternative as it supports modification at multiple fronts while not causing any disruptions to the code flow.

Hence, developers and security experts must lookout for other ways to keep the applications and websites away from the reach of SSTI’s reach. Here are some expert-approved SSTI prevention strategies to enforce.

1. Limited ‘Edit’ Access
   

In any case, templates shouldn’t be available for modification and alteration to anyone else, except developers and admins. Templates that are open to all are easy targets for hackers. Hence, it’s wise to execute the access rules on the templates and keep their accessibility restricted. However, this is not an achievable goal all time.

2. A Quick Scrutiny 
   

Sanitization is another viable technique to keep the possibilities of SSTI attacks on the lower side. It refers to cross checking all the intended content for the presence of destructive elements beforehand. Most importantly, this prior scrutiny should be performed on the user transmitted data. One can make it happen by using regex and creating a list of verified expressions. Keep in mind that this solution doesn’t warrant 100% protection.

3. Sandboxing
   

For better protection from SSTI, sandboxing is a better option than sanitization. It’s a preventive approach involving creating a secure and close ecosystem for the user. The close environment is free from dangerous features and modules while restricted access to other data when any vulnerability is figured out. Though its efficacy is commendable, its implementation is a tough task. Also, it’s easy to bypass it by using oversights or misconfiguration.

4. Go for Logicless Templates
   

You can use logic-less templates to prevent SSTI attacks. Logic-less engine templates are the templates used to detach code interpretation and visual rendering. Mustache is a common example of a logic-less template. As a logic-less template uses mil control flow statements, all sort of control is data-driven by default and makes application logic integration possible. This reduces the possibility of remote code execution.

5. Utilize a Docker Container
   

If none of the above solutions work then defenders must admit that the remote code execution is inevitable and should try to trim its impact by implementing customized sandboxing by executing the template engine in a completely locked Docker container. 

The final word

Ensuring end-to-end system security demands a detailed understanding of the wide range of vulnerabilities. SSTI (Server Side Template Injection) is one such vulnerability. Hope that reading this article would have helped you understand its seriousness and made you aware about the need for cybersecurity for organizational digital assets.