SSTI: Server side template injection
SSTI can occur because of a technique that developers use to solve the issue of dynamic page generations. Some websites take user input or calculated values and place them in a template that is ready to be served to the site visitor.
You might wonder why templating engines exist and so did I. It turns out templating engines on the server help speed up the process of programming by using smaller tokens and syntax. Templating engines can also help us add logic and variables to our templates. While these are beautiful positives, we also have some negatives to templating engines.
The biggest negative to using server side templating engines is the security aspect. I often warn you guys that integration points are places where security vulnerabilities happen and this is one of the clearest examples i can think of. Since templating engines run on the server and sometimes use variables that may be user supplied, these engines need to grab that data from somewhere. Since templating engines are running as standalone software that take input, there are no inherent security rules defined.
All of this is very fancy language for saying that developers need to filter user data properly, or user can supply commands to the templating engine and the templating engine non-descrimitly takes that input and executes this command.
I do not want to talk down to any developer. They have my deepest respect. That being said, developers have a tendency to not implement these filtering mechanisms properly due to their nature. Often these filters are blacklist based, meaning the developer creates a config file that states what character or sequence of characters is supposed to be disallowed. If the developer forgets one of the characters that we can use to construct an SSTI attack string however, we have an entry point.
It may also occur that developers do implement the filtering systems properly but that we still have an SSTI. This can occur because the filters might not be applied to all points where the templating engine takes input from.
SSTI can occur in plaintext and in code context.
The strategy we will take on this topic is very similar to the XSS strategy. We are pretty much banking on the fact that integration points make it easy to forget to apply the correct filtering.
For a full attack strategy, we want to detect SSTI, identify the templating engine being used and finally exploit it.
We want to insert our attack vector as soon as we can and into every single field that we can to make detection as likely as possible. The reason for this is simple, as you test the application, the templating engine might use any of the saved attack vectors and if the developers forgot to include the filtering on that endpoint/integration point, we have our basic entry point.
As an attack vector i would suggest you use:
${7*7}
The attack vector allows for the broadest detection possible as we use characters that are used in the most prevalent templating engines.
When the server doesn’t return our original attack vector, but instead returns 49, we have likely detected either an SSTI or a CSTI.