TL/DR: OAuth users are being urged to check their sign-in flows for third-party scripts, including error flows, that could expose them to newly uncovered attack scenarios. Through a chain of attacks, the misconfigurations could allow for single-click account takeovers.
While the attack needed for such a single-click account takeover would be complex, the research by Frans Rosén, Security Advisor at Detectify, discovered that some of the most popular consumer and business websites in the world currently are not following the OAuth specification best practices and thus are vulnerable to the attack chain.
1: Weak or no origin-check postMessage-listeners that leaks URLs
2: Cross-site scripting on sandbox/third-party domains that get the URL
3: Using APIs to fetch the URL out-of-bounds
The OAuth open spec enables single-sign-on to a website by allowing users to authenticate using their third-party credentials – think “Sign in with Google / Apple / Facebook / etc” on a third-party website. All of these third-party service providers utilize OAuth to issue some form of code or access token to verify the identity of the user. OAuth is widely used across the web but has had numerous security vulnerabilities over the last ten years, including recent GitHub breaches using stolen OAuth tokens.
Why this new research matters
While OAuth has had its security challenges, it is still a powerful spec for developers and product owners that enables generally secure access delegation, but also an improved user experience. Because of this, there has been understandable growth in the use of the OAuth framework, not just on consumer sites for end-user access, but also in enterprise scenarios for internal access architectures for important business-related platforms.
With the rise in enterprise adoption of OAuth, the three vulnerable scenarios explained by Rosén expose a unique risk for highly targeted, 1-click account takeover scenarios for spearfishing or supply chain attacks.
While the OAuth spec indicates that third-party scripts should not be running anywhere in the login flow, the spec could easily be misinterpreted or overlooked as key guidance is currently grouped in a section that is seemingly unrelated and of a lower threat severity level
What should organizations using OAuth do to reduce this risk?
First and foremost is to know what kinds of pages are used in the OAuth flow, including error or exception pages that could be triggered if any of the parameters in the sign-in flow are wrong or missing.
Next, the organization should make sure that the aforementioned pages do not use any kind of third-party scripts. A number of types of third-party scripts were found in the wild by Rosén during this research that could leak URLs, such as,
- Chatbot widgets
- Analytics pixels
- Captcha services
Rosén reported multiple instances that were identified in his research and are currently in responsible disclosure processes. He also provided a draft of his research post in advance of publication to the working group of the IETF “OAuth 2.0 Security Best Practices” draft.