In my previous article, I described how I found a security flaw in a popular desktop app's OAuth flow that allowed me to steal any user's account with just one click. I reported it, saw it patched, and then bypassed the patch again. Since the process of bypassing and exploiting the flaw is interesting to me, I decided to write a second article about it. I also tried to get permission to disclose the report, but they didn't allow me to do so. Therefore, throughout this post, I'll refer to the domain as redacted.com.

Setup

Since the setup environment hasn't changed, I refer to the setup section of this write-up.

Reconnaissance

After the vulnerability was patched, I tried to do the same thing I did before to see what would prevent me from taking over a victim's account.

Analyzing The Patch

I followed the previous attack scenario explained here, and you can see its diagram in the image below.

As an attacker, I initiated the OAuth login process in my desktop app. I copied the generated OAuth URL (https://oauth2.redacted.com/auth/google?remote_key=[ATTACKER_REMOTE_KEY]&jwt=1&client_id=[CLIENT_ID]&lang=en&return_skip=1) from the browser it opened and then opened it on the victim’s device with a different IP. However, after completing the OAuth process on the victim’s device, I wasn't able to log in to the attacker’s desktop app as the victim, as I expected.

The patched version showed me the following page:

I tried again using a different device but the same IP through a VPN. I discovered that as an attacker, I could take over the victim's account only if our IPs matched. This showed that the prevention relied only on IP, which is usually not enough.

IP Spoofing via HTTP Headers

By checking all the requests initiated by the desktop application, I noticed that all domains are behind the CDN, and when a developer puts a domain behind a CDN, finding the real client IP can be challenging. This is because there is no universal, standardized way for CDNs to convey the original visitor's IP to the backend, and this process can vary based on the CDN provider, programming language, server configuration, and other factors.

To obtain the real client IP behind a proxy (such as a CDN) and pass it to the server, several HTTP headers are commonly used:

• X-Forwarded-For is a list of comma-separated IPs that gets appended to by each traversed proxy. The idea is that the first IP (added by the first proxy) is the true client IP. Each subsequent IP is another proxy along the path. The last proxy’s IP is not present (because proxies don’t add their own IPs, and because it connects directly to the server so its IP will be directly available anyway).

• Forwarded is the most official but seemingly least-used header.

• There are also special single-IP headers like X-Real-IP (Nginx), CF-Connecting-IP (Cloudflare), or True-Client-IP (Cloudflare and Akamai).

I prepared a victim's device, saved its IP, and initiated the OAuth flow with the attacker's device. This time, I used the X-Forwarded-For header in every request made by the Desktop application. Then I opened the generated OAuth URL using the victim’s device, and I successfully logged in as the victim on the attacker's Desktop application.

As we saw, the patch is vulnerable, but one piece of the puzzle is missing for the exploit: How does the attacker find out the victim's IP to initiate the OAuth flow with it?

Finding Victim’s IP

I previously identified a stored XSS vulnerability in the redirect_uri parameter of a specific endpoint, which has since been patched. In brief, when users accessed the Manage Account section within the desktop application, the backend generated a token and then triggered a browser window opening with a URL structured as https://redacted.com/token?t=Code. This URL facilitated authentication transfer from the application to the browser by leveraging data linked to the Code passed in the t parameter. The Code contained both account information and a redirect_uri value, which dictated the destination URL after the authentication process completed. The vulnerability happened because there were no checks on the redirect_uri, allowing harmful scripts to be added. This issue was fixed after my report.

The following request to the backend API shows the request body for generating the Code passed in the t parameter in the URL:

And the Code that you'll receive in response:

I attempted to exploit this feature to achieve an open redirect by altering the redirect_uri parameter to something like mirzadzare.net. I obtained the generated code from the response and opened the URL (https://redacted.com/token?t=code) in a browser. As a result, it redirected me to mirzadzare.net after the authentication transfer. With this low-impact open redirect, I could redirect the victim to my website and log their IP! The puzzle is finally complete.

Attack Scenario

Based on the analyzed flow, the process of logging the victim's IP and initiating the OAuth flow needed to be automated. I decided to write a PHP exploit to mimic the desktop application, capture the victim's access token, and send it to the attacker via a Telegram bot.

The attack scenario is illustrated in the diagram below:

1. The attacker alters the redirect_uri and sends it to the API endpoint, receiving an authorization code in response.

2. The attacker crafts a malicious link containing this code and sends it to the victim.

3. The victim opens the malicious link.

4. The exploit sends a request to the desktop application's API to initiate the OAuth flow and simultaneously establishes a WebSocket connection with the backend server.

5. The exploit opens a login window in the victim's browser (I could do this without popping up a window, but for simplicity and clarity, I did it for the proof of concept.).

6. The victim enters their credentials in the OAuth provider login window.

7. The exploit continuously monitors the WebSocket connection and detects when the victim successfully logs in and the access token is received.

8. Finally, the exploit sends the stolen access token to the attacker’s Telegram bot, enabling the attacker to take over the victim's account.

In the POC above, the current browser tab displays the exploit page, while the other shows the company's OAuth login result page. Once completed, the access token is sent from the victim's browser to the attacker via a Telegram bot.

Conclusion

This writeup shows how partial fixes can create a false sense of security instead of removing the risk completely. Even though the original issue was fixed, the patch used IP-based validation as its main trust method, which is weak in modern web setups with proxies, CDNs, and client-controlled headers. By combining small issues like IP spoofing and an open redirect, a full account takeover was possible despite the initial fix.

This case teaches important lessons for developers and security teams. First, don't rely only on changeable client properties like IP addresses for authentication and authorization. Second, test fixes against real attacker models, not just the original example. Third, small issues like open redirects or header misconfigurations can become serious when combined.

Security is about how small weaknesses interact, not just one flaw.

Just one click on a malicious link → account takeover. No phishing, no malware.

I discovered a security flaw in a popular desktop app’s OAuth flow that let me steal any user’s account just by one click. The root causes: missing state validation, long-lived tokens stored after loopback redirect, and blind trust in a remote_key parameter. In this post, I walk you through the exact attack step-by-step, why it worked so cleanly, and how vendors can actually fix it.

A few months ago, I decided to start looking for vulnerabilities in desktop applications. To clarify, when I say “finding bugs in desktop apps,“ I mean the parts where a desktop application interacts with its web backend, like authentication, data exchange, or any other integration points. The target for this write-up is a well-known company. I can't disclose its name, so throughout this post, I'll refer to the domain as redacted.com.

Setup

Because I wanted to capture a desktop application's traffic, I installed the BurpSuite certificate on my OS as a root authority. Then, I set up a system-wide proxy through BurpSuite and opened the desktop application. When I launched the application and checked the captured requests, I realized that it did not use certificate pinning. This simplified the traffic interception and meant I didn't need Frida.

Reconnaissance

Understand the application better than its developers do.

I started using the application like a regular user by clicking on every button and trying out all the features, especially the hidden or small ones tucked away in corners, while intercepting the traffic with Burp.The application required you to log in before use, offering two methods: traditional credentials or OAuth.

OAuth flows are particularly interesting to security researchers because there are many ways they can be implemented. The most interesting part is where developers customize the flow to suit their needs, as this is where bugs often appear. (The image below is a sample OAuth page from my !Safe-Blog Project)

OAuth Authorization Flow

I started logging into my account using OAuth. When you clicked on one of the OAuth options, such as “Login with Google” or “Login with Facebook,” a browser window opened with the following URL:

https://oauth2.redacted.com/auth/google?remote_key=[REMOTE_KEY]
&jwt=1&client_id=[CLIENT_ID]&lang=en&return_skip=1

The remote_key was randomly generated each time a user wanted to use OAuth, while the client ID remained the same. This URL then took you to the OAuth provider to log into your account. After you finished the OAuth process, you were redirected to the company website with a message that said, “Login completed, just close the browser.“ When you returned to the desktop app, you saw that you were logged into your account.

The first question I asked myself was: “How was the authentication transferred from the browser to the desktop application?“ I looked for deep links but didn't find any, so I checked the WebSocket section in Burp. I noticed that the desktop app initiates a WebSocket connection with the server right after generating the remote_key. It continuously checks in a loop to see if the user is authenticated. If the user logs in through the browser, the WebSocket server sends back an access token, confirming the user is authenticated, and then the desktop app logs the user into their account.

Here's what happened in the open WebSocket connection after the authentication was successfully completed:

So based on these observations, the diagram below illustrates the OAuth flow:

1. The user opens the Desktop Application.

2. The desktop app displays a login page with two options: Login with credentials and Login with OAuth.

3. The user selects OAuth Login.

4. The desktop app launches the default browser and opens: https://oauth2.redacted.com/auth/google?remote_key=[REMOTE_KEY]&jwt=1&client_id=[CLIENT_ID]&lang=en&return_skip=1

5. The browser shows the OAuth provider page. The user completes the OAuth login.

6. After successful OAuth authentication, the browser redirects to the company website with a message: “Login completed, just close the browser.“

7. Meanwhile, right after starting the browser login, the Desktop App initiates a WebSocket connection to the backend server.

8. The Desktop App continuously checks the authentication status by sending the remote_key to the WebSocket Server in a loop, showing multiple cycles:

   • Check #1 → server responds “not authenticated”

   • Check #2 → “not authenticated”

   • Check #3 → “not authenticated”

9. Once the browser OAuth is completed, the server detects the session and sends a WebSocket response containing an access token.

   • Check #x → “User Authenticated! (Access_Token: xxxxxxxx)”

10. The desktop app receives the access token, marks the user as authenticated, and logs them into their account.

11. Finally, the user is logged into the desktop app through the OAuth flow that started from the web browser.

Attack Scenario

As a security researcher, the first thing that comes to mind is to test if the remote_key is linked to the desktop application session or an identifier.

I asked myself: “What happens if I initiate the Login with OAuth process in my desktop app, copy the generated OAuth URL (https://oauth2.redacted.com/auth/google?remote_key=[ATTACKER_REMOTE_KEY]&jwt=1&client_id=[CLIENT_ID]&lang=en&return_skip=1) from the browser it launched, and send it to a victim? If they complete the OAuth login, will my desktop app authenticate as them?“ I decided to test this scenario.

I logged out of my account, repeated the OAuth authentication flow, and copied the newly generated URL from the browser launched by the desktop application. I then used my phone as the victim device and opened the link there. To my surprise, the desktop application authenticated me as the victim.

Accordingly, the attack scenario can be illustrated as follows:

1. The Attacker opens the Desktop Application.

2. The desktop app displays a login page with two options: Login with credentials and Login with OAuth.

3. The Attacker selects OAuth Login.

4. The desktop app launches the default browser and opens: https://oauth2.redacted.com/auth/google?remote_key=[ATTACKER_REMOTE_KEY]&jwt=1&client_id=[CLIENT_ID]&lang=en&return_skip=1

5. Attacker Copies the URL and send it to the victim

6. Victim clicks on the link and browser will open

7. The browser shows the OAuth provider page. The victim completes the Google OAuth login.

8. After successful OAuth authentication, the browser redirects to the company website with a message: “Login completed, just close the browser.“

9. Meanwhile on the Attacker’s Side, right after starting the browser login, the Desktop App initiates a WebSocket connection to the backend server.

10. The Desktop App continuously checks the authentication status by sending the remote_key to the WebSocket Server in a loop, showing multiple cycles:

    • Check #1 → server responds “not authenticated”

    • Check #2 → “not authenticated”

    • Check #3 → “not authenticated”

11. Once the victim’s OAuth flow is completed, the server detects the session and sends a WebSocket response containing victim’s access token.

    • Check #x → “User Authenticated! (Access_Token: xxxxxxxx)”

12. On the attacker side The desktop app receives the access token, marks the attacker as authenticated, and logs them into victim account.

As demonstrated, there were no mechanisms in place to verify whether the user authenticating on the desktop application was the same individual who was logged into the web session.

Mitigation

The root cause of this vulnerability lies in the absence of state validation between the OAuth initiator and the session completer. The remote_key parameter acts as a session identifier but lacks any binding to the device or user that generated it, allowing an attacker to hijack the authentication flow.

To address this vulnerability, the following mitigations should be implemented:

1. Implement OAuth State Parameter

The application should generate a cryptographically secure, random state parameter that is:

• Bound to the desktop application session

• Validated upon OAuth callback

• Single-use and expires after a short time window (e.g., 5 minutes)

This ensures that only the entity that initiated the OAuth flow can complete it.

2. Bind Remote Key to Device/Session

The remote_key should be cryptographically tied to the desktop application's session or device identifier. When the WebSocket connection is established, the server should verify that:

• The remote_key was generated by the same device making the authentication request

• The desktop app instance matches the one that initiated the flow

3. Add User Confirmation Step

After the OAuth provider redirects back to the company website, it should display clear information about which device is requesting authentication:

• Device name/type

• Approximate location

• Timestamp of the request

Require the user to explicitly confirm: “Are you trying to log in to [Device Name]?“ before sending the access token through the WebSocket.

4. Implement Remote Key Expiration

The remote_key should have a short lifespan (e.g., 2-3 minutes). If the OAuth flow is not completed within this timeframe, the key should be invalidated on the server side, and the desktop application should display a timeout error. This mechanism was implemented in this case, but this alone doesn't secure OAuth.

5. Rate Limiting and Anomaly Detection

Implement monitoring to detect suspicious patterns:

• Multiple failed authentication attempts with different remote_key values

• Authentication requests from geographically distant locations within short time periods

• Unusual WebSocket connection patterns

By implementing these mitigations, the application can ensure that the OAuth authentication flow remains secure and that only the legitimate user who initiated the login process can complete it on their desktop application. Please note that mitigation steps 4 and 5 only make the attack more complex and will not secure OAuth on their own.

Final Words

Don't hesitate to test cross-platform applications. Many security researchers avoid desktop or mobile apps because they seem complex, but take it easy and grow your mindset. You're a hacker! For a real hacker, there are no limitations. Approach cross-platform applications with curiosity and a willingness to investigate deeper layers. As you saw in this write-up, you should expand the attack surface as much as possible. Every application is like an iceberg; what you see is not all there is, so explore what's beneath the surface. After I reported this issue, the developer fixed it quickly. Once the initial report was marked as resolved, I decided to dig deeper into their new implementation and successfully bypassed the patch. In my next write-up, I’ll explain exactly how I did it and what went wrong with their fix.

I hope you enjoyed this write-up and found it helpful. See you in the next one!٫