Yaamlabs
Case study 14

Document access and guessable reset links

Government contracting

A supplier portal let organisations download documents and reset their own passwords. We were asked whether a document could be pulled by the wrong organisation, and whether a reset link could be anticipated.

Web & API penetration test, Public sector supplier, severity HIGH, reported 2024

At a glance

  • Challenge. Downloads checked login but not ownership, and reset tokens moved predictably, putting other organisations' documents and accounts at risk.
  • Approach. We fetched one organisation's document from another's account and requested several reset links to see whether the tokens could be predicted.
  • Result. Downloads now enforce ownership on the resolved file, reset tokens are long, random, single use and short-lived, and both flows were retested.
  • Impact. One organisation on the portal could have downloaded another's documents, and an attacker could have generated a valid reset link to take over an account.
  • Classification. CWE-640 Weak Password Recovery Mechanism for Forgotten Password, OWASP Top 10 (2021): A07 Identification and Authentication Failures. Component: Document downloads and password reset tokens.

The challenge

A download link that checks only that you are logged in, and not that the document is yours, hands out a catalogue whose entries differ by a number. The organisations on the portal are separated by that check, and when it is missing they are not separated at all.

A password reset link is a temporary key. Its safety depends entirely on being unguessable. When the token is built from a value that can be predicted, the current time, a counter, a short sequence, then the key can be made rather than intercepted, and account recovery becomes account takeover.

Neither weakness announces itself. A predictable token is a valid token. A missing ownership check is a successful download. The system reports success in both cases, which is the difficulty.

Our approach

We used two organisation accounts to test whether a document issued to one could be fetched by the other, and we requested several reset links to see whether the tokens moved in a way that could be predicted.

Around those findings we checked the surface that shared the assumption:

  • Whether document downloads enforced ownership on the resolved file
  • Whether reset tokens were long, random and single use
  • Whether tokens expired promptly and were invalidated after use
  • Whether other links carrying identifiers shared the ownership gap

Delivered with the requests and the tokens observed, so each finding could be reproduced against test accounts without taking our word for it.

From finding to fix

  1. Fetched a document as another organisation
  2. Requested several password reset links
  3. Found the reset tokens predictable
  4. Enforced ownership and randomness, retested

The outcome

Document downloads now enforce ownership on the resolved file, and reset tokens were moved to long random values that are single use and expire promptly, so a link can no longer be anticipated or replayed.

We retested the download surface and the reset flow after the fix. Reported as HIGH in 2024. Retest included in the engagement.

Check your own system

  • Request several reset links in a row for a test account and compare the tokens for any shared prefix, timestamp or counter.
  • Generate reset tokens from a cryptographically secure random source, store only a hash, and invalidate them on use and on a short expiry.
  • Download a document as one organisation, then request the same file identifier from another organisation's account and confirm it is refused.
  • Check every other link that carries an identifier, such as exports and attachments, for the same ownership check on the resolved object.

Read more case studies, see Web Application Penetration Testing, or write to hello@yaamlabs.com.