Exploiting Misconfigurations and Authorization Vulnerabilities

This article discusses the exploitation of multiple misconfigurations and authorization vulnerabilities in a multinational company's Content Management System (CMS).

Target Background

The target organization operated a CMS platform used for managing product and service content across multiple public web properties.

The application was built using ReactJS and leveraged AWS Cognito for authentication.

Published content was automatically pushed to the live production websites associated with various business units.

Overview

The application did not expose a public sign-up workflow.

Only administrators were intended to create users and assign roles internally.

The home page only presented a login form without any visible registration capability.

Reconnaissance

Initial reconnaissance identified the following technologies:

• ReactJS
• Amazon CDN
• REST APIs
• AWS Cognito

Source File Analysis

Analysis of the loaded JavaScript bundles did not immediately reveal accessible REST API endpoints.

To extend reconnaissance, URL fuzzing techniques were used against the application paths.

This process revealed a hidden registration endpoint:

https://abc.com/abc/xyz/signup.html

Misconfiguration #1 — Hidden Signup Workflow

Although the application did not expose a visible signup interface, the backend functionality remained enabled.

The endpoint allowed arbitrary account creation without:

• Email verification
• Administrative approval
• Additional validation workflows

After registration the application authenticated successfully, however access to internal CMS pages was denied.

Further inspection confirmed that authentication succeeded, but authorization failed due to missing user roles.

JWT Analysis

Upon successful login the application issued a JWT token through the response headers.

Decoding the JWT revealed empty Cognito permission groups.

{
  "sub": "e03f561e-9392-437d-abf7",
  "cognito:groups": [
    ""
  ],
  "cognito:username": "test",
  "cognito:roles": [
    ""
  ],
  "email": "nj@tvhsecurity.com"
}

The token proved that authentication was successful while authorization roles were absent.

JWT Fuzzing

Several attempts were made to modify the JWT payload by injecting arbitrary Cognito role values.

However the modified tokens failed validation and did not grant additional access.

Extracting Internal URLs

Using the valid authorization token, the frontend source files were downloaded and analyzed further.

Embedded URLs were extracted using custom tooling and automated reconnaissance techniques.

The following tools were used:

• curl
• HTTPX
• URLScrapy

HTTP Response Analysis

Extracted URLs were processed through HTTPX in order to identify pages with anomalous response lengths.

One particular page exposed static role information related to internal CMS authorization logic.

The following roles were identified:

• editor
• publisher

Editors could create and modify content while publishers could approve deployments.

Checkpoint

At this stage the following components were available:

• Valid authenticated account
• JWT authorization token
• Knowledge of internal role names
• Frontend application source files

Authorization Bypass

During experimentation with browser developer tools a local storage variable named user_role was identified.

The variable existed but remained empty for newly created accounts.

By manually setting:

localStorage.setItem("user_role", "editor")

and refreshing the page, the application granted editor-level access.

Authorization decisions were being performed entirely through client-side local storage values.

Misconfiguration #2 — Broken Authorization

The application used AWS Cognito groups only for authentication validation but failed to enforce them server-side for authorization.

The backend APIs trusted client-side role values supplied by the frontend application.

As long as a valid JWT token existed, arbitrary role escalation became possible.

Privilege Escalation

Changing the local storage value from:

editor

to:

publisher

granted full publisher-level privileges after page refresh.

This enabled:

• Approving content
• Publishing changes
• Rejecting submissions
• Accessing privileged CMS workflows

Impact

• Unauthorized account creation
• Authentication bypass conditions
• Privilege escalation
• Publisher-level access
• Unauthorized content modification
• Potential production content compromise

Root Cause

• Hidden legacy signup endpoint
• Improper authorization enforcement
• Client-side trust assumptions
• Missing server-side role validation
• Reliance on local storage for authorization

Conclusion

Applications should never rely on client-side storage values for authorization decisions.

All authorization logic must be validated server-side using trusted identity providers and immutable permission checks.

Combined with hidden registration functionality, the weak authorization implementation enabled full privilege escalation inside the CMS environment.

Thank you for reading.