Server Side Template Injection - A quick guide to finding that first bug
Server Side Template Injection, or SSTI, is a vulnerability identified within web applications that utilise templating engines to assist is presenting dynamic data via web pages. Common templating engines include Jinja2 and Twig. The important thing to know about templating engines, is they run on a web applications server and return the generated data to the browser.
Ultimately, this means that any form of vulnerability that exists within the template can lead to remote code execution (RCE) directly on the server. This opens up the possibility for an attacker to use a vulnerable webserver to pivot into internal networks or exfiltrate sensitive data from underlying databases.
Commonly, SSTI can be mistaken for Cross-Site Scripting (XSS) but if you, the reader, have performed penetration tests or researched web application bugs before - you will know that XSS is a client-side attack and not a server-side attack.
I don't want to dig too much into how SSTI vulnerabilities can exist and how they can be exploited, PortSwigger have a brilliant post that covers a range of things relative to SSTI. So that would be a great place to start to freshen up your knowledge and gain a deeper understanding: https://portswigger.net/research/server-side-template-injection
Second, creating a basic web application on a local server which utilises a templating engine and allows the user to send and receive certain web data will help highlight how these vulnerabilities are introduced by a developer, how an attacker can exploit them and how they can be patched.
Once understood, it's time to start hunting for an SSTI in the wild! Now, this can be done manually by inspecting web requests to and from web applications, manually placing the payloads into the requests and awaiting their response. As I tend to test large scopes, this is not as efficient as can be and I choose to automate as much as I can to help gain quick coverage before diving in for a deeper, manual inspection.
There are a number of approaches that can be taken. I will highlight a couple of methods that I have personally used and drop some tools that can help with the approach.
Method 1:
cat urls.txt | qsreplace "azbycx{{4*4}}" | httpx -threads 10 -timeout 1 -match-regex 'azbycx16' -o vulnerable_urls.txt
This tweaks identified URL parameters with qsreplace to contain payloads. These are then piped into httpx with a pattern to try identify in the web response body.
Speed: Fast
Method 2:
cat urls.txt | ./lazyssti
(Shameless self plug for a tool I whipped together that essentially does the above, but all in one.) Pipe a list of identified URLs into the lazyssti binary and await for the results.
Speed: Fast
Method 3:
Manually browse the web application and inject SSTI payloads into the URL parameters. Make sure you observe all the responses and use a unique string that can easily be 'searched' for in the source.
Speed: Slow
Brief Tool Breakdown:
qsreplace:
qsreplace is a Golang tool that accepts URLs via standard input, processes the URLs and replaces all query string values with a user supplied value. Once generated, the tool prints all the generated URLs ready to be used by another tool. This tool does not perform any form of web requests or vulnerability identification itself.
https://github.com/tomnomnom/qsreplace
httpx:
A HTTP toolkit that utilises the retryablehttp library to run multiple probes. Ultimately it can be used to perform fast web requests against user supplied URLs.
https://github.com/projectdiscovery/httpx
lazyssti:
A Golang tool I have begun developing to take a list of discovered URLs, tweak the parameters and perform all the web requests. This is not to replace the solution presented in Method 1, however if I can create an 'all in one' method of identifying these vulnerabilities within a single binary then it can't be a negative thing.