Chained Vulnerabilities in Web Applications

Introduction

Vulnerability chaining, also known as exploit chaining, is the process of combining multiple vulnerabilities to achieve a more significant or impactful attack. In complex systems, real-world attacks often involve multiple steps and understanding, and mitigating chains is crucial for realistic security assessments.

Before reading this article, it is recommended that you are already familiar with basic web application attacks.

Content

CSRF & XSS

XSS is a dangerous vulnerability because breaks CSRF protections, making all mitigations for CSRF irrelevant. People sometimes focus only on CSRF mitigations, but don’t let XSS attacks to pass!

XSS attacks can:

read CSRF token
send authenticated requests
runs in same origin

Below I will explain how these 2 can be chained together using CSRF as a delivery method and XSS as execution. CSRF bypasses authentication barrier and converts victim’s privileges into attacker’s injection vector.

CSRF + XSS

CSRF is used as delivery method to perform a XSS in the victim browser. This is very impactful because it does not require authentication and could be used in places that requires more privileges.

For example let’s say we have a forum section used just for admins. You do not need access in the website at all to deliver the vulnerability. The CSRF payload is sent to the victim which is an admin on the website. Once accessed, it will POST request a comment with the Stored XSS payload that will grab the admins’ sessions for the attacker.

Stealth Delivery + CSRF/XSS

Another chaining similar to this one is to use a stealthier method for your malicious requests. In this case is rather about a cross-site request delivery. The initial malicious URL has the same impact, but different websites can be used as the delivery method.

Instead of clicking https://vulnerable.com/abc<script>sent-me-your-cookies</script> you would click an attacker controlled URL that seems normal https://not-malicious.com/. When is accessed, it will trigger the Reflected XSS request to the vulnerable website.

Another case is to use the delivery method in a vulnerable visited website by the victim. If the attacker found a vulnerability in a popular page (site A) that would allow the attacker to redirect the victim, it could trigger the Reflected XSS or CSRF to the vulnerable targeted website (site B). In this scenario, the victim does not need to click a malicious link, is just attacked by a legitimate website once visited.

This delivery can be done through HTML injections, malicious Ads, a compromised widget, third-party scripts etc.

As an example, the malicious code could be something like this:

<img src="https://victim.com/delete_account"> //the source being a CSRF GET URL

XSS + XSS

Similar with the previous one, a website A can contain vulnerable JS code as Stored XSS that will inject malicious JS code to a second website B. In this case, there are chained 2 vulnerable websites to perform a more stealth and impactful attack.

File Upload -> XSS

Using an Unrestricted File Upload vulnerability, malicious scripts can be uploaded on the server and used to execute JavaScript code in the victim’s browser. This is helpful when the script becomes too large to be written in one line.

Then, using a HTML Injection, the victims could be redirected to the vulnerable file uploaded that executes JS code in the browser.

File Upload -> RCE

Sometimes a File Upload could lead to RCE because an attacker can upload a file that is executable by the web application, such as a web shell or reverse shell. The attacker needs to know the location of the file uploaded and the configuration of the server.

The most common scenario is the application based on PHP server. The attacker uploads a webshell.php and gets RCE if the code is executed. Depending on the environment, the attacker needs to use different payloads, for example:

.aspx for Microsoft IIS (ASP.net)
.jsp for Apache Tomcat (Java)
.js for Node.js
and others

Is important to check whether the executable is running with the expected extension or not.

File Upload + File Inclusion

If the malicious file uploaded is not executed by the browser when the path is visited, a file inclusion vlunerability could be used to execute the code from the file.

In some cases if the web application allows files to be uploaded as “test.php.png”, a file inclusion vulnerability could execute the file as PHP. The path to the file uploaded is required.

An example of such file is presented below. If the URL to the file is visited, the web application will try to return an image, so the file can not be executed as PHP, but can be executed if is included in the page.

RFI -> RCE

RFI in most of the cases goes to RCE, because a reverse shell can be hosted on another domain and this can be executed from the target through the RFI payload. What should be tested is if the file is included in the page and if the code is executed.

Open Redirect -> CSRF

Open Redirect can be used to hide the vulnerable URL, making it longer (if is based on GET request). If is based on a POST request, the redirect can be done to an intermediate website controlled by the attacker that is then making the CSRF attack.

Access https://vulnerable.com/dashboard?redirect=https://not-malicious.com/
https://not-malicious.com/ makes the CSRF attack back to https://vulnerable.com/

XXE -> SSRF

XXE injections could perform SSRF attacks if the malicious XML entity is configured to reference a URL instead of a local file system path. This induces the XML parser on the server to make an HTTP request to an internal or external resource, allowing the attacker to interact with backend systems.

			
/** Original request: **/
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
  <!ENTITY xxe SYSTEM "https://internal-service.local/resource">
]>
<root>
  <data>&xxe;</data>
</root>
/** Malicious request: **/
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
  <!ENTITY xxe SYSTEM "http://localhost:8443/admin">
]>
<root>
  <data>&xxe;</data>
</root>

		

XXE -> RCE

Under specific conditions XXE can lead to RCE. This can happen in different cases, for example:

if a local file with executable code can be included
if injection is possible into a file that is then executed by the server
through vulnerable server components, libraries or extensions

SQL Injection -> RCE

If SQL injection is present, sqlmap tool can be used with –os-cmd flag, to execute commands, or –os-shell and –os-pwn to spawn a reverse shell.

In order for this flags to work, the database user must have sufficient privileges to execute commands that interact with the underlying operating system. If all conditions are fulfilled, the sqlmap will provide command execution on the server.

Clickjacking + DOM XSS

Clickjacking can be combined with DOM XSS as the JS code is executed in the iframe of the vulnerable web application. The victim press a button and consequently executes the DOM XSS attack.

Host Header Injection + Password Reset

Host Header Injection is not rated as a high risk, but could become dangerous if is chained with other functionalities. For example if the application uses the Host header value to construct the password reset URL for “Forgot password” functionality. An attacker could manipulate this to redirect victim to a malicious domain, leading to account takeover.

Original link:
https://example.com/reset_password?token=22554

Host Header Injection in POST request:
POST /reset_password HTTP/1.1
Host: example.com (change to attacker.com)

email=john.doe@victim.com

The link received on email:
https://attacker.com/reset_password?token=22554

If the email parameter is not available, the attack must be performed using Man-In-The-Middle or HTTP Request Smuggling technique.

LFI + Log Poisoning -> RCE

If a LFI vulnerability exists on a web application and an attacker is also able to inject malicious code into a log file, this could lead to a RCE. For example, using LFI an attacker reads the logs from the server and finds one that stores the User-Agent. A PHP code is injected in User-Agent and stored in the log file. Using LFI the log is included in the page with the PHP code executed.

This example can be seen in the next screenshots:

Conclusion

Chained vulnerabilities in web applications occur when multiple security flaws are combined to escalate the severity and impact of an attack. Individually, these vulnerabilities might have limited impact, but when exploited together, they can lead to significant security breaches. Understanding and identifying these chains is important for security professionals to protect web applications effectively and for developers to implement comprehensive security measures.

Keep in mind that this article only provides a brief introduction to chained attacks, and their successful exploitation depends on many factors.