We run a lot of web application tests at OmniCyber Security, and a recent trend we’ve noticed is a rise in template injection vulnerabilities. Both client-side and server-side vulnerabilities are cropping up, and that’s not good news. Well, it is for people who want to attack these weaknesses, but for the rest of us, it’s not great.
In this post, we’ll dive into the differences between Client-Side Template Injection (CSTI) and Server-Side Template Injection (SSTI), and the potential risks associated with each.
What are SSTI and CSTI attacks?
SSTI occurs when an attacker can inject their own code into a server-side template, which is then executed by the server when the template is rendered. This can happen when the application uses unsanitised user input to generate templates or when the application allows users to upload template files. Common server-side templating engines include Twig, Jinja2, Django, ExpressJS, and Razor.
CSTI, on the other hand, occurs when an attacker can inject their own code into a client-side template, which is then executed by the victim’s browser when the template is rendered. This can happen when the application uses unsanitised user input to generate client-side templates or when the application allows users to upload template files that are then included in the application’s pages. Common client-side templating engines include AngularJS (Templates), Vue (Templates), Handlebars, and Mustache.
SSTI attack case study
In a recent engagement, our team was working with a client that allowed users to create and modify email templates. In the editor, you could choose variables to personalise bulk emails with names, companies, industries, and the like. When selected, these variables were placed in double curly braces e.g. {{ username }}. This led us to suspect that the draft email templates could be in a raw format which would be executed later by a templating engine.
To test our theory, we added our own variable with the popular {{7*7}} test string. After sending the test email, we received an email with the greeting “Welcome, 49”, neatly proving our theory. This wasn’t our first rodeo with templating engines, and we were able to fingerprint the templating engine used and identify it as Twig.
The Twig templating engine contains helper ‘filters’ which allow the modification of variables, for example: {{ ‘Hello World’ | upper }} would render as: HELLO WORLD
One filter, with the thrillingly imaginative name ‘filter’, allows for custom functions, and using this it’s possible to pass ‘system’ to run arbitrary commands, such as: {{ [‘cat /etc/passwd’] | filter(‘system’) | raw }}. This produced the output of the ‘cat /etc/passwd’ command from the host into the test email.
We now had remote code execution under the context of the www-data user, which is a very powerful position to be in. From here we were able to further enumerate the host and reveal pretty much anything we wanted. Further attacks from here from a genuinely malicious actor could include potential privilege escalation and enumeration of any internal services.
How to prevent SSTI attacks
There are several ways to prevent SSTI attacks. The most effective way is to sanitize user input to ensure that it does not contain any malicious code. This can be done by validating input data and using appropriate input sanitization functions. Another way to prevent SSTI attacks is to use a template engine that has built-in protections against SSTI, which many do. These protections include automatic escaping of user input, strict input validation, filter and function whitelisting, and sandboxing.
How to prevent CSTI attacks
Now let’s turn our attention to CSTI. Like the SSTI vulnerability, this is usually exploited through user input that is not properly validated or sanitized, such as JavaScript code injected through form fields or URL parameters. One of the main dangers associated with CSTI is the ability to perform XSS (Cross-Site Scripting) attacks, which can lead to data theft, account takeover and malware installation.
To reduce the chance of a successful CSTI attack, web application developers and security professionals should follow secure coding practices and keep up to date with the latest security best practices. These include implementing secure coding practices, performing regular vulnerability assessments and penetration testing, and keeping software and systems up to date with the latest security patches and updates.
To find out how our team can help you, whether that’s through vulnerability scanning, penetration testing or just offering some advice, contact one of our experts today.