Research is a constant process of failure and iteration. However, in most cases, you only see the one-in-a-thousand (successful) attempt. To normalize f*ck ups, and because I believe the behavior we identified in the course of this research is still relevant and interesting, this post is published for educational purposes.

Implementing secure Single-Sign-On (SSO) flows on mobile platforms is a continuos challenge. This post discusses an Android feature which potentially enabled a malicious Android app to hijack arbitrary SSO flows. As the feature existed on platform level (prior Android 12), it affected not only misconfigured apps, but also (web-)applications that follow OAuth best current practice¹.

The vulnerability was reported to Google via the Android and Google Devices Security Reward Program on November, 29th 2024. Shortly after submission, Google highlighted a crucial thing that was missed before: Due to major rework of the App Link behavior, the reported issues do only work on Android versions prior to Android 12.

The following unauthenticated Client-Side Template Injection (CSTI) resulting in a Cross-Site Scripting (XSS) vulnerability was discovered in a private bug bounty program. While the vulnerability could only be exploited in case a user had no active session at the application, chained with an SSO gadget, a malicious actor could have still gained access to the user’s account and performed actions on behalf of the user.

With the rise of Single-Sign-On (SSO) and especially OAuth 2.0 and OpenID Connect (OIDC), the attack surface of web applications has increased significantly. In this post, I will show how to escalate a Cross-Site Scripting (XSS) vulnerability to an Account Takeover (ATO) by abusing OAuth2/OIDC gadgets and how to prevent such attacks.