Application supports Single Sign-On (SSO) with popular authentication providers such as Google and Discord. This feature allows users to log in using their accounts from these providers. However, a security vulnerability exists where:
The OAuth authentication flow is initiated in the same browser window/tab.
There are no protections in place to prevent the login page from being controlled by a malicious parent window (e.g., via window.location.replace()).
This flaw enables an attacker to manipulate the OAuth handshake by opening a login page inside a controlled environment and redirecting the flow to their own OAuth client. As a result, the victim unknowingly grants access to their authentication provider account, which can then be used to compromise their account.
Clarification on Vulnerability Classification
This vulnerability arises from a technical misconfiguration—specifically, the missing Cross-Origin Opener Policy (COOP) —that allows access token theft and subsequent email access.
This is a chained attack resulting from technical misconfigurations.
The absence of COOP allows a malicious window to control the login flow.
This control permits interception of OAuth tokens, including those with mail scope.
The attacker reads the victim’s emails, including password reset messages.
This enables complete account takeover via password reset.
Attack Scenario:
A malicious parent window opens the OAuth login page.
The parent window monitors navigation changes in the victim’s window (e.g., detecting "Sign in with Google").
The parent window intercepts and redirects the OAuth flow to a malicious endpoint, tricking the victim into authorizing the attacker's OAuth client.
Once an attacker obtains an access token with mail scope, they can read sensitive emails and use the information for further exploitation.
This attack leverages a standard login flow without requiring any deceptive tactics or UI manipulation.
Steps to Reproduce
Navigate to https:
Click on "Login with Google" or wait a few seconds. The attacker-controlled OAuth window will automatically replace the legitimate one.
The OAuth token will be stolen and includes mail scope.
The attacker can read the victim’s emails and use the reset password email to take over the account.
Note: You might see a warning about an unverified app. This is expected due to time constraints—we haven’t verified the app or developed a genuine one. This can be skipped, as the PoC alone is sufficient to demonstrate the vulnerability.
Impact
This vulnerability allows an attacker to manipulate the OAuth flow and gain unauthorized access to user accounts. The consequences include:
Account Takeover: Complete control over the victim’s account.
Data Breach: Access to sensitive user data, including emails and linked services.
Privilege Escalation: Reading private messages by leveraging mail scope permissions.
Financial & Reputational Risks**: Unauthorized access may result in significant damages.
Example API request using stolen token:
GET /gmail/v1/users/me/messages HTTP/2
Host: www.googleapis.com
Authorization: Bearer <access-token>
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Recommended Mitigation
Fix #1: Implement Cross-Origin Opener Policy (COOP)**
Set the following HTTP response header to isolate the login page from other windows:
Cross-Origin-Opener-Policy: same-origin
This will prevent cross-origin window access.
Fix #2: Prevent Login Window from Being Controlled by a Parent Window**
Add the following JavaScript snippet to detect and respond to malicious parent
windows:
javascript
if (window.opener) {
try {
if (window.opener.origin) {
console.log("Safe: Opened by the same origin.");
}
} catch {
window.opener.close();
}
}
Fix #3: Initiate OAuth in a Separate Child Window
Avoid handling the OAuth handshake in the same browser window as the app. Initiating the process in a separate child window helps prevent flow interception by parent windows.
By implementing these mitigations, an organization can effectively protect its users against OAuth flow manipulation and unauthorized account access.
This vulnerability has been recognized as high severity (P2) by other organizations
---------------------------------------------------------------------
Here is the POC
CVSS for this is : https:
I think the report is misunderstood due to the nature of this vulnerability. We are not compromising the existing OAuth flow. Instead, we are exploiting a missing Cross-Origin Opener Policy (COOP) to gain access to the victim's mail scope. This allows us to read their emails and subsequently perform a password reset, leading to complete account takeover. This is a chained attack.
Specifically:
The lack of COOP allows us to steal the victim's OAuth token.
This token grants our application mail scope access, enabling us to read their emails.
We can then use the email contents to reset their password.
Reset Password Via Google APIs.png
The impact is significant, as it grants complete control over anything associated with the victim's mailbox. This type of vulnerability has been recognized as high severity (P2) by other organizations.
For a proof of concept, we demonstrated the attack flow. In a real-world scenario, the attack requires:
A legitimate application requesting mail scope permissions.
Standard link delivery. (Just like XSS, CSRF)
The victim proceeding through the normal login process (e.g., "Sign in with Google"), similar to the existing flow.
The core issue is the missing COOP on the login page, which allows the token theft and subsequent mailbox access. The victim proceeds through a standard login flow, eliminating the need for social engineering.