You dont have javascript enabled! Please enable it! 5 Crucial Steps To Stop Server-Side Template Injection Attacks - CHARBEL NEMNOM - MVP | MCT | CCSP | CISM - Cloud & CyberSecurity

5 Crucial Steps to Stop Server-Side Template Injection Attacks

4 Min. Read

In January 2024, software company Atlassian raised alarm bells about a critical injection vulnerability in its Confluence Data Center and Confluence Data Server products. This vulnerability allowed attackers to inject OGNL expressions without authentication, potentially allowing them to execute code on compromised systems.

In this guide, we will discuss what can be done to address Server-Side Template Injection (SSTI) threats, emphasizing tactics that help prevent these attacks from occurring.

Server-Side Template Injection

The template injection vulnerability is identified as CVE-2023-22527 on the NIST National Vulnerability Database and is assigned a 9.8 (critical) base score. Atlassian scores this vulnerability higher, at a maximum of 10.0 score. Customers still using old Confluence Data Center and Server versions were advised to update their systems to address the vulnerability.

Injection attack vulnerabilities are serious cyber threats that should be met with prompt and cautious actions. The consequences can be dire. For example, the Rails YAML vulnerability discovered in 2016 resulted in attacks on various high-profile websites, including GitHub. It is essential to be prepared to combat injection attacks, Server-Side Template Injection (SSTI) in particular, so you can significantly reduce or prevent adverse consequences.

1. Input Sanitization

One essential step in preventing a Server-Side Template Injection (SSTI) attack from succeeding is to sanitize or sterilize inputs allowed in forms or other interfaces that will enable inputs. The term may sound like a misnomer here since sanitization is generally remedial, but input sanitization in this context is preventive.

To clarify, input sanitization entails the certainty that only valid inputs are allowed. Disruptive elements should be prohibited outright. In other words, only clean or safe inputs should be permitted. Any unwanted or unexpected behavior must be prevented from entering into the forms or user interfaces.

Input Sanitization
Input Sanitization

Input sanitization can be undertaken through a combination of the following: creating an allow list of inputs instead of a deny list, validating input data, implementing escaping mechanisms for user input, not employing the “eval” and “exec” functions, sanitizing data for specific contexts, and implementing content security policies. Essentially, these steps help prevent the possibility of having inputs that enable unsafe or malicious behaviors.

It is important to emphasize that input sanitization is not foolproof. Eliminating all possible malicious inputs is unachievable, as attackers can find creative ways to overcome sanitization efforts. It is essential to employ other preventive measures.

2. Edit Access Restriction

Providing outsiders or third parties with the ability to edit templates is like inviting attackers to compromise a system. Only your developers and administrators should be able to use the edit function. Regarding templates used in production, access should be limited to specific administrators, particularly those directly involved in managing the server or application.

Proper user authentication and authorization must be implemented to protect the edit function. The edit function should also be secured by robust user identification mechanisms, including password hashing and session management.

Edit Access Restriction
Edit Access Restriction

It is also advisable to use parameterized rather than dynamic SQL queries. Parameterizing queries isolates the SQL code from the user input, considerably decreasing the chances of SQL injection attacks. These restrictions are set by creating access rules in the template files.

3. Output Encoding

Output encoding or output escaping is a security mechanism that prevents injection attacks, including SSTI. It entails encoding potentially anomalous or malicious characters in user-created content before rendering it in the output.

Output Encoding
Output Encoding

The main objective of output encoding is to ensure the user input is handled as data, not an executable code or script. For example, non-alphanumeric characters such as the ampersand, slash, apostrophe, and mathematical symbols are encoded to prevent the formation of executable HTML code or scripts in web browsers. Output encoding typically entails the appending of additional characters to special characters. The character “&,” for instance, becomes “&amp,” while “<” becomes “&lt.”

Output encoding is a must whenever user input or user-generated content is rendered in the output. It must be implemented regardless of the data’s origin, whether in database queries or user input.

4. Using Logic-less Templates

Logic-less templates are templates that segregate code interpretation from visual representation. They separate the presentation layer from an application’s business logic. In contrast to conventional templates, logic-less templates ensure no decision-making capabilities, control structures, or programming logic in the templates, hence the name.

Logic-less templates are characterized by simplicity and security. They enable dynamic content rendering in web applications using a clean code architecture that is easier to maintain and unlikely to be used in injection attacks. Since they lack programming logic, even if attackers manage to inject arbitrary code into a system, execution is highly unlikely to take place. Incidentally, they help keep SSTI and cross-site scripting attacks at bay.

Using Logic-less Templates
Using Logic-less Templates

Some popular examples of logic-less templates include Twig, a template engine for PHP; Mustache, which is known for supporting various programming languages; Handlebars, a superset of Mustache; and Liquid, a common logic-less template associated with Shopify. These templates focus on data presentation and do not provide opportunities for data manipulation.

5. Sandboxing

Sandboxing can be described as the more secure cousin of input sanitization. Instead of preventing the possibility of injection attacks through restrictions on inputs, sandboxing builds a safe and isolated environment for users. This environment restrains or limits the adverse impact of an injection attack, preventing anomalies from spreading into other parts of the system.

The sandboxing step ensures that there are no dangerous functions and modules. If these modules are compromised, the risks are effectively contained within the sandbox. However, sandboxing is quite tricky to implement. For one, it can be challenging to address the complexity of system interactions. Creating a functional sandbox that has sensible access restrictions is also quite tricky. Sandboxing adds performance head and can also expand cyber-attack surfaces.


Moreover, even though sandboxing is widely perceived to be more effective than input sanitization, it is similarly not foolproof. A minor misconfiguration is all it takes to render the sandbox ineffective. Also, privilege escalation can enable access outside sandboxed environments.

In Conclusion

Addressing server-side template injection (SSTI) threats is crucial in the wake of critical vulnerabilities, such as the one identified in Atlassian’s Confluence products. This guide outlines effective tactics to prevent and mitigate SSTI attacks. It emphasizes the importance of input sanitization to ensure only valid inputs are accepted despite acknowledging its limitations.

Restricting edit access, implementing output encoding, and utilizing logic-less templates are recommended for secure template management. Sandboxing is introduced as a more secure measure, albeit with its challenges. While no single method guarantees complete prevention, they do not have to be undertaken in the same order. A comprehensive approach integrating these strategies is advised to seal potential injection attack vulnerabilities effectively.

Thank you for reading my blog.

If you have any questions or feedback, please leave a comment.

-Charbel Nemnom-

Photo of author
About the Author
Charbel Nemnom
Charbel Nemnom is a Senior Cloud Architect with 20+ years of IT experience. As a Swiss Certified Information Security Manager (ISM), CCSP, CISM, MVP, and MCT, he excels in optimizing mission-critical enterprise systems. His extensive practical knowledge spans complex system design, network architecture, business continuity, and cloud security, establishing him as an authoritative and trustworthy expert in the field. Charbel frequently writes about Cloud, Cybersecurity, and IT Certifications.

Things to Keep in Mind When Switching from Terraform to OpenTofu for IaC

How To Create a Self-Hosted Agent for Azure Pipelines


Let me know what you think, or ask a question...