Knocking the door to Server-side Template Injection. Part 1

by Mohamed Habib Jawadi

# Hands on guide on Server-Side Template Injection

Introduction

Templating engines are broadly used by modern applications to serve dynamic content to users, over the web or even in email compaigns. Nevertheless, like most technologies/ features out there, it is prone to being the target of abuse as its fuzzing is the eventual outcome of the outgrowning numbers of testers not to mention script kiddies.

Incontrovertible is the criticality of the impact, when it comes to unwise integration as accepting user input in templates can lead to Server Side Template Injection, mostly mistaken for XSS (Cross Site Scripting aka. “><script>alert(“Hacker me am “)</script>), and one of the gates to the RCE( Remote Code Execution ) hell turning each input a nightmare to the BugBounty programs’ budgets .
Below is an example:
https://hackerone.com/reports/423541 Bounty: 10K$

When does this arise?

Modern web applications in general frequently rely on opinionated frameworks which make the usage of templating engines in the hands of every developer, even the unexperienced ones (or pros but lazy :p) for they are in need for solutions to embed dynamic content and serve costumizable web pages and emails.
The injection occurs when an application trusts user input without proper sanitization [read more about user input sanitization] due to one of two reasons:
– Developer error 
– Deliberate exposure

The example below is the example of a web site that generates dynamic content from user-provided values, harnessing the Jinja2 templating engine power. However, SSTI was introduced when concatenating the inputField variable to the template string instead of passing in to a template context.

From a discovery point of view, the exotic behavior of a page when submitting invalid syntax can help easilty identify the occurance of SSTI with the presence of errors (usually when forgetting to switch the debug mode off in frameworks), however the concatenation of a user input to a server variable, evaluating simple arithmetic as introduced above when redering is the most useful indication.

$ curl --get 'http://localhost:8000/sample?field=someString'
# OUTPUT: User input will be reflected here: someString
$ curl --get '–http://localhost:8000/sample?field={{3000+54}}'
# curl: (3) [globbing] nested brace in column 37
# After encoding the parameter data
$ curl --get 'http://localhost:8000/sample?field=%7B%7B3000%2B54%7D%7D'
# OUTPUT: User input will be reflected here: 3054

Exploitation:

• Templating engine identification
• Manual exploitation (root-me writeup -p2-)

Templating engine identification:

After the detection of the vulnerability, the next natural step is to try to exploit it. However that cannot be done without knowinng which templating engine is in use. Eventhough, the process can be as easy as submitting malformed input data… the finding a webapp these days with non-supressed warnings in production is a luxury not all of testers can afford (it doesn’t come with the box ._. ) thus using a tree of possibilities for fuzzing is a must for tackling the task in hand.
The example above, is a flask simple webapp using the Jinja2 templating engine, try to rediscover that using the tree below:

That was it for part one, we lerned what SSTI is and how to find it, the methodology: finding -> identification -> exploitation.
In the next part, we will exploit a vulnerable application by solving a root-me challenge and discover a tool to automate the process.

About the Author

Muhammad Habib Jawady is 18 year old Tunisian InfoSec hobbyist currently working on Web application security. Authored articles on Cybrary and dev.to (a forum for developers) about DevOps and information security.