> For the complete documentation index, see [llms.txt](https://ganesha-hk.gitbook.io/cybersecurity-writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ganesha-hk.gitbook.io/cybersecurity-writeups/port-swigger-access-control-labs/lab-8.md). # lab-8 ## User ID Controlled by Request Parameter with Data Leakage in Redirect **Difficulty:** Apprentice ### Lab Description This lab contains an access control vulnerability where sensitive data is leaked in the body of a redirect response. Even though the server correctly redirects unauthorised requests to the login page, it generates and includes the sensitive page content in the response body before doing so. **Objective:** Obtain the API key for the user `carlos` and submit it as the solution. **Credentials:** `wiener:peter` ### Solution **Step 1 — Identify the account endpoint** Log in as `wiener:peter` and capture the requests in Burp. The account page URL is: ``` GET /my-account?id=wiener ``` Send this request to Repeater. **Step 2 — Confirm session validation exists — but is flawed** Remove the session cookie and send the request. Unlike earlier labs, the server does check the session — the response is a `302` redirect to `/login`. It appears the application is properly enforcing authentication. However, look carefully at the **body** of the `302` response. It contains the fully rendered HTML of the account page, including the user's email and API key — despite the redirect. The flaw is in the execution order on the server: ``` Request received ↓ Load user data from database ↓ Render full HTML page ↓ Check session validity ← access control check happens here, too late ↓ Return 302 redirect ← but the rendered HTML is already in the body ``` The data is included in the redirect response before it is discarded, and Burp (unlike a browser) shows the full response body regardless of the status code. **Step 3 — Extract carlos's API key** Change the parameter to `id=carlos` and send the request (without a session cookie): ``` GET /my-account?id=carlos ``` Inspect the response body of the `302` redirect — it contains Carlos's rendered account page with his API key. Copy and submit it to complete the lab. ### Conclusion The application performed the access control check too late in the request lifecycle — after the sensitive data had already been loaded and rendered into the response body. A browser would follow the redirect and never display the leaked content, but an attacker using Burp or any HTTP client can read the full response. Access control checks must happen **before** any user data is loaded or rendered, not after. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://ganesha-hk.gitbook.io/cybersecurity-writeups/port-swigger-access-control-labs/lab-8.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.