An Introduction to Server Side Template Injection Bugs

Server Side Template Injection (SSTI) bugs are a less commonly known type of vulnerability in web application security. Although these bugs are rare, they can have a significant impact when discovered, often resulting in Remote Code Execution (RCE).

This article aims to explain how these issues are introduced and identify common areas where they can be found in real-world scenarios.

What Are Server-Side Templates?

The modern web relies heavily on vast amounts of user information, product details, and various other types of data. To present this information in a meaningful way, it needs to be organized on web pages effectively so the user can quickly get to what’s most important; a serotonin boost from their curated page of memes.

Template languages and frameworks introduce special syntax and constructs that enable developers to create templates that contain static content but also provide syntax and constructs that allow dynamic content to be rendered without the need to mix backend and frontend code.

Where do the security issues come in?

The security issue arises when an attacker is able to send a request where the server’s template engine processes the user input as a template. A good security assessment is a focused one, consider the below areas when looking for this bug class.

Admin Functionality - Features that allow an admin to customize pages, banners, or other visuals in an application can sometimes offer templating as a feature. Some developers may choose to even allow access to template languages which opens up this vulnerability.

Un-Sanitized Input - Potentially any input that’s returned back to the user, or on another page could lead to SSTI depending on the website’s functionality. Now understanding the use cases for template languages, put on your developer hat and try to think where you would leverage templating

Testing for SSTI

If you suspect an SSTI vulnerability in an application, there are a few templating languages the application can be using. The more targeted your testing is, the better. If you’re able to determine the application’s source languages through recon (python/java/php/etc), this will help you craft test payloads for popular templating frameworks used in the target language.

SSTI Polyglot Payload

The SSTI Polyglot payload is designed to test for this vulnerability across several frameworks and languages. It can assist in testing when the source is not known, however, it’s more likely to be stopped by input sanitization or WAFs because of the prevalence of this specific payload and the variety in special characters. ${{<%[%'"}}%\.

You might consider using the payload in a request like this to trigger some kind of error message on the target application.

GET /search?query=${{<%[%'"}}%\.

Python - Jinja2

A simple payload to test if an app is processing Jinja templates is {{7*7}} , you will see 49 on the page if it’s processing the template.

Advancing the payload, you can attempt to get execution with the below example executing the date command using Python’s OS package.

{{ self.__init__.__globals__.__builtins__.__import__('os').popen('date').read() }}

In exploiting this above example, you are using Jinja to exec the os command using OS functionality which should be included in the application’s classpath. In the event that the application’s runtime is particularly hardened but you have a working SSTI POC, you may consider digging into any additional Python packages that the application uses. For instance, you attempt to access the commonly used requests package for further exploitation through SSTI. This is similar to the type of exploit development you might see with de-serialization bugs.

Jinja Filter Bypasses

You should also be aware that there are bypasses for Jinja2 WAF and application filters. Filters and associated bypasses are always evolving, however below are common filters you may see.

WAFs may be picking up some part of self.__init__.__globals__.__builtins__. If this is the case, using attr() may help as it can access the builtins object directly.

{{ request|attr('builtins')|import('os')|popen('date')|read }}

Digging deeper into filter bypasses, you can have Python help transform your payload! For example, using format() can transform the payload as it’s being processed the template engine. This helps when some combination of . or _ are blocked.

{{ request|format('%s%sbuiltins%s%s')|import('os')|popen('date')|read }}

Java Template Injection

Java has more templating frameworks that you may need to contend with for better or for worse. Spring-based web apps are very common, Baeldung has a great list of these https://www.baeldung.com/spring-template-engines

ThymeLeaf Injection

This is one of the most common ones you’ll see in Java, and it has well known exploits for SSTI bugs. To exec a simple test to confirm we have a working template injection bug, you can use this trick again ${7*7} and if you see 49 in the response and not the template, that’s a sign of an issue.

The RCE payload for this comes in 2 variations, Spring Expression Language (SpringEL) and Object Graph Navigation Language (OGNL). SpringEL is much more popular and modern, but you may find OGNL templates still in use. Here’s our example again executing the date command.

• SpringEL ${T(java.lang.Runtime).getRuntime().exec(‘date’)}
• OGNL ${#rt = @java.lang.Runtime@getRuntime(),#rt.exec(‘date’)}

Conclusion

Although this is an intro, hopefully, you can see how these vulnerabilities can be taken advantage of and how they arise. This doesn’t cover nearly all possible SSTI payloads and frameworks, but I encourage you to dig deeper.

Further Reading

• https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Server Side Template Injection/README.md
• https://portswigger.net/web-security/server-side-template-injection