Session reuse in a donation flow
Nonprofit
A donation platform took one-off and recurring gifts and let donors manage their details. We were asked whether a session could outlive its owner, and whether card data was handled the way donors would expect.
Web & API penetration test, Nonprofit donation platform, severity HIGH, reported 2024
At a glance
- Challenge. Donor sessions could outlive sign-out and were not renewed at sign-in, and card data rested on the platform instead of staying with the payment provider.
- Approach. We watched how sessions were created, changed and ended, reused a session that should have ended, and followed card data to where it came to rest.
- Result. Sessions renew at sign-in and privilege change and end server-side at logout and expiry, card data stays with the provider, and both flows were retested.
- Impact. Anyone holding a donor's old session token could have kept acting as that donor after sign-out, and card data sat on a platform never built to hold it.
- Classification. CWE-613 Insufficient Session Expiration, OWASP Top 10 (2021): A07 Identification and Authentication Failures. Component: Donor session handling and card data flow.
The challenge
A session is a statement that this request comes from the person who signed in. If the token that carries the session is not tied to that sign in, does not change when privilege changes, or does not end when the donor logs out, then the statement can be true for the wrong person. A session that can be fixed or reused is a door that does not lock behind you.
Card data raises a separate expectation. Donors assume their card is handled by the payment provider and never rests on the platform. When card details pass through or are retained where they should only transit, the platform has quietly taken on a responsibility, and a risk, that it was not built to carry.
Both problems are invisible in the happy path. The donation succeeds either way. The question is what else the same mechanism allows.
Our approach
We examined how sessions were created, changed and ended, and whether a token remained valid when it should not. We followed the card data to see where it travelled and whether it rested anywhere it should only pass through.
Around those findings we checked the surface that shared the assumption:
- Whether the session token was renewed at sign in and privilege change
- Whether logout and expiry actually invalidated the session server-side
- Whether card data was confined to the payment provider
- Whether donor detail changes required a current, authenticated session
Delivered with the requests and the session behaviour observed, so each finding could be reproduced against a test account without taking our word for it.
From finding to fix
- Examined how sessions began and ended
- Reused a session that should have ended
- Traced card data past the provider
- Renewed sessions, confined cards, retested
The outcome
Session tokens are now renewed at sign in and privilege change and are invalidated on logout and expiry server-side, so a token cannot be fixed or reused. Card handling was confined to the payment provider so card data no longer rests on the platform.
We retested the session and donation flows after the fix. Reported as HIGH in 2024. Retest included in the engagement.
Check your own system
- Sign out, replay a request with the old session cookie, and confirm the server rejects it.
- Issue a new session identifier at sign-in and at every privilege change, and check that the earlier identifier stops working.
- Put a test donation through an intercepting proxy and confirm the card number goes only to the payment provider, never to your own servers, logs or database.
- Require a current, authenticated session before donor details or recurring gifts can be changed.
Read more case studies, see Web Application Penetration Testing, or write to hello@yaamlabs.com.