# Introducing Proxy Enriched Sequence Diagrams (PESD)

Internal AWS API Gateway endpoint issuing impersonation sessions lacked authn/authz, letting any VPN-connected employee obtain access tokens for any web-facing platform user.

- Payout: Research
- Severity: high
- Program: Internal admin platform
- Write-up by: Doyensec
- Disclosed: 2023-02-13
- Write-up quality: 6/10
- Original: https://blog.doyensec.com/2023/02/14/pesd-extension-public-release.html
- Library page: https://bugbountylibrary.com/r/blog%3Ablog-doyensec-com-2023-02-14-pesd-extension-public-release-html
- Tags: area:cloud domain:cloud domain:web impact:ato impact:internal-access impact:privesc kind:research platform:research sev:high tech:aws technique:source-review vuln:access-control vuln:auth-bypass

**Target:** AWS API Gateway endpoint backed by Lambda issuing impersonation sessions
**Root cause:** The Lambda-backed API Gateway endpoint that mints impersonated sessions did not enforce authentication or authorization of the caller; grant checks were only done in the separate internal app handler.
**Steps:**
1. Authenticate to internal super-admin app and request impersonation of a target user; handler (1) checks tenant access grant and returns redirect URL to internal AWS API Gateway endpoint.
2. Call the API Gateway endpoint (3) directly with URL params `tenantId`, `user_id`, etc.; Lambda returns `access_token`, `refresh_token`, `user_id` without checking caller auth or grant.
3. Submit returned auth details to web-facing.platform.com (5) to set session as the target user.
**How found:** Sequence-diagram analysis of the impersonation flow revealed the authz check (request 1) was decoupled from session creation (request 3), prompting direct invocation of the internal API.
**Exploitation:** Any employee on the VPN skips the internal app's grant check by invoking the API Gateway endpoint directly with arbitrary tenantId/user_id, receiving valid impersonation tokens and setting a session on the web-facing platform as any user.
**Insight:** When a flow splits authorization (front handler) from the privileged action (backend API), test the backend endpoint directly — internal-network-only exposure is not an auth boundary.