ZTH: Obscure Web Vulns
Server Side Template Injection (SSTI)
A template engine allows developers to use static HTML pages with dynamic elements. Take for instance a static profile.html page, a template engine would allow a developer to set a username parameter, that would always be set to the current user's username
Server Side Template Injection, is when a user is able to pass in a parameter that can control the template engine that is running on the server.
For example take the code
This introduces a vulnerability, as it allows a hacker to inject template code into the website. The effects of this can be devastating, from XSS, all the way to RCE.
Note: Different template engines have different injection payloads, however usually you can test for SSTI using {{2+2}} as a test.
Manual Exploitation
Gives us this page. It takes a prompt for a name, and then returns Hello <name>!., suppose it is vulnerable to SSTI ( {{2+2}} gives Hello 4! )
We can use the wonderful repository PayloadsAllTheThings, to find some payloads.
For example, {{ ''.__class__.__mro__[2].__subclasses__()[40]()(<file>).read()}} to read files on the server.
We can use the code {{config.__class__.__init__.__globals__['os'].popen(<command>).read()}} to execute commands on the server. All that payload does is import the os module, and run a command using the popen method.
Automatic Exploitation
There is a tool known as Tplmap that does that for us! The tool can be found here.
Note: use python2 to install the requirements. python2 -m pip
The basic syntax for tplmap is different depending on whether you're using get or post
Cross Site Request Forgery (CSRF)
CSRF occurs when a user visits a page on a site, that performs an action on a different site. For instance, let's say a user clicks a link to a website created by a hacker, on the website would be an html tag such as <img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net"> which would change the account email on the vulnerable website to "pwned@evil-user.net". CSRF works because it's the victim making the request not the site, so all the site sees is a normal user making a normal request.
This opens the door, to the user's account being fully compromised through the use of a password reset for example. The severity of this cannot be overstated, as it allows an attacker to potentially gain personal information about a user, such as credit card details in an extreme case.
Manual Exploitation
Let's take an example application
It seems simple enough, As user bob, I can send funds to either Bob or Alice with any of the available balance in my account. Let's take a closer look at the request in burp.
This is looking good, parameters we can customize and a session cookie that is automatically set. Everything seems vulnerable to CSRF. Let's try and make a vulnerable site. Putting <img src="http://localhost:3000/transfer?to=alice&amount=100"> into an html file and using SimpleHTTPServer to host it should change's Alice's balance by 100, Let's see if it does!
Automatic Exploitation
There is a nice automated scanner, which tests if a site is vulnerable to CSRF. this tool is known as xsrfprobe and can be install via pip using pip3 install xsrfprobe. This will only work using python 3.
The syntax for the command is xsrfprobe -u <url>/<endpoint>
Last updated
