Server-side attacks concentrate on weaknesses in the application or services that run on a server, while client-side attacks occur on the user’s device (the browser or client machine) rather than on the server. Recognizing and distinguishing between these two categories is critical for effective penetration testing and bug-bounty work, because the attack surface, exploitation techniques, and mitigation strategies differ significantly.

For example, Cross-Site Scripting (XSS) is typically a client-side problem because it targets the browser and the user’s interaction with a web page. By contrast, server-side attacks aim directly at the web server or backend components. In this module we will explain and explore four major families of server-side vulnerabilities, how they arise, and what risks they pose:

Server-Side Request Forgery (SSRF)
Server-Side Template Injection (SSTI)
Server-Side Includes (SSI) Injection
XSLT (Extensible Stylesheet Language Transformations) Server-Side Injection

Server-Side Request Forgery (SSRF)

Server-Side Request Forgery (SSRF) is a class of flaw that lets an attacker coerce a vulnerable web application into issuing HTTP (or other protocol) requests from the server itself, often to arbitrary destinations. This typically happens when an application accepts a URL or network resource from user input and then fetches it without adequate validation. If exploited, SSRF can be used to reach internal services that are not publicly accessible, bypass firewall protections, enumerate internal hosts and ports, and exfiltrate sensitive data. In severe cases, SSRF can act as a stepping stone to further compromise internal infrastructure.

Server-Side Template Injection (SSTI)

Many web applications use template engines on the server to dynamically build HTML or other output from templates combined with user data. When untrusted input is directly injected into a template without proper sanitization, attackers may be able to insert template expressions or code. This is known as Server-Side Template Injection (SSTI). Depending on the templating engine and how templates are evaluated, SSTI can result in information disclosure, server-side logic manipulation, or in the worst cases remote code execution that gives an attacker arbitrary control over the server environment.

Server-Side Includes (SSI) Injection

Server-Side Includes (SSI) allow servers to insert dynamic content—such as common headers, footers, or other fragments—into HTML pages at request time using special SSI directives. Because SSI processes commands embedded in HTML, if user input can influence those directives, an attacker might inject SSI commands. SSI injection can cause disclosure of sensitive files, inclusion of unintended content, or execute arbitrary commands on servers that interpret SSI directives insecurely. As with other server-side injection problems, the impact ranges from mild information leaks to full remote execution depending on server configuration.

XSLT Server-Side Injection

XSLT is a language for transforming XML documents into other formats (for example, HTML). Some web applications perform XSLT transformations on the server to render client responses. XSLT server-side injection occurs when an attacker can manipulate either the XML input or the XSLT stylesheet used in the transformation, allowing malicious templates or code to be processed by the server. Successful exploitation may permit attackers to alter output, access unintended data, or in some environments execute arbitrary operations on the server. The exact consequences depend on how transformations are performed and which XSLT processors and extension features are enabled.

Identifying SSRF

Having covered the SSRF fundamentals, let’s jump straight into a practical example web application.

Exploit a SSRF vulnerability to identify an internal web application. Access the internal application to obtain the flag.

Open the page and click on Check Availability button.

Intecept the request with Burp Suite. Right-click on the request and choose Sent to Repeater.

Start a server with your terminal and change de DNS to your IP to validade the vulnerability

Click on Send button.

OK, the vulnerability exists. Change the IP to a internal IP. It works!! Now we want to search for other sevices that are running on this machine. Right-click on the request and choose Sent to Intruder.

Select the port that you were using and click on Add button. Configure the range from 1 to 10000.

On the Settings tab, insert the text bellow to grep this text when we execute the attack

Failed to connect to

Click on Attack button.

There are 3 ports open: 80, 3306, 8000. Go back to Repeater and Send a resquest on this port to get the flag.

Exploiting SSRF

Having covered how to spot SSRF flaws and use them to map services on the web server, we’ll now move on to more advanced exploitation methods — techniques that amplify the consequences of an SSRF compromise and let you extract more sensitive information or gain further access.

Exploit the SSRF vulnerability to identify an additional endpoint. Access that endpoint to obtain the flag. Feel free to play around with all SSRF exploitation techniques discussed in this section.

Just open the page, send and intercept a request with burp

Right click and choose Send to Repeater. On Repeater tab, use the payload bellow:

dateserver=file:///flag.txt

Blind SSRF

In many real-world scenarios involving SSRF (Server-Side Request Forgery) vulnerabilities, the server’s response is not shown to the attacker. These cases are known as blind SSRF vulnerabilities because the response generated by the request remains completely hidden from view. As a result, the usual exploitation techniques described in earlier sections cannot be applied, since they depend on analyzing or interpreting the response returned by the target system. Consequently, the overall impact of blind SSRF flaws is typically much lower, as the attacker’s ability to gather information, confirm successful exploitation, or pivot further within the network is greatly restricted by the absence of visible feedback.

Exploit the SSRF to identify open ports on the system. Which port is open in addition to port 80?

Open the page and click on the Check Availability button.

Intercept the request with Burp Suite.

Choose send to Repeater. In this tab, we want to send a valid and an invalid port to see if we have differents responses. With the 80 port, we know that wil works.

Now, let’s try an invalid port. Using 8000 port, we have a different response.

Let’s enumerate ports 1 through 10,000 to search for responses we know are correct. Right click on the request and choose Send to Intruder. Configure the attack.

Click on Start Attack button.

Identifying SSTI

Before attempting to exploit a Server-Side Template Injection (SSTI) flaw, it’s crucial to first verify that the vulnerability actually exists. In addition, you must determine which template engine the target web application relies on, because the steps and payloads for exploitation vary greatly depending on the specific engine in use. Each templating system has its own syntax, built-in functions and evaluation rules, so knowing the exact engine is vital to craft effective, engine-specific exploitation techniques and reliable proof-of-concept payloads.

Apply what you learned in this section and identify the Template Engine used by the web application. Provide the name of the template engine as the answer.

Open the page and send the text bellow

the payload {{7*7}} evaluated to 49, and {{7*'7'}} would also evaluate to 49 (numeric multiplication) — behavior matching…

This behavior matches Twig

Exploiting SSTI — Jinja2

Having covered how to detect a template injection vulnerability and determine which templating system the target uses, we now shift our attention to exploiting SSTI specifically when the identified engine is Jinja2. In this section we’ll assume the earlier verification steps — confirming SSTI and identifying the template engine — have already been completed, and we will concentrate solely on the exploitation phase under that assumption.

Jinja2 is a widely used templating engine in Python web stacks, frequently found in frameworks like Flask and sometimes used with Django projects. For clarity, the examples and discussion here are framed around a Flask application; templates and exploitation approaches can differ subtly when Jinja2 is embedded in other frameworks or when additional middleware modifies template rendering.

When crafting payloads for Jinja2, you may be able to leverage any Python modules that are already loaded into the application’s runtime — whether they were imported directly by the app’s code or pulled in transitively by other libraries. In some cases, it may also be possible to bring additional modules into scope from within the template context. Keep in mind that specific exploitation techniques are heavily dependent on the target environment (framework version, configuration, available imports, and runtime protections), so a cautious, environment-aware approach is essential.

Exploit the SSTI vulnerability to obtain RCE and read the flag.

Open the site and insert the text bellow:

{{ self.init.globals.builtins.open("/flag.txt").read() }}

Click on Submit button and get the flag.

Exploiting SSTI — Twig

In this section we’ll examine a different instance of Server-Side Template Injection exploitation, shifting our focus from the previously covered Jinja examples to the Twig templating engine. As before, we’ll concentrate exclusively on exploitation techniques and operate under the assumption that the SSTI vulnerability has already been confirmed and the template engine identified in earlier steps. Twig is a templating system used primarily with PHP applications; because it runs in a different language and runtime, the available payloads, syntax and exploitation approaches will differ from those used against Jinja, so engine-specific knowledge is important when crafting and testing exploits.

Exploit the SSTI vulnerability to obtain RCE and read the flag.

Open the page and insert the text bellow:

{{ ['cat /flag.txt'] | filter('system') }}

And get the flag.

Exploiting SSI Injection

Now that we’ve explained how Server-Side Includes (SSI) operate in the previous section, we’ll move on to examine how to exploit SSI injection vulnerabilities — covering practical attack techniques, typical payloads and the conditions that make exploitation possible.

Exploit the SSI Injection vulnerability to obtain RCE and read the flag.

Open the page and use the text bellow:

<!--#exec cmd="cat /flag.txt" -->

Click on Submit button and get the flag.

Exploiting XSLT Injection

Having reviewed the fundamentals and typical use cases of XSLT in the previous section, we will now turn our attention to exploiting XSLT injection vulnerabilities — examining practical attack techniques, example payloads, and the environmental conditions that allow such exploits to succeed.

Exploit the XSLT Injection vulnerability to obtain RCE and read the flag.

Open the page and click on the Send button. Intercept the request with Burp Suite.

Right click on it and choose Send to Repeater

Use the requesto to get the flag.

GET /index.php?name=<xsl%3avalue-of+select%3d"php%3afunction('system','cat+/flag.txt')"+/>+HTTP/1.1

Skills Assessment

Scenario

You must perform a security assessment of a client’s web application. Apply what you learned in this module to locate and retrieve the flag, operating strictly within the agreed scope.

Obtain the flag.

Open the page and intercept the request.