Summary
When interacting with modern web applications, we need to be aware that multiple machines and components are likely involved in the process. There may be intrusion detection/prevention systems, content delivery networks for better performance, load balancers, reverse proxies, other application servers, template engines, and database servers between us and the application server. As you can imagine, the IP associated with the domain name may have nothing to do with the actual application server. When we issue HTTP requests to a target application, all the machines and components involved in the process do not simply pass requests through but also interpret them in order, for example, to apply restrictions or identify and block attacks.
At this point, we need to consider the below:
- Do those intermediary machines and components interpret and treat the requests the same way the final application server does? If not, this could be the root cause of a security issue.
- Do those intermediary machines and components perform (enough) validation before the user request hits the final application server? If not, this could also be the root cause of a security issue.
The attack scenarios mentioned above leverage the trust between the final application server and the intermediary machines and components. However, there are scenarios where server-side attacks can be executed against the hosting server itself without the interference of any intermediary machines and components, leveraging the trust between the server and itself. In the latter scenarios, a URL is usually passed with a hostname of 127.0.0.1 or localhost.
From a penetration tester's perspective, it is worth checking for inefficiencies in how user requests are being treated or validated from these types of intermediary machines and components or the application server itself since they can lead to severe information leakage or even remote code execution.
This module will discuss the basics of identifying and exploiting server-side bugs.
This module is broken into sections with accompanying hands-on exercises to practice each of the tactics and techniques we cover. The module ends with a practical hands-on skills assessment to gauge your understanding of the various topic areas.
You can start and stop the module at any time and pick up where you left off. There is no time limit or "grading," but you must complete all of the exercises and the skills assessment to receive the maximum number of cubes and have this module marked as complete in any paths you have chosen.
As you work through the module, you will see example commands and command output for the various topics introduced. It is worth reproducing as many of these examples as possible to reinforce further the concepts presented in each section. You can do this in the PwnBox provided in the interactive sections or your virtual machine.
The module is classified as "Medium" and assumes a working knowledge of the Linux command line and an understanding of information security fundamentals. The module also assumes basic knowledge of web applications and web requests. It will build on this understanding to teach how server-side bugs can be exploited.
In addition to the above, a firm grasp of the following modules can be considered as prerequisites for the successful completion of this module:
- Linux Fundamentals
- Web Requests
- Introduction to Web Applications
- Using Web Proxies
- Cross-Site Scripting (XSS)
Introduction to Server-Side Attacks
Server-Side attacks target the application or service provided by a server, whereas the purpose of a client-side attack is to attack the client. Understanding and identifying the differences is essential for penetration testing and bug bounty hunting.
An excellent example of these that should help clarify the differences between server-side attacks vs. client-side attacks are Cross-Site Request Forgeries (CSRF) and Server-side Request Forgeries (SSRF). Both of these attacks involve a web server and how servers process URLs. However, CSRF and SSRF have different targets and purposes.
Roughly quoted from the Cross-Site Request Forgery section in the Introduction to Web Applications module:
CSRF attacks may utilize other client side -attacks like XSS vulnerabilities to perform requests to a web application that a victim has already been authenticated to. This allows the attacker to perform actions as the authorized user, such as changing their password to something the attacker would know or performing any unwarranted action as the victim.
From the above situation, we should be able to infer that the target is the client. Server-Side attacks target the actual application, the objective being to leak sensitive data or inject unwarranted input into the application and even achieve remote code execution (RCE). The targets in this situation are the back-end services.
Types of Server-Side Attacks
This module will cover different types of Server-Side attacks and how to exploit them. These are:
-
Abusing Intermediary Applications: Accessing internal applications not accessible from our network by leveraging specific exposed binary protocols. -
Server-Side Request Forgery (SSRF): Making the hosting application server issue requests to arbitrary external domains or internal resources in an attempt to identify sensitive data. -
Server-Side Includes Injection (SSI): Injecting a payload so that ill-intended Server-Side Include directives are parsed to achieve remote code execution or leak sensitive data. This vulnerability occurs when poorly validated user input manages to become part of a response that is parsed for Server-Side Include directives. -
Edge-Side Includes Injection (ESI): ESI is an XML-based markup language used to tackle performance issues by temporarily storing dynamic web content that the regular web caching protocols do not save. Edge-Side Include Injection occurs when an attacker manages to reflect ill-intended ESI tags in the HTTP Response. The root cause of this vulnerability is that HTTP surrogates cannot validate the ESI tag origin. They will gladly parse and evaluate legitimate ESI tags by the upstream server and malicious ESI tags supplied by an attacker. -
Server-Side Template Injection (SSTI): Template Engines facilitate dynamic data presentation through web pages or emails. Server-Side Template Injection is essentially injecting ill-intended template directives (payload) inside a template, leveraging Template Engines that insecurely mix user input with a given template. -
Extensible Stylesheet Language Transformations Server-Side Injection (XSLT): XSLT is an XML-based language usually used when transforming XML documents into HTML, another XML document, or PDF. Extensible Stylesheet Language Transformations Server-Side Injection can occur when arbitrary XSLT file upload is possible or when an application generates the XSL Transformation’s XML document dynamically using unvalidated input from the user.
Moving On
Let's now dive into each attack in detail.
