Server-Side Template Injection
What is Server-Side Template Injection? Server-Side Template Injection attack (SSTI) is a critical vulnerability in web applications, where a threat actor exploits a template’s native syntax and employs malicious payloads into the template. By injecting harmful code into the server-side templates, they enable unauthorized access, data breaches or even complete takeover. The compromised template is then executed server-side. SSTs (Server-Side Templates) facilitate dynamic generation, but they are susceptible to SSTI attacks. The SSTs enhance web page customization and performance by processing user information directly on the server. Their vulnerability underscores the importance of robust security measures in web development. SSTI is a bit different from other client-like templating that affects end-user experience only. Whereas SSTI occurs within the server, making it different from cross-site scripting vulnerabilities. SSTs, having great usefulness, in feature-rich web applications can unintentionally expose sensitive user data. This creates emphasis on the need for proactive security measures to reduce SSTI risks. Impact of Server-Side Template Injection Server-Side Template Injection payloads can lead to various attacks on a website. This depends on the type of template engine and the way it works with the application. It is very rare that these vulnerabilities do not pose a real security risk, but in most cases SSTI attacks can cause severe impact. In most severe cases, the threat actors remotely execute code and take over the whole control of the backend servers. They then use these servers to execute additional attacks on internal infrastructure. And in cases where the threat actors cannot execute code remotely, they might be able to read sensitive information or files stored on the server. Here, the attackers with access to read only, can still use SSTI as the basis for many other attacks. Working of Server-Side Template (SST) Server-Side Template (SST) is the most common method for web frameworks to dynamically create HTML, using templates. It consists of both the static parts of HTML output, along with the syntax that describes how it will place dynamic content. These basic server-side template injection systems are unsafe from suspicious template authors. For example, a website should not permit its users to supply their own templates, as a template author can execute cross-site scripting attacks and can obtain properties of these template variables that may include sensitive data. Thereafter, these template engines process template files that support in populating dynamic information into web pages. The template engine generates the HTML output response when an HTTP request arrives. The most commonly used Server-Side Template engines are Jinja2 or Jinja, Freemaker, Mako, Velocity, Smarty, Tornado, Genshi, Twig and Mustache. Working of Server-Side Template Injection (SSTI) Server-Side Template Injection (SSTI) happens when a malicious attacker uses the native template syntax to deploy a harmful payload into a template, which is then executed on the server-side. Template engines are designed to make web pages by merging fixed templates with dynamic data. SSTI attacks take place when a user inputs information and it is then integrated into the template, instead of passing it in the form data. It permits the malicious users to inject random template commands that distort the template engine and allows them to take full control over the server. How can you detect SSTI Vulnerabilities? The SSTI vulnerabilities may occur in two contexts based on different detection techniques. Plain text SSTI detection Testers can detect SSTI payloads in a plain text context by using template expressions as the payload used by different template engines. Thereafter, the basic server-side template injection can view the server’s HTTP responses in an error message. Code-based SSTI detection Testers can test for SSTI vulnerabilities in a code context by creating payloads to retrieve an error or blank server response. For example, a tester can employ a GET parameter in a HTTP request using the personal_greeting variable in the template statement. The payload server will respond with a blank “Hello”. Thereafter, the tester can inject an HTML tag to break out the statement. When the tester identifies the injection point, it is possible to identify the template engine based on the relevant template expressions. The malicious payload used in the input determines whether the tester will identify an SSTI. The server may display an error message or flag the exception. If there is vulnerability in the server, the server will respond with an error message reflecting the template engine. Identify the Template Engine As the testers detect the template injection, they must identify which template engine is used. This may be a simple step, where the testers submit an invalid syntax that induces the template engine to identify itself in the resulting error message. However, this technique is insufficient in some cases, as something suppresses the error messages. It is not suitable for automation. Beside, the testers can automate the identification step with a decision tree in Burp Suite. The tree can direct language-specific payloads, with red and green arrows representing failed and successful responses. At times, a single payload may result in several successful responses, such as the {{7*7}} probe resulting in 7777777 in Jinja2 and 49 in Twig. Vulnerability Exploitation Once the template injection and the underlying template engine is identified, the testers must try to read the documentation. This is an important step for identifying zero-day exploits and verifying if an attacker could exploit the SSTI vulnerability. If there is no apparent exploit at this stage, then, the tester should check the extent of the environment’s accessibility. In this step, you will get to know about the default objects that are provided by the template engine and application-specific objects that the developer passed to the template. Some template systems may expose a namespace or “self” object that allows the developer to list the methods and attributes of the object. As the developer supplies the objects, they are more likely to have sensitive data and can vary between multiple templates in the application. Testers should therefore apply this process separately to each such template. At this stage, the tester should get a clear understanding