> For the complete documentation index, see [llms.txt](https://kruknight.gitbook.io/daemon-of-hacking/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kruknight.gitbook.io/daemon-of-hacking/writeups/portswigger-labs/server-side-template-injection/basic-server-side-template-injection-code-context.md).
# Basic server-side template injection (code context)
## Lab Description
## Walkthrough
### Step 1: Analyze the Functionality
**Observation:**
* After logging in with the provided credentials (`wiener:peter`), you navigate to the **My Account** page.
* There’s a dropdown labeled **"Preferred Name"**, which suggests that the user can select a display format for their name (e.g., full name, first name, nickname).
* Changing this setting sends a POST request with the parameter `blog-post-author-display` to configure how the user’s name will be displayed in comments.
* Since the hint mentions server-side template injection, the first step is to identify whether this functionality is vulnerable.
* Focus on the parameter `blog-post-author-display`, as it might process user input in an unsafe manner.
* A template engine is likely being used to generate the output dynamically.
### **Step 2: Test for SSTI Vulnerability**
**Action:**
* Modify the `blog-post-author-display` parameter to include a basic template injection payload, such as `{{7*7}}`.
* Expected Behavior: If vulnerable, the application should evaluate this payload and return `49` instead of the string `{{7*7}}`.
**Result:**
* Post a comment on a blog post to see how the name is rendered.
* The username shows as `Peter0 {{49}}`, confirming the SSTI vulnerability.
**Thought Process:**
1. The successful result of `{{7*7}}` indicates the presence of a template engine.
2. The next step is to identify which template engine is in use to craft an appropriate payload for remote code execution (RCE).
To see our username and check if the payload worked we need to post a comment on one of the posts, so we go ahead and do that and we can see that the payload worked
### **Step 3: Identify the Template Engine**
**Action:**
* Use **trial-and-error** with payloads specific to common template engines (e.g., Jinja2, Tornado, Twig).
* Sites like **PayloadsAllTheThings** provide a list of test payloads for various engines.
After testing, the template engine is identified as **Python’s Jinja2**.
1. Knowing the template engine allows crafting payloads that execute Python code.
2. The next goal is to gain RCE by running arbitrary commands on the server.
#### **Step 4: Achieve Remote Code Execution**
**Action:**
* Use the Jinja2 payload to import the `os` module and run system command
This payload, when URL-encoded, executes the `ls` command to list files in the directory.
* The ability to execute commands confirms RCE.
* The lab objective is to delete the file `morale.txt`. Now, craft a payload to accomplish this.
```
user.first_name}}{%25+import+os+%25}{{os.system('ls')
```
#### **Step 5: Delete the File**
**Action:**
* Modify the payload to delete `morale.txt` using the `rm` command:
```
user.first_name}}{%25+import+os+%25}{{os.system('rm%20morale.txt')
```
* Deleting `morale.txt` satisfies the lab requirements.
* By leveraging SSTI and RCE, you have demonstrated the exploitability of improper input handling in template engines.
