DeepFold: Efficient Multilinear Polynomial Commitment from Reed-Solomon Code and Its Application to Zero-knowledge Proofs

Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms

Speakers: Kaixuan Luo (The Chinese University of Hong Kong); Xianbo Wang (The Chinese University of Hong Kong); Pui Ho Adonis Fung (Samsung Research America); Wing Cheong Lau (The Chinese University of Hong Kong); Julien Lecomte (Samsung Research America)

Conference: USENIX Security

YouTube: N/A - Peer-reviewed paper, no video available.

Overview

This article delves into the critical security vulnerabilities discovered in integration platforms that leverage OAuth 2.0 for account linking. The paper, authored by Kaixuan Luo and Xianbo Wang from The Chinese University of Hong Kong, alongside Pui Ho Adonis Fung and Julien Lecomte from Samsung Research America, unveils two novel platform-wide attack classes: Cross-app OAuth Account Takeover (COAT) and Cross-app OAuth Request Forgery (CORF). These attacks exploit flawed designs in how these platforms manage multi-app OAuth authorizations, particularly a lack of proper app differentiation.

The research highlights a fundamental paradigm shift in the traditional OAuth trust model when applied to integration platforms. Unlike conventional setups where trusted authorization servers issue tokens to untrusted third-party clients, integration platforms often see untrusted third-party apps acting as authorization servers for a trusted platform's OAuth client. This reversal creates new attack surfaces, leading to widespread vulnerabilities. The implications are severe, ranging from unauthorized access to sensitive user data and services to complete account takeovers, sometimes achievable with a single click.

The significance of this work is underscored by its real-world impact. A comprehensive measurement study revealed that an alarming 16 out of 18 popular consumer- and enterprise-facing integration platforms were vulnerable, including those developed by industry giants like Microsoft, Google, and Amazon. The responsible disclosure efforts by the researchers led to significant security improvements, including the assignment of a critical-severity CVE (CVE-2023-36019) with a CVSS score of 9.6, and substantial bug bounties. This research not only exposes a pervasive security flaw but also provides robust countermeasures, urging a re-evaluation of OAuth's implementation in modern, interconnected digital ecosystems.

Background

Integration platforms have become foundational components of the internet, designed to unify the functionalities of diverse applications, services, and devices into a cohesive, interconnected ecosystem. These platforms manifest in various forms, including Workflow Automation platforms (e.g., Microsoft Power Automate, Zapier), Virtual Assistants (e.g., Amazon Alexa, Google Assistant, ChatGPT Plugins), and Smart Homes (e.g., Google Home, Samsung SmartThings). Their core utility lies in their ability to orchestrate a wide range of external services on behalf of end-users, breaking down digital silos.

A fundamental feature enabling this orchestration is account linking, which connects an end-user's accounts at third-party apps to their platform account. This process typically relies on the OAuth 2.0 protocol, the de facto standard for authorization delegation. In account linking, apps delegate end-users' access tokens to the integration platform's backend, empowering the platform to make API calls to those third-party services on behalf of the user. For example, a workflow automation platform might use an access token to save Gmail attachments directly to Dropbox, or a smart home platform might control Philips Hue light bulbs.

The paper identifies a crucial OAuth Role Reversal within integration platforms. Traditionally, an OAuth client (e.g., a third-party application like Spotify) registers with a trusted Authorization Server (AS) (e.g., Google Sign-in) to gain access to user resources. In this model, the third-party client is generally considered untrusted, while the AS is trusted. However, in integration platforms, this dynamic flips. The platform itself (e.g., Google Assistant) acts as the trusted OAuth client, while the various third-party apps integrated into its open marketplace (e.g., Spotify, Philips Hue) function as the Authorization Servers. These integrated apps, often developed by untrusted third-parties, are now the "trustworthy" entities in the OAuth flow, owning the resources and providing them to the platform. This inverted trust model, combined with the open nature of these platforms, introduces novel security considerations that traditional OAuth specifications do not fully address.

The OAuth Authorization Code Grant flow, as detailed in Section 2, is the prevalent mechanism for account linking. In a typical flow involving a single app:

1. The end-user initiates account linking with an "active app" on the platform.
2. The platform's OAuth client generates a state parameter and redirects the user-agent (browser) to the active app's authorization endpoint.
3. The user authenticates and authorizes the linking at the app's AS.
4. The AS issues an authorization code (auth code) and redirects the user-agent back to the platform's redirect_uri (callback URL), along with the auth code and state.
5. The platform's backend then exchanges this auth code at the app's token endpoint for a long-lasting access token.
6. This access token is stored and associated with the end-user's platform account, allowing the platform to control the app.

Crucially, apps are pre-registered at the platform, providing their authorization endpoint URL, token endpoint URL, client_id, client_secret, and other details. The platform assigns each app a unique app ID and a redirect_uri, which can be either distinct per-app or universal across apps. The ease of malicious app infiltration is a significant concern. Attackers can register innocent-looking apps in open marketplaces, potentially bypassing vetting through server-side dynamic changes or exploiting sharing-based distribution channels that don't require vetting. The attacker model assumes the ability to set up victim-accessible malicious endpoints and the victim being tricked into interacting with a malicious app or clicking a crafted link. The core attack scenario involves a malicious app manipulating the OAuth flow to target a benign app during its own account linking process, aiming for unauthorized access or privacy compromise of the victim's benign app account.

Key Findings

The research presents compelling evidence of two novel, platform-wide attack classes that exploit the unique OAuth architecture of integration platforms: Cross-app OAuth Account Takeover (COAT) and Cross-app OAuth Request Forgery (CORF). These attacks stem from a fundamental flaw: the integration platform's inability to consistently differentiate and track the "active app" throughout an OAuth authorization flow.

The prevalence of these vulnerabilities is striking: out of 18 popular consumer- or enterprise-facing integration platforms evaluated, a staggering 16 were found susceptible to cross-app attacks. Specifically, 11 platforms were vulnerable to COAT (7 to the COATU variant, 5 to the COATD variant, with one platform vulnerable to both), and 5 platforms were vulnerable to CORF. This widespread susceptibility includes platforms built by major technology companies such as Microsoft (Power Automate), Google (Assistant, Home), and Amazon (Alexa).

The security impact of these attacks is profound:

• Unauthorized Control: Attackers can gain control over end-users' cloud services (e.g., Microsoft 365, Azure assets) and physical devices (e.g., smart home devices).
• Privacy Leakage: Covert logging of sensitive information becomes possible.
• Account Takeover: In the most severe cases, the attacks lead to a complete compromise of the victim's app accounts. For instance, the research identified a critical COAT vulnerability in Microsoft Power Automate, enabling platform-wide, single-click account takeovers across over 50 first-party Microsoft applications. This vulnerability was assigned CVE-2023-36019 with a CVSS score of 9.6.
• Single-click Exploits: For 9 of the vulnerable platforms, attacks could be launched with a single click on a crafted link, often without the need for the malicious app to be vetted or published in the marketplace.

To facilitate systematic discovery of these vulnerabilities, the researchers developed COVScan, a semi-automated black-box testing tool. COVScan profiles varied OAuth designs by analyzing and manipulating network traffic, identifying cross-app vulnerabilities without requiring internal knowledge of the platform or acting as a malicious party. Its effectiveness was validated against manual exploitation, proving both cost-effective and accurate.

The root cause of these vulnerabilities lies in the lack of robust mechanisms to verify the consistency of the authorization context across different apps. Standard OAuth specifications, when viewed through the lens of integration platforms' unique role reversal and multi-app architecture, proved insufficient. The researchers proposed robust countermeasures centered on app-specific bindings and collaborated with affected vendors to deploy comprehensive solutions, leading to widespread patching and improved security postures across the affected ecosystem.

Technical Deep Dive

The core of the cross-app OAuth vulnerabilities lies in the integration platform's failure to adequately track the "active app" during an OAuth flow, especially when multiple apps are involved. Traditionally, OAuth security relies on two fundamental requirements: redirect_uri matching by the Authorization Server (AS) and state matching by the OAuth client. While these prevent common attacks like authorization code injection (due to redirect_uri mismatch) and Login CSRF (due to state mismatch) in traditional settings, they are insufficient in a multi-app integration platform.

The paper highlights that the state parameter, while opaque to ASes, reflects how OAuth is initiated but cannot track its conclusion if it traverses multiple ASes. Conversely, the redirect_uri parameter, if not properly secured, can be tampered with by an AS. This leads to scenarios where the platform's OAuth client can be deceived into either leaking an authorization code to a malicious app or injecting an attacker's authorization code into a benign app's flow.

Cross-app OAuth Account Takeover (COAT)

The COAT attack targets platforms where the OAuth client primarily relies on the state parameter to identify the active app. The attack's essence is the malicious app's ability to redirect the victim to a benign app's authorization endpoint while retaining the malicious app's state value. This results in the benign app's authorization code (auth code) being sent to the malicious app's token endpoint.

The attack flow (illustrated in Figure 5, left) involves three phases:

1. Attack Preparation (S0): The attacker registers a malicious app on the platform, specifying their own authorization and token endpoint URLs. They obtain an app ID and a redirect_uri. The attacker then captures a legitimate authorization request URL for a targeted benign app to craft their attack logic.

• Two variants exist: COATU (Universal redirect_uri): where the platform issues a universal redirect_uri for all apps. COATD (Distinct redirect_uri): where the platform issues a distinct redirect_uri for each app.

1. Leaking Auth Code (Victim's Interaction) (S1-S5):

• S1: The victim initiates account linking with the malicious app. The platform redirects the user to the attacker-controlled authorization endpoint with a freshly generated state parameter.
• S2: The malicious app's authorization endpoint immediately redirects the user to the benign app's authorization endpoint. Crucially, it replaces the benign app's redirect_uri and client_id (obtained in S0) but preserves the original state parameter (which is associated with the malicious app).
• S3: From the benign app's AS perspective, this appears as a legitimate authorization request. If the victim has previously linked this benign app, the AS might issue an auth code instantly without re-prompting for consent (silent authorization, discussed below).
• S4: The benign app's auth code is sent to the platform's redirect_uri. The URL contains the auth code and the state parameter (which still identifies the malicious app). The platform verifies the state parameter, confirming it matches the one issued in S1.
• S5: Because the state parameter is associated with the malicious app, the platform (incorrectly) sends the benign app's auth code to the attacker-controlled token endpoint.

1. Attack Wrap-up (S6): The attacker, having stolen the victim's auth code for the benign app, initiates a new OAuth flow with the benign app on their own platform console. They intercept the traffic and inject the stolen auth code. The platform then exchanges this code for an access token for the victim's benign app account, linking it to the attacker's platform identity. The attacker now has full control over the victim's benign app account.

Cross-app OAuth Request Forgery (CORF)

The CORF attack targets platforms that rely on the distinctive element in each app's redirect_uri (e.g., the app ID in the path) to track the active app, rather than solely on the state parameter. This makes them vulnerable to a cross-app version of Login CSRF.

The attack flow (illustrated in Figure 5, right) also involves two main phases:

1. Attack Preparation (S0-S1):

• S0: The attacker registers a malicious app and configures its authorization endpoint.
• S1: The attacker initiates account linking with a benign app using their own account, authenticates, and authorizes it. They capture a valid auth code for the benign app but do not redeem it.

1. Victim's Interaction (S2-S3):

• S2: The victim initiates account linking with the malicious app. The attacker's malicious authorization endpoint returns a crafted authorization response. This response issues a redirection to the benign app's redirect_uri, but crucially, it includes the attacker's auth code (obtained in S1) and the state parameter generated for the victim's malicious app flow.
• S3: The platform backend receives this, perceives the active app as the targeted benign app (based on the redirect_uri), and exchanges the attacker's auth code for an access token for the benign app. This token is then associated with the victim's platform account. As a result, the victim's platform account is now linked to the attacker's benign app account, potentially replacing any existing link. Any subsequent actions the victim performs with the benign app through the platform will operate on the attacker's account, leading to privacy leakage or data manipulation.

Worst-Case Scenario: Single-Click Attacks

The paper describes how specific platform-side design flaws can escalate these attacks to a single-click compromise without requiring the attacker to even publish the malicious app (Figure 6). These conditions include:

• R1: Starting OAuth with cross-site GET request: If the mechanism to initiate an OAuth flow is a simple GET request without CSRF protection (e.g., https://platform.com/connect/<app_id>), an attacker can craft a hyperlink. A victim clicking this link would inadvertently initiate an OAuth flow with the malicious app.
• R2: Inadequate access control/DEV-PROD isolation: Some platforms lack proper isolation, allowing victims to link accounts with non-published apps created by attackers.
• R3: Auto-triggered authorization request: The platform directly triggers the authorization request via HTTP redirects without further user interaction.

Circumventing Consent at Authorization Server (R*)

For COAT attacks, an additional factor is the AS's consent design. Many ASes support silent authorizations (also called automatic authorizations). If a user has a prior authenticated session and has previously granted consent, the AS will issue an auth code instantly without showing a consent screen. Prominent ASes like Microsoft, GitHub, Dropbox, and Xiaomi adopt this. A COAT attacker can exploit this by triggering silent authorizations if the victim has previously linked the benign app.

Furthermore, attackers can often bypass explicit consent even if silent authorizations are disabled by default. Many ASes use a custom GET parameter (e.g., prompt=none, skip_confirm) in the authorization request to control the consent screen's visibility. A COAT attacker can modify this parameter in the crafted redirection from the malicious app's AS to the benign app's AS (Step S2 in COAT), effectively bypassing the consent process. This technique was verified with GitHub, Dropbox, and Xiaomi's ASes and can also circumvent forced re-authentication and account selection. Listing 1 provides a concrete example of a single-click COAT attack with consent bypass.

Demo / Proof of Concept

To systematically detect the identified cross-app OAuth vulnerabilities, the researchers developed COVScan (Cross-app OAuth Vulnerability Scanner), a semi-automated black-box testing tool. The tool's design is rooted in the insight that while OAuth client implementation details are often obscured in closed-source cloud platforms, the platform's reaction to induced app identity inconsistencies can reveal its active app tracking mechanism and thus its vulnerability.

Methodology: Decision Tree for Vulnerability Detection

COVScan's methodology is based on a decision tree (Figure 9) that infers how an OAuth client identifies the active app. The process involves manipulating network traffic to create inconsistencies between the state parameter and the redirect_uri, then observing the OAuth outcome (success or failure).

Initial Setup:

The tester selects two arbitrary apps (App A and App B) within an integration platform, establishes account linking for each, and records their respective redirect_uris and unredeemed, valid auth codes.

Decision Phases:

1. D1: Does the platform assign identical redirect_uri for both apps?

• Yes: The platform must rely solely on the state parameter for app differentiation. This directly indicates vulnerability to COATU (COAT with universal redirect_uri). The process ends here.
• No: The redirect_uris are distinct. Proceed to D2.

1. D2: What is the OAuth outcome of replacing the distinctive element of redirect_uri in the request to the redirection endpoint?

• In an OAuth flow initiated with App A, COVScan intercepts the request to the redirection endpoint (e.g., https://platform.com/<app_A>/redirect?state=<app_A_state>&code=<app_A_code>). It then modifies the redirect_uri to point to App B (e.g., https://platform.com/<app_B>/redirect?state=<app_A_state>&code=<app_A_code>).
• Succeed: If the OAuth flow succeeds, it implies the platform ignored the redirect_uri change and used the state parameter (which still identifies App A) to route the auth code to App A's token endpoint. This confirms vulnerability to COATD (COAT with distinct redirect_uri).
• Fail: If the OAuth flow fails, it could mean either the platform detected the redirect_uri mismatch (secure) or it routed the auth code to App B's token endpoint (based on the modified redirect_uri), but App B's AS rejected App A's auth code (CORF). To distinguish, proceed to D3.

1. D3: On top of the substitution made in D2, what is the OAuth outcome of replacing the auth code as well?

• Continuing from D2's failed scenario, COVScan now replaces both the redirect_uri's distinct element (to App B) and the auth code (with App B's auth code captured earlier). The request becomes https://platform.com/<app_B>/redirect?state=<app_A_state>&code=<app_B_code>.
• Succeed: If the OAuth flow now succeeds, it means the platform routed the auth code to App B's token endpoint (based on the redirect_uri) and App B's AS accepted the auth code (which now matches). This confirms vulnerability to CORF.
• Fail: If the OAuth flow still fails, it indicates that proper defensive checks are in place, and the platform is secure against these cross-app attacks.

Tool Implementation and Verification

COVScan is implemented in Python, leveraging selenium-wire for browser automation and HTTP traffic interception/modification. For mobile-based platforms, an alternative version uses mitmproxy. undetected-chromedriver is used to bypass bot detection. The tool is semi-automated, requiring minimal human intervention for initial navigation and authentication due to varied UIs. OAuth outcomes are distinguished by monitoring HTTP requests/responses for keywords like "error" or "unsuccessful."

For platforms identified as vulnerable by COVScan, manual Proof of Concept (PoC) attacks were conducted to verify the findings and evaluate the amplification of security impact, such as single-click exploits and consent bypass. These PoCs served as the ground truth for the semi-automated detection.

Evaluation Results and Real-World Impact

The evaluation across 18 mainstream integration platforms confirmed the prevalence of vulnerabilities: 16 were susceptible, with 9 vulnerable to single-click attacks.

• Microsoft Power Automate: A critical COAT vulnerability (CVE-2023-36019, CVSS 9.6) was identified. This allowed single-click account takeovers across over 50 first-party Microsoft applications (Microsoft 365, Azure assets). The attack exploited the platform's lack of CSRF protection (R1), isolation between environments (R2), auto-triggered authorization requests (R3), and the implicit trust/consent bypass for first-party Microsoft services (even more severe than R*). The platform issued distinct redirect_uris for first-party apps and universal ones for third-parties, tracking the active app solely by state. Microsoft responded by re-architecting its connectors ecosystem, deprecating universal redirect_uris, and instructing developers to migrate to distinct ones, implementing an extra consent screen during transition.
• A Leading LLM Platform: Initially vulnerable to regular Login CSRF due to missing state parameters, and subsequently to CORF even after state was mandated, due to reliance on distinct redirect_uris without proper state binding. Both issues were fixed after responsible disclosure.
• Secure Platforms: Only two platforms, Zapier and IFTTT, were found to be secure. Their design incorporated solutions similar to the proposed robust countermeasures, associating an app-specific ID with state, embedding an equivalent ID in redirect_uri, and enforcing matching at the redirection endpoint.

The research also evaluated 4 open-source workflow automation platforms (n8n, Activepieces, Automatisch, Nango), finding all of them vulnerable to either COATU or COATD due to missing defenses, highlighting the downstream impact on applications utilizing these platforms.

Defensive Implications

The prevalence of COAT and CORF attacks underscores a fundamental security gap in how integration platforms handle OAuth-based account linking. The root cause is the platform's inability to ensure consistency between the app that initiates the OAuth flow and the app whose Authorization Server (AS) issues the auth code (and subsequently receives the access token). The platform's OAuth client gets confused, failing to properly differentiate the active app throughout the process.

Robust Countermeasure: App-specific Bindings

The most robust and universal defense proposed is the implementation of app-specific bindings. This countermeasure requires dual confirmation of the active app's identity:

1. Platform-issued Unique Identifier: During app registration, the platform must generate a globally unique identifier (e.g., a random UUID-based app ID) for each app. This ID must be both associated with the state parameter (e.g., embedded in a JWT payload) and embedded into the redirect_uri (either in the path or subdomain).
2. Enforced Matching at Redirection Endpoint: The redirect_uri must be distinct and app-specific, validated by the AS, and returned in the authorization response. Critically, the platform's OAuth client MUST compare the app ID embedded in the state parameter against its counterpart extracted from the redirect_uri at the redirection endpoint before proceeding with the access token request. If these two identifiers do not match, the OAuth flow must be aborted.

This solution directly addresses the root cause of both COAT and CORF by ensuring that the app initially contacted by the platform is indeed the one whose AS issues the auth code and whose token endpoint receives the subsequent request.

Migration Challenges:

• COATU platforms (universal redirect_uri): Migrating these platforms is challenging as it requires switching to distinct, app-specific redirect_uris for all apps. This necessitates coordination with every third-party app developer to whitelist the new redirect_uri at their AS. A protracted transition period is often required to maintain backward compatibility.
• COATD platforms (distinct redirect_uri): The fix is more straightforward, requiring only updates to the platform's OAuth client backend code to extract and match the existing app ID in state and redirect_uri.
• CORF platforms: These platforms need to update their state parameter format to embed or associate the app ID and enforce matching against the distinctive element in redirect_uri. This is generally less disruptive as state should be opaque to the AS.

Temporary Mitigations

During the transition period, especially for COATU platforms, temporary measures can provide relief:

• Securing Opted-in Apps: The platform can track which apps have migrated to the new redirect_uri format. For migrated apps, the platform enforces the app ID matching and aborts flows using universal redirect_uris. Unmigrated apps continue with the old system. This allows progressive security improvements.
• Mitigating Single-click Impacts:
• CSRF Protection: Ensuring that every request to initiate an OAuth flow (R1 in §4.3.1) is CSRF protected can prevent inadvertent initiation via crafted hyperlinks.
• Platform-enforced Consent Screen: For unmigrated apps, an extra consent screen presented by the platform before the access token request (e.g., at Step 1 or 5 of Figure 2) can act as a temporary defense, relying on user vigilance. This is crucial because if presented after the auth code is leaked, it's ineffective.

Invalid Defense: PKCE

The paper explicitly clarifies that PKCE (Proof Key for Code Exchange), often considered a robust defense against authorization code injection, does not mitigate COAT or CORF attacks. This is a common misconception.

• In COAT, an attacker can force the victim to generate a PKCE code_challenge within the attacker's OAuth flow. When the attacker later exchanges the stolen auth code, they can use a code_verifier that corresponds to their code_challenge, passing validation. This is known as the "PKCE Chosen Challenge Attack" [22].
• In CORF, the attacker can use the victim's code_challenge to obtain an auth code, which is then injected back into the victim's OAuth flow, as depicted in Figure 7. PKCE, in these cross-app contexts, fails to provide the necessary isolation.

Comparison with IdP Mix-up Attacks

The paper distinguishes cross-app attacks from previously discussed IdP mix-up attacks [7, 23] by highlighting the critical difference in trust relationships. While IdP mix-up attacks focus on a single OAuth client (Relying Party) interacting with multiple trusted Identity Providers (IdPs)/ASes, cross-app attacks occur in integration platforms where the OAuth client (the platform) interacts with numerous untrusted third-party apps acting as ASes. The ease of introducing a malicious, untrusted app into an open marketplace makes cross-app attacks far more practical and prevalent than IdP mix-up attacks, which often rely on the unrealistic assumption of compromising a trusted IdP. The issuer defense proposed in OAuth specifications for IdP mix-up attacks is also deemed insufficient for integration platforms due to the possibility of multiple apps sharing the same issuer and the specific context of CORF. The proposed per-app ID is a more aligned isolation boundary.

Key Takeaways

• OAuth Role Reversal Creates New Threats: Integration platforms fundamentally flip the traditional OAuth trust model, where untrusted third-party apps act as Authorization Servers for a trusted platform's OAuth client. This paradigm shift introduces novel, unaddressed security vulnerabilities.
• Widespread and Critical Vulnerabilities: Two new attack classes, Cross-app OAuth Account Takeover (COAT) and Cross-app OAuth Request Forgery (CORF), are pervasive, affecting 16 out of 18 mainstream integration platforms, including those from Microsoft, Google, and Amazon. These vulnerabilities can lead to full account takeovers and privacy compromises.
• Lack of App Differentiation is the Root Cause: The underlying problem is the integration platform's failure to consistently and securely differentiate the "active app" throughout an OAuth flow, particularly when relying solely on the opaque state parameter or easily tampered redirect_uri for active app tracking.
• Single-click Attacks Amplify Impact: A significant number of platforms (9 out of 16 vulnerable ones) are susceptible to single-click exploitation, often bypassing app vetting and explicit user consent, dramatically lowering the bar for attackers.
• Robust Countermeasures are Essential: The proposed solution of app-specific bindings – requiring a globally unique app ID to be associated with both the state parameter and embedded in a distinct redirect_uri, followed by strict matching at the redirection endpoint – offers a robust defense. Generic defenses like PKCE are insufficient.
• COVScan Enables Scalable Detection: The development of COVScan, a semi-automated black-box testing tool, demonstrates that these complex vulnerabilities can be reliably detected without internal platform knowledge or extensive app development, proving effective in real-world assessments.

About the Speaker(s)

The research paper "Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms" was authored by a collaborative team of researchers:

• Kaixuan Luo (The Chinese University of Hong Kong)
• Xianbo Wang (The Chinese University of Hong Kong)
• Pui Ho Adonis Fung (Samsung Research America)
• Wing Cheong Lau (The Chinese University of Hong Kong)
• Julien Lecomte (Samsung Research America)

This work highlights a successful collaboration between academia and industry, with part of the research conducted during an author's internship at Samsung Research America. Their collective expertise spans web and mobile security, with a focus on identifying and mitigating complex vulnerabilities in modern digital ecosystems. Their responsible disclosure efforts and engagement with industry vendors have led to significant security improvements across numerous high-profile platforms, earning them bug bounties and the assignment of a critical CVE.