🔐
Secure Coding Handbook
  • Secure Coding Handbook
  • Resources
  • Client side
    • Cross-Site Scripting [XSS]
    • Cross-Site Request Forgery [CSRF]
    • Clickjacking
    • Open Redirects
  • Server Side
    • SQL Injections [SQLi]
    • XML External Entity Injection [XXE]
    • OS Command Injection [Command Execution]
    • File Upload
    • Server-Side Request Forgery [SSRF]
    • Host Header Injection
    • Authentication
    • Directory Traversal
    • Template Injection [SSTI]
  • API
    • Broken Object Level Authorization
    • Excessive Data Exposure
    • Mass Assignment
  • Auxiliary
    • Vulnerable Dependency Management
    • Deserialization
    • Logging
  • Solidity
    • Re-Entrancy
Powered by GitBook
On this page
  • 1. Introduction:
  • 2. Typical vulnerable code:
  • 3. Mitigations:
  • 4. Takeaways:

Was this helpful?

  1. Server Side

Template Injection [SSTI]

PreviousDirectory TraversalNextBroken Object Level Authorization

Last updated 3 years ago

Was this helpful?

1. Introduction:

Server-side template injection is when an attacker is able to use native template syntax to inject a malicious payload into a template, which is then executed server-side.

Template engines are designed to generate web pages by combining fixed templates with volatile data. This allows attackers to inject arbitrary template directives in order to manipulate the template engine, often enabling them to take complete control of the server.

You can read more about this type of vulnerability,

2. Typical vulnerable code:

There are several libraries/ frameworks that make use of templates, here are a few: Jinja, Flask, Mako, Twig. The following code snippet showcases Flask's vulnerability:

from flask import Flask,request,render_template_string 
from urllib.parse import unquote

app = Flask(__name__)

@app.route("/")
def main_page():
    return "Hey there, this is my cool weeb site."

@app.errorhandler(404) 
def page_not_found(error): 
    url = unquote(request.url) 
    return render_template_string("<h1>URL %s not found</h1><br/>" % url), 404 
    
if __name__ == '__main__': 
    app.run(debug = False, host = '0.0.0.0')

3. Mitigations:

If user-supplied templates are a business requirement, how should they be implemented? The lowest risk approach is to simply use a trivial template engine such as Mustache, or Python's Template. Separating the logic from rendering as much as possible can greatly reduce your exposure to the most dangerous template-based attacks. Another, complementary approach is to concede that arbitrary code execution is inevitable(regardless of filtering/ whitelisting/ blacklisting)and sandbox it inside a locked-down Docker container.

4. Takeaways:

Not using user-supplied templates saves you of this possible exploitation. Should you really have to use template rendering however, an alternative can be sandboxing the actual rendering in a custom way, though you can think of the major drawbacks here.

You can find more details about this topic here:

The given input is being rendered and reflected into the response. This is easily mistaken for a simple vulnerability, but it's easy to difference if you try set mathematical operations within the template expression: {{7*7}}.

Showcasing that {{7*7}} gets rendered as 49 proves the point that our application is vulnerable to SSTI. We will however not go into more details regarding further exploitation, for that.

.

from an attacker's perspective, here.
XSS
however you can refer to this awesome guide
Server-Side Template Injection
Hacktricks guide of exploiting SSTI.
Testing for SSTI
2MB
EN-Server-Side-Template-Injection-RCE-For-The-Modern-Web-App-BlackHat-15.pdf
pdf
BlackHat SSTI