Daemon Of Hacking
  • WELCOME!
    • 👋/home/usr/KruKnight
  • METHODOLOGIES & RESOURCES
    • Passwords & Attacks
    • Post Exploitation
      • 👀Situational Awareness
      • 🖥️Privilege Escalation
        • Linux Privilege Escalation
        • Windows Privilege Escalation
  • Writeups
    • CyCtf 2024
      • Vending Machine
      • Aerospace
      • OhMyCell
    • Portswigger Labs
      • Authentication
        • Username enumeration via different responses
        • 2FA simple bypass
        • Password reset broken logic
        • Username enumeration via subtly different responses
        • Username enumeration via response timing
        • Broken Brute-Force Protection, IP Block
        • Username enumeration via account lock
        • 2FA broken logic
        • Brute-forcing a stay-logged-in cookie
        • Offline password cracking
        • Password reset poisoning via middleware
        • Password brute-force via password change
        • Broken brute-force protection, multiple credentials per request
      • Os Command Injection
        • OS command injection, simple case
        • Blind OS command injection with time delays
        • Blind OS command injection with output redirection
        • Blind OS command injection with out-of-band interaction
        • Blind OS command injection with out-of-band data exfiltration
      • Cross-Origin Resource Sharing (CORS)
        • CORS vulnerability with basic origin reflection
        • CORS vulnerability with trusted null origin
        • CORS vulnerability with trusted insecure protocols
      • Server-side template injection
        • Basic server-side template injection
        • Basic server-side template injection (code context)
      • Server-Side Request Forgery (SSRF)
        • Basic SSRF against the local server
        • Basic SSRF against another back-end
        • Blind SSRF with out-of-band detection
        • SSRF with blacklist-based input filter
        • SSRF with filter bypass via open redirection vulnerability
      • Path Traversal
  • 🟩HTB Writeups
    • Heal
Powered by GitBook
On this page
  • Lab Description
  • Walkthrough
  • Step 1: Analyze the Functionality
  • Step 2: Test for SSTI Vulnerability
  • Step 3: Identify the Template Engine

Was this helpful?

  1. Writeups
  2. Portswigger Labs
  3. Server-side template injection

Basic server-side template injection (code context)

PreviousBasic server-side template injectionNextServer-Side Request Forgery (SSRF)

Last updated 5 months ago

Was this helpful?

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.