Server-side template injection occurs when an attacker is able to inject a malicious payload into a template, which is subsequently executed server-side.
Template engines are intended to create web pages by mixing fixed templates with variable data. When user input is concatenated directly into a template rather than being given in as data, server-side template injection attacks can occur. This enables attackers to insert arbitrary template directives into the template engine, allowing them to gain total control of the server. Server-side template injection payloads, as the name implies, are given and assessed on the server, possibly making them far more hazardous than ordinary client-side template injection.
Server-side template injection flaws can expose websites to a wide range of attacks, depending on the template engine in issue and how the application employs it. In certain rare cases, these flaws do not constitute a serious security concern. However, server-side template injection can have disastrous consequences most of the time.
At the most severe end of the spectrum, an attacker may be able to accomplish remote code execution, gaining complete control of the back-end server and utilizing it to launch further assaults against internal infrastructure.
Even when complete remote code execution is not achievable, an attacker may frequently utilize server-side template injection as the foundation for a variety of additional attacks, possibly acquiring read access to sensitive data and arbitrary files on the server.
Allowing no users to alter or submit new templates is the greatest strategy to avoid server-side template injection. However, owing to commercial reasons, this is sometimes inevitable.
Using a “logic-less” template engine, such as Mustache, unless absolutely essential, is one of the simplest methods to prevent creating server-side template injection vulnerabilities. Separating functionality and appearance as much as possible will limit your vulnerability to the most deadly template-based attacks.
Another precaution is to run user code exclusively in a sandboxed environment where potentially harmful modules and functions have been removed entirely. Unfortunately, sandboxing untrusted code is inherently complex and vulnerable to circumvention.
Static templates that just act as placeholders for dynamic information are often not subject to server-side template injection. The classic example is an email that addresses each user by name, such as the following Twig template excerpt:
$output = $twig->render("Dear {first_name},", array("first_name" => $user.first_name) );
Because the user’s first name is simply supplied into the template as data, it is not subject to server-side template injection.
However, because templates are just strings, web developers may occasionally immediately concatenate user input into templates before displaying. Let’s look at a similar example to the one before, except this time users may change elements of the email before sending it. They could, for example, be allowed to pick the name that is used:
$output = $twig->render("Dear " . $_GET['name']);
Instead of a static value being supplied into the template in this case, a portion of the template is dynamically constructed using the GET parameter name. Because template syntax is evaluated on the server, an attacker might theoretically include a server-side template injection payload inside the name argument, as seen below:
http://vulnerablewebsite.com/?name={{malicious-code}}
ZOFixer.com security scan helps to find this vulnerability in your software and server, you can easily use it by registering on our website and activating the 30-day trial.