OAuth Redirect URI Allowlist Bypass via Path Traversal
A client application at app.example.com uses OAuth 2.0 authorization code flow with an authorization server at auth.example.com. The client registers redirect_uri https://app.example.com/callback. The server's allowlist check appears to use a prefix match against the registered URI. The app has an open redirect at https://app.example.com/redirect?url= that 302s to any absolute URL. You have a test account and can complete the flow. The authorization server returns the code in the query string and does not use PKCE. Burp Proxy is capturing traffic. You want to prove account takeover by stealing a victim's authorization code without interacting with the victim. The authorization endpoint validates client_id and redirect_uri before showing the consent page; an invalid redirect_uri returns HTTP 400 with error=invalid_request. The token endpoint requires client_id and redirect_uri but no client secret, because this is a public client.
1. What redirect_uri variants do you test in Burp Repeater, and what response indicates a bypass?
Read the worked answer
Start with the exact registered URI to confirm the flow. Then test path traversal and parser confusion in Repeater with Follow Redirects off: https://app.example.com/callback/../redirect?url=https://attacker.example, https://app.example.com/callback%2f..%2fredirect?url=https://attacker.example, https://app.example.com/[email protected], https://app.example.com/callback.attacker.example, and https://app.example.com/callback?next=https://attacker.example. A bypass is indicated by a 302 whose Location is the open redirect or attacker host, rather than a 400 invalid_request. Because the server uses a prefix match, callback/../redirect may normalize after validation and land on /redirect. Check the Location header carefully, including URL-encoded characters. Use Collaborator as the attacker host and confirm the authorization code arrives in the query string. A 200 consent page for a variant is weaker evidence; you need the redirect to the uncontrolled host.
2. Once you have a redirect to your Collaborator domain, how do you complete the attack and what Burp tools help?
Read the worked answer
Send the victim a link to auth.example.com with client_id, response_type=code, scope, and the crafted redirect_uri. When the victim authenticates, the authorization server redirects to the open redirect with ?code=...; the open redirect forwards the code to your Collaborator URL. Use Collaborator to capture the request and extract the code. Then use Repeater to POST to the token endpoint with grant_type=authorization_code, code, client_id, and the same redirect_uri. Because there is no PKCE and no client secret, the code should exchange for an access token. Use Decoder to URL-decode the code if needed. Verify the token by calling a userinfo endpoint and confirming it belongs to the victim. Keep the entire chain in Logger; the critical evidence is the authorization response Location header and the successful token exchange.
3. What mitigation and verification steps would you recommend?
Read the worked answer
Use exact string matching for redirect_uri, not prefix matching. Reject any URI with path traversal, encoded separators, userinfo, or query parameters that are not pre-registered. Remove the open redirect or restrict it to relative paths. Require PKCE for public clients and bind the authorization code to the code_verifier. For verification, replay the same Repeater variants and expect HTTP 400 invalid_request for all of them. Complete a legitimate flow with the exact URI and PKCE to ensure functionality. Test the open redirect separately with url=https://attacker.example; it should no longer 302 externally. Finally, try to exchange a stolen code without the verifier; the token endpoint should reject it.