From Demo to Full Access: How One Simple Step Leads to 3 Security Vulnerabilities

Introduction

When starting a security assessment, we did not initially have any privileges on the application. The only entry point available to us was the application's Demo environment.

At first glance, the Demo appeared to be heavily restricted. Users were not supposed to have access to the application's signup functionality, which significantly limited the available attack surface.

However, instead of stopping at the visible functionality, we started looking at how the application handled different paths and access points.

This led us to an unexpected discovery.

By manipulating the application path, we were able to reach a login page that was not directly exposed through the Demo. From there, a simple change in the path allowed us to access the Signup functionality and create our own account.

What initially looked like a simple forced browsing issue eventually became the starting point for discovering three separate security vulnerabilities:

• Forced Browsing — Accessing the Signup Panel

• Broken Function Level Authorization via client-side trust

• Stored Cross-Site Scripting (XSS)

In this article, we will walk through the entire discovery process and show how a single seemingly simple finding allowed us to move from a restricted Demo environment to accessing functionality that was intended to be available only to privileged users.

The Discovery

Before diving into the individual vulnerabilities, let's understand how we moved from a restricted Demo environment to discovering multiple vulnerabilities.

The first thing we noticed was that the application did not provide a normal way for users to create an account.

This is common in Demo environments: the application may allow visitors to explore specific functionality while restricting registration and authenticated features.

However, instead of relying only on the functionality exposed by the interface, we started testing how the application handled different paths.

1. Forced Browsing — Accessing the Signup Panel

The first breakthrough came from testing different application paths.

By experimenting with different paths and attempting to navigate to locations that were not directly exposed through the Demo, we eventually reached the application's Login page.

Once we reached the Login functionality, we noticed something interesting: the application used a predictable path structure.

Instead of continuing with the existing Login path, we tested whether the same functionality existed under a Signup path.

We changed:

/login

to:

/signup

To our surprise, the Signup page was accessible.

This allowed us to create an account even though the Demo itself did not provide an obvious way to register.

At this point, we had successfully moved from an unauthenticated Demo environment to an authenticated user account.

But this was only the beginning.

2. Broken Function Level Authorization via client-side trust

After successfully creating an account and logging in, we started exploring the functionality available to our newly created user.

Initially, the account had access to only two functions.

We could access these functions normally, but the rest of the application's functionality was not exposed to our account.

However, while analyzing the application's requests and responses, we noticed that access to functionality appeared to depend on information returned in the server response.

This led us to test whether manipulating the response could affect the functionality available to our account.

We modified the relevant response values and observed how the application's frontend reacted.

By manipulating the response, we were able to make functionality that was originally hidden from our account become accessible.

Using Match and Replace in Burp Suite Choice Response body From `False` To `True`

The exposed panels were not merely cosmetic. The server accepted and processed the resulting create, edit, and delete requests without performing any server-side authorization check — the tampered response only revealed functionality the backend was already willing to execute for an unprivileged account.

This included functionality that appeared to be intended for administrators or privileged users.

The important part was that the application was relying on client-side response data to determine which functionality should be available instead of enforcing the authorization checks securely on the server side.

Once this was bypassed, several additional panels became accessible.

Accessing File Management Functionality

One of the panels exposed functionality related to files uploaded to the application.

We were able to view uploaded files and perform actions that should not have been available to our account.

These actions included:

• Viewing uploaded files

• Adding files

• Editing files

• Deleting files

This significantly expanded the level of access available to our account.

Accessing Location Management

Another privileged panel that became accessible was the Location Management functionality.

The panel allowed us to:

• View existing locations

• Create locations

• Edit locations

• Delete or manage locations

At this point, the impact of the response manipulation became much more significant.

What initially appeared to be a restricted Demo account had now gained access to functionality that was intended for privileged users.

3. Stored Cross-Site Scripting

After obtaining full control over the Location functionality, we started testing whether user-controlled fields were properly sanitized.

Since we had the ability to create and modify locations, we focused on the fields that accepted arbitrary text.

One field immediately stood out as a potential injection point.

We tested whether JavaScript could be stored inside the Location data.

After injecting a JavaScript payload, the application accepted and stored the value without properly sanitizing it.

The payload was then rendered when users accessed the affected Location.

This confirmed that the application was vulnerable to Stored Cross-Site Scripting (Stored XSS).

Because the payload was stored on the server, the attack was not limited to the user who submitted it.

Any user who later visited the affected Location could have the malicious JavaScript executed in their browser.

Depending on the victim's privileges and the application's security controls, this could allow an attacker to perform actions in the victim's context, access information available to the browser session, or manipulate the application's interface.

From One Simple Step to Multiple Vulnerabilities

At this point, the attack chain became clear.

The vulnerabilities were not isolated findings. They could be chained together:

Restricted Demo ↓ Forced Browsing ↓ Signup Panel ↓ Create User Account ↓ Response Manipulation ↓ Unauthorized Privileged Functionality ↓ Location Management ↓ Stored XSS

What started as a restricted Demo environment eventually led to access to functionality that was not intended for our account and ultimately allowed us to store JavaScript that executed in the browsers of users visiting the affected Location.

This demonstrates an important security principle: vulnerabilities that may initially appear to have limited impact can become significantly more dangerous when combined with other weaknesses in authentication, authorization, and input validation.

Security Impact

The combination of these vulnerabilities created a significantly larger attack surface than any individual issue would suggest.

The identified issues allowed us to:

• Reach the application's Signup functionality despite it not being exposed through the Demo.

• Create an authenticated user account.

• Manipulate application responses to expose functionality intended for privileged users.

• Access functionality for managing locations and uploaded files.

• Create and modify locations.

• Store malicious JavaScript that executed when other users visited the affected Location.

The final Stored XSS vulnerability could potentially be used to perform actions in the context of other users, depending on their privileges and the application's security controls.

The overall impact therefore came from chaining multiple weaknesses together, rather than relying on a single vulnerability.

Root Cause

The vulnerabilities originated from multiple security control weaknesses.

1. Insufficient Access Validation

The application did not properly restrict access to sensitive application paths, allowing us to reach functionality that was not intended to be exposed through the Demo.

2. Client-Side Access Control

The application relied on response data to determine which functionality should be available to the current user.

Because this information could be manipulated on the client side, privileged functionality could be exposed without sufficient server-side authorization enforcement.

3. Insufficient Input Sanitization

The Location functionality accepted user-controlled input without properly encoding or sanitizing it before rendering it to other users.

This allowed JavaScript to be stored and subsequently executed in victims' browsers.

Mitigation

To prevent similar attack chains, applications should implement security controls at multiple layers.

Access Validation

Sensitive application paths should not be accessible simply because a user can guess or manipulate their URL.

Authorization should be enforced server-side for every protected endpoint.

Server-Side Authorization

The server should never rely on frontend logic or response manipulation to determine whether a user is authorized to perform an action.

Every sensitive operation should independently verify:

• User identity

• User role

• Resource ownership

• Required permissions

Input Validation and Output Encoding

All user-controlled input should be properly validated and contextually encoded before being rendered.

For HTML contexts, applications should use appropriate output encoding and avoid directly inserting untrusted input into executable contexts.

A strong Content Security Policy (CSP) can also provide an additional layer of defense against XSS.

Lessons Learned

One of the most important lessons from this research was that the initial attack surface does not always represent the actual attack surface.

A Demo environment may appear to expose only a few functions, but hidden paths, weak authorization controls, and client-side security decisions can expose significantly more functionality.

The most interesting part of this assessment was not discovering each vulnerability individually, but understanding how they could be connected.

A simple path discovery led to account creation.

Account creation led to authenticated functionality.

Response manipulation exposed privileged functionality.

Privileged functionality provided control over a location.

And that functionality ultimately became the injection point for Stored XSS.

This is why security testing should not focus only on individual endpoints. Understanding how different application components interact can reveal attack chains that would otherwise remain unnoticed.

Conclusion

What started as a restricted Demo environment turned into a deeper security investigation that uncovered three interconnected vulnerabilities.

The experience highlights an important lesson for both security researchers and developers:

A small weakness can become a serious security issue when it is combined with other weaknesses in the application's security model.

For security researchers, this means that discovering one weakness should often be treated as a starting point rather than the end of the investigation.

For developers, it demonstrates why authentication, authorization, input validation, and server-side security controls must work together instead of relying on individual layers of protection.