Fief-server Server-Side Template Injection vulnerability
Last year, I performed a web application penetration test on a license management service responsible for generating licenses for an application.
Users could register for this service and gain approval from an administrator or a privileged user.
Once approved, they could request new licenses according to their specific needs.
The application used the open-source Fief project for user authentication and authorization.
.
What is Fief?
According to the Fief website:
"Fief is an open-source platform to manage users and authentication in your applications. Our goal is to help you manage users and security in a matter of minutes, not days."
During the penetration test, several authorization-related findings were identified.
However, this article will focus on a Server-Side Template Injection (SSTI) vulnerability that led to remote code execution.
Setting up the Test Environment
To set up the test environment, you can use a Docker Compose file.
After downloading and running it, you can access the environment at http://localhost:8000/login with the username test@test.com and password fief123fief.
Vulnerability Details
It's important to note that any user can register and create their own workspace within the system.
Users also have the option to connect the Fief management system to their own hosted database, which introduces its own set of security risks, or they can utilize Fief's cloud service.
Pay attention; every user can register and sign up for the system. Users can connect the Fief management system to their own hosted database, which has its own security risks, or they can use Fief's cloud service.
While Fief has many features, our focus here is on the email templates, specifically the section for customization at /customization/emailtemplates/.
Several templates are available, and users can select any of them.
Upon examining the template editor, it's apparent that any content entered in the comment editor is directly rendered on the page.
A simple Cross-Site Scripting (XSS) payload, such as <script>alert('xss')</script>, will be executed, demonstrating the absence of input validation. This results in self-XSS.
However, a more critical vulnerability exists: Server-Side Template Injection (SSTI).
Web applications often use template engines to dynamically generate content for web pages and emails.
When user-supplied data is directly inserted into these templates without proper sanitization, it creates a Server-Side Template Injection vulnerability.
Although it can be mistaken for Cross-Site Scripting (XSS), SSTI presents a far greater risk.
While XSS targets the client-side, SSTI enables attackers to manipulate the server's internal operations,
Potentially achieving Remote Code Execution (RCE) and using the compromised application as a platform for further attacks.
Identifying SSTI
As James Kettle explains in his article, there are methods to identify the backend template engine.
In this case, access to the code reveals that the backend template engine is Jinja.
https://portswigger.net/cms/images/migration/blog/screen-shot-2015-07-20-at-09-21-56.png
The following payloads can be used to verify SSTI:
By default, the Jinja environment permits access to unsafe attributes and methods, such as __init__, which leads to security vulnerabilities like the one described.
Remediation
The vulnerability was addressed by switching the email template rendering to Jinja's Immutable Sandboxed Environment, which explicitly prohibits such operations.
The changes implemented to fix the issue can be found here.
The vulnerability report is available here.
