> For the complete documentation index, see [llms.txt](https://ganesha-hk.gitbook.io/offensive-security-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/offensive-security-writeups/port-swigger-oauth-labs/lab-1.md). # lab-1 ## Authentication Bypass via OAuth Implicit Flow **Difficulty:** Apprentice ### Lab Description This lab uses an OAuth service to allow users to log in with their social media account. Flawed validation by the client application makes it possible for an attacker to log in to other users' accounts without knowing their password. **Objective:** Log in to Carlos's account. His email address is `carlos@carlos-montoya.net`. **Credentials:** `wiener:peter` ### Root Cause When a client application uses the **implicit method** of OAuth for authentication and authorization, there is no back-channel server-to-server communication. Instead, the authorization server sends the access token directly to the browser, where it can be manipulated to take over other users' accounts and access their sensitive data. Vulnerable workflow: ``` Browser │ ▼ Authorization Server │ Login + Consent │ Returns Access Token ▼ Browser ``` ### Exploitation Log in using `wiener:peter` and complete the OAuth flow. Capture all requests in Burp Suite and analyse the history. Find the request: ``` POST /authenticate HTTP/2 ``` This contains the JSON data sent by the authentication server to the third-party client application via the browser. Remove the session cookie and send the request — a `200` response confirms the session is not being validated. Update the request body, setting `email` to `carlos@carlos-montoya.net` and `username` to `carlos`, then send. You are now logged in as Carlos. ### Lesson Learned If a third-party application uses the implicit OAuth method, look for the response packet sent from the resource server to the client application via the browser. Try replacing the `email` or `username` fields with a victim's values — if the server doesn't re-validate the session, you can take over their account. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://ganesha-hk.gitbook.io/offensive-security-writeups/port-swigger-oauth-labs/lab-1.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.