Account Takeover Through Manipulation of Session Storage

This article explores account takeover through manipulation of session storage values in a financial web application.

Target Background

The target application was designed for financial workflows including invoice generation, payment tracking, and reconciliation operations.

Users could create organizations, invite members, and assign roles for collaborative financial management.

Overview

A test account was created to evaluate the application's authentication and authorization logic.

After login, the application required users to create an organization and assign team roles.

Reconnaissance

• ReactJS frontend
• Akamai WAF
• REST APIs
• Cookie-based authentication

User Enumeration

During authentication the application performed a user verification request based on the supplied email address.

Request

GET /api/v1/user?email=nj@tvhsecurity.com HTTP/2
Host: www.target.com
Cookie: session=blahblah

Response

{
  "status": true,
  "message": "Successfully Retrieved",
  "result": [
    {
      "UserId": 601XXX,
      "EmailId": "nj@tvhsecurity.com",
      "RoleName": "Admin",
      "CountryName": "India",
      "Status": "Approved",
      "IsActive": true
    }
  ]
}

The API exposed excessive user metadata during the login workflow.

Post Login Analysis

Further analysis of browser storage revealed that the application stored user information inside session storage.

The stored values matched the response returned from the user verification API endpoint.

Theory

The application relied on encrypted cookies for authentication, however authorization logic appeared dependent on session storage values.

To validate the theory, a second legitimate user account was created for testing.

The objective was to determine whether replacing session storage values would impersonate another user account.

Extracting User Data

A second verification request was issued using another user's email address.

GET /api/v1/user?email=nj+1@tvhsecurity.com HTTP/2
Host: www.target.com

The returned JSON response contained the complete user object required for impersonation.

Session Storage Manipulation

The extracted JSON payload was copied into the session storage value associated with the login key.

After refreshing the page, the application granted access to the second user's account.

OSINT Reconnaissance

To validate the issue against a real-world account, OSINT reconnaissance was performed against the target organization.

Corporate email addresses were collected from:

• Public contact pages
• GitHub repositories
• Issue tracker comments
• Developer discussions

GitHub Recon

GitHub issue comments revealed valid employee email addresses associated with the organization.

The discovered email addresses were tested using Intruder to identify valid accounts through content-length variations.

Verify User

Request

GET /api/v1/user?email=baXXXXXX@target.com HTTP/2
Host: www.target.com

Response

{
  "status": true,
  "message": "Successfully Retrieved",
  "result": [
    {
      "UserId": 10XXX,
      "EmailId": "baXXXXXX@target.com",
      "RoleName": "Admin",
      "CountryName": "United States",
      "Status": "Approved"
    }
  ]
}

Checkpoint

• Valid user email identified
• User metadata extracted
• Session storage structure understood
• Authorization trust assumptions confirmed

Extracted Session Value

{
  "UserId": 10XXX,
  "EmailId": "baXXXXXX@target.com",
  "RoleName": "Admin",
  "CountryName": "United States",
  "Status": "Approved"
}

The above JSON object was inserted into session storage in order to impersonate the target user.

Exploitation

After replacing the session storage value and refreshing the application, full access to the victim account was obtained.

The application exposed:

• Invoices
• Financial records
• User information
• Administrative functionality

Impact

• Account Takeover
• Privilege escalation
• Unauthorized financial access
• User impersonation
• Exposure of sensitive business data
• Potential invoice manipulation

Root Cause

• Trusting client-side session storage
• Broken authorization model
• Excessive API data exposure
• User enumeration vulnerability
• Improper session validation

Conclusion

Authorization decisions should never rely on mutable client-side storage mechanisms such as sessionStorage or localStorage.

Applications must validate user identity and permissions server-side using trusted session state and immutable authorization checks.

Combined with user enumeration and excessive metadata exposure, the flawed authorization design enabled full account takeover against legitimate users.

Thank you for reading.