PaperlayerView exact revision on arXiv

Source-linked AI summary

One Click to Leak: Characterizing the Real-World Usage and Threat Impact of MNO-based Single Sign-On Websites

Jiasheng Huang, Mingxuan Liu, Pei Chen, Baojun Liu, Yiming Zhang, Geng Hong, Zhenrui Zhang, Hai Yang, Haixin Duan, Hui Jiang

arXiv:2609.12037v2cs.CR

TL;DR

Web-based MSSO has expanded while its delegated trust boundaries and security risks remain poorly characterized. The paper reconstructs its workflow and develops a detection framework for a year-long measurement. It finds widespread trust defects and documents websites and a seized platform associated with OCL exploitation.

  • Problem

    Web-based MSSO’s deployment and security risks remain poorly characterized despite its expansion from native apps to websites.

    Source: §1 · p. 2

  • Method

    The paper reconstructs MSSO’s workflow and uses OCL Detector, a staged framework combining passive DNS, search data, dynamic probing, and script analysis.

    Source: §1 · p. 2, §4 · p. 6

  • Results

    73.6% of 116,852 measured URLs had at least one trust defect; 101 websites were associated with exploitation, and a seized platform collected 14,100 phone numbers in three days.

    Source: §1 · p. 2

  • Takeaways & Limitations

    The findings document widespread trust defects and OCL exploitation in web-based MSSO, including phone-number collection linked to sensitive web context.

    Source: §1 · pp. 2–3

    The PDNS and search-index datasets come from Chinese vendors, limiting the geographic scope of the evaluation.

    Source: §7 · p. 13

Abstract

from arXiv · show

Mobile Network Operator (MNO)-based Single Sign-On (MSSO) is a password-free authentication framework relying on mobile data sessions. Unlike traditional SSO, it shifts the Identity Provider (IdP) to the MNO and the authentication anchor to the Service Provider (SP). MSSO is increasingly deployed and has expanded from mobile apps to websites, yet its web ecosystem and security risks remain largely unexplored. We analyze mainstream MSSO deployments and identify a 3-phase workflow with three trust defects enabling trust hijacking. We further demonstrate One-Click-to-Leak (OCL) attacks, where a single webpage visit can leak sensitive identity information (e.g., phone numbers). With a leading security company, we conduct the first large-scale, longitudinal study of web-based MSSO. We design a hierarchical detection framework using passive DNS correlations and URL reconstruction from search data to identify MSSO-enabled websites. Over one year, we identified 116,852 website URLs across 729 apex domains. Of these URLs, 73.6% exhibit at least one trust defect: 69.4% expose developer credentials, and 27.1% issue high-privilege tokens before user consent, indicating widespread OCL-enabling trust defects. Among the 729 apex domains, 31.8% rely on Resellers, obscuring the downstream SP from the MNO in the analyzed flows. Script analysis identifies 101 websites strongly associated with OCL attack behavior. With our partner, we trace a representative upstream platform subsequently seized by law enforcement and uncover a monetized underground ecosystem. Sanitized backend data shows that it collected 14,100 users' phone numbers within three days and linked them to sensitive information such as browsing activity. Our work provides a comprehensive study of web-based MSSO deployment and security implications. Through responsible disclosure, our work helps secure the mobile authentication ecosystem.

1 Introduction

Web-based MSSO’s delegated trust boundaries remain poorly characterized, despite its expansion from mobile apps to websites. The paper reconstructs the workflow and trust defects, measures their prevalence, and documents real-world OCL exploitation.

Web-based MSSO context

  • MSSO uses an active mobile data session as an identity signal, with the MNO acting as IdP and the SP authenticating the user through one-click login.The paper contrasts this low-friction flow with password entry, SMS OTP retrieval, and browser redirects in conventional Web SSO.Source: §1 · p. 2

Trust hijack threat

  • Three defects—unenforced consent, exposed static credentials, and an origin-validation blindspot—enable trust hijacking and OCL, where one visit can leak a verified phone number.The threat arises from the delegated trust chain operating in browser-based MSSO.Source: §1 · p. 2

Longitudinal measurement

  • The paper designs OCL Detector to find MSSO-enabled websites and high-risk usage through passive DNS correlation, search-engine URL mapping, dynamic probing, and script analysis.The measurement spans one year.Source: §1 · p. 2

Measurement results

  • 73.6% of 116,852 measured URLs had at least one trust defect; 69.4% exposed developer credentials, and 27.1% issued high-privilege tokens before consent.The URLs spanned 729 apex domains; 31.8% of those domains relied on resellers.Source: §1 · p. 2

In-the-wild exploitation

  • A representative seized platform collected 14,100 phone numbers in three days and linked them to sensitive web context, including browsing activity.Script analysis also identified 101 websites strongly associated with exploitation through scripts supplied by five upstream platforms.Source: §1 · p. 2

Defense and disclosure

  • The paper reports practical defense mechanisms and responsible disclosure; at least 148 identified sites deployed recommended defenses, including masked-number completion.The contributions describe disclosure to affected MNOs, SPs, and law-enforcement agencies, with assistance from collaborators.Source: §1 · p. 3

2 MNO-based SSO Preliminaries

The section traces authentication’s shift from user-held credentials toward delegated trust, then describes how MSSO carries that model onto the web. It reconstructs the common workflow and distinguishes direct MNO providers from third-party resellers.

2.1 Evolution of Web Authentication

  • Authentication progresses from passwords and SMS OTPs to Web SSO and MSSO, which shifts the IdP role to the MNO and uses mobile data sessions as an identity signal.Unlike Web SSO, MSSO does not require third-party interaction, and users can authenticate with one tap.Source: §2.1 · p. 3
  • Web MSSO moves authentication logic from opaque native-app binaries into browser JavaScript, where credentials, parameters, and tokens are readable and easier to extract.The paper treats this transparent execution environment as a distinct attack surface compared with native apps.Source: §2.1 · p. 3

2.2 Preliminary Study of Web-based MSSO

  • The preliminary study confirmed 14 MSSO providers and extracted 20 seed endpoints, then identified 225 sites using MSSO through traffic and JavaScript call-stack analysis.The workflow is generalized across provider implementations, despite variations such as some MNOs’ two-stage token process.Source: §2.2 · pp. 3–4
  • The common workflow has three phases: the SP frontend fetches a masked number, requests a User Identity Token after authorization, then relays it to the backend for verification.The backend exchanges the token with the MNO to retrieve the full phone number and establish the user session.Source: §2.2 · p. 4
  • Direct MNOs verify identity from mobile-network data, while resellers broker multiple MNOs’ services through unified interfaces that route requests by the user’s network.Both provider types share a client-side delegation pattern in which SP JavaScript embeds credentials and follows the three-phase flow, creating trust-hijack risk.Source: §2.2 · p. 4

3 Trust Hijack Threat in Web-based MSSO

The paper argues that gaps in consent enforcement, credential protection, and origin validation undermine MSSO’s delegated trust chain. Together, they permit a one-visit attack that can obtain and resolve a user’s identity token without a login action.

Trust defects

  • Unenforced consent lets SP-side JavaScript invoke authentication without protocol-level proof that a human approved the request.The MNO cannot reliably distinguish a genuine user click from a programmatic API invocation.Source: §3 · p. 5
  • Static developer credentials embedded in client-side assets can be collected and reused to impersonate a legitimate SP.The paper also identifies an origin-validation blindspot: reseller-mediated requests may authenticate the intermediary without binding the MNO-facing request to the downstream SP.Source: §3 · p. 5

One-Click-to-Leak attack

  • OCL needs no prior knowledge of the victim’s identity: an adversary uses a legitimate SP’s credentials to request a token, then replays it to resolve the phone number.The origin-validation blindspot permits replay across a different origin and session; unenforced consent allows the flow to start without user permission.Source: §3 · p. 6

Attack flow and feasibility

  • The attack proceeds from luring a mobile-data user to a webpage through a covert token request and illicit issuance, ending with backend token resolution to a phone number.A captured token can be submitted to the legitimate verification endpoint from a separate session, which returned the corresponding verified number in controlled experiments.Source: §3 · p. 6

4 OCL Detection

OCL Detector addresses the difficulty of finding web-based MSSO at scale by combining passive DNS correlation, search-engine data, and targeted dynamic analysis. Its pipeline identifies MSSO sites, probes their authentication behavior, and analyzes scripts for abuse candidates.

4 OCL Detection

  • OCL Detector combines passive-DNS domain discovery, search-derived URL reconstruction, and dynamic verification to identify MSSO sites and collect evidence for abuse analysis.MSSO interactions are hard to detect at web scale because they appear in authentication traffic and JavaScript, while brute-force crawling is costly and real-user monitoring is privacy-invasive.Source: §4 · p. 6, §4.1 · p. 6

4.2 MSSO-related Domain Discoverer

  • The Domain Discoverer correlates candidate domains with MSSO seed domains using short-window DNS co-occurrences, time-decayed confidence scores, and entropy-weighted client aggregation.It discards candidates seen by three or fewer client IPs and returns a ranked domain list.Source: §4.2 · p. 7

4.3 MSSO Service Verifier

  • The Service Verifier maps candidate domains to representative URLs, then simulates mobile-network browsing and checks traffic against MSSO service signatures.It traces resource-providing domains back to embedding sites and records matched requests, alerts, and supporting evidence.Source: §4.3 · p. 7

4.4 Abuse Detector

  • Abuse analysis clusters scripts using static, provider, behavioral, path, and domain features to produce candidates for downstream investigation.Clusters are attribution candidates rather than proof of exfiltration; provider analysis and case studies are used for validation.Source: §4.4 · pp. 7–8

4.5 Implementation

  • The implementation uses passive-DNS logs and a search-engine relationship graph, with mobile-configured headless browsers to probe MSSO flows and capture call stacks.The probing environment was checked across network routing, client profile, browser state, and automation settings for MNO and Reseller deployments.Source: §4.5 · p. 8

4.6 Evaluation

  • The evaluation found high precision and full coverage of the independently confirmed Secrank Top 1M ground-truth set.Of 329 reachable sampled URLs, 319 completed valid MSSO authentication flows (96.9%); the authors report high relative recall against that ground-truth set.Source: §4.6 · p. 8

5 Real-World Trust Hijack Assessment

The one-year assessment found web-based MSSO across many sites and high-trust sectors, with consent, credential, and origin-validation defects widespread in the observed deployments. Reseller-mediated flows obscure downstream service providers from MNOs in the analyzed requests.

5.1 The MSSO Deployment Landscape

  • 116,852 MSSO-enabled URLs across 729 apex domains were identified, with deployments spanning high-value sectors and an overall upward trend across the measurement period.The authors caution that short-term fluctuations in observed domains reflect passive-DNS sampling, not necessarily site decommissioning.Source: §5.1 · pp. 8–9

5.2 Privileged Tokens Issued Without Consent

  • 27.1% (31,654 URLs) issued high-privilege tokens before consent, affecting 24.9% (182 domains) and violating the intended low-privilege pre-authentication boundary.The described flows can expose a verified identifier when an adversary impersonates an SP and invokes the pre-fetch API without a user click.Source: §5.2 · p. 9

5.3 Leaked and Shared Developer Credentials

  • 69.4% (81,146 URLs) exposed developer credentials, affecting 62.6% (457 domains); the study identified 460 distinct exposed credentials.The findings also describe credential sharing across sites, including reuse spanning 30 sites in one conglomerate and 28 sites across sectors.Source: §5.3 · p. 10

5.4 Origin Blindspot via the Reseller Ecosystem

  • 31.8% (232) of 729 apex domains, corresponding to 19.6% (22,859 URLs), used Third-Party Resellers that left MNOs unable to identify the downstream SP from the MNO-facing request.Reseller-connected URLs had an observed credential-leak rate of 80.1%, compared with 66.6% for direct-MNO sites.Source: §5.4 · pp. 10–11

6 One-Click-to-Leak Attack Evaluation

The evaluation traces suspicious MSSO scripts from downstream behavior to upstream providers, then examines case studies and sanitized backend evidence from one seized platform. It finds platform-concentrated abuse and an operational pipeline that captured and monetized phone numbers at scale.

6.1 Malicious Provider Discovery

  • Clustering filtered 9,782 JavaScript files into 586 anomalous outliers and revealed risky patterns including obfuscated first-party logic, hyper-active integrations, and covert third-party exploit-platform candidates.The evaluation uses downstream behavioral analysis and upstream attribution because direct observation of exfiltration in transit is impractical.Source: §6.1 · p. 11, §6 · p. 11
  • Of 586 high-risk scripts, 162 (27.6%) were served by five upstream platforms and covered 101 websites, indicating concentrated platform-based activity rather than sporadic developer error.The high-risk set was narrowed from 9,782 scripts; 255 of 582 parseable resources contained a recognized obfuscation pattern.Source: §6.1 · pp. 11–12

6.2 Case Study: In-the-Wild Exploitation

  • 101 websites were strongly associated with abusive MSSO exploitation through scripts supplied by five upstream platforms, though final data exfiltration could not be reliably observed in transit.The authors classify these sites as strongly associated with abuse, not as directly confirmed instances of exfiltration.Source: §6.2 · p. 12
  • Platform A’s analytics scripts secretly trigger the MSSO pre-fetch API on page load, capture the User Identity Token, and exfiltrate it to enable de-anonymization without consent.The scripts masquerade as user analytics tools and exploit Trust Defects characterized earlier in the paper.Source: §6.2 · p. 12
  • Platform B chains stolen downstream developer credentials with a vulnerable pre-fetch API to obtain high-privilege tokens without user interaction, then exfiltrates them to a third-party tracking platform.This case uses two Trust Defects to complete the malicious service chain.Source: §6.2 · p. 12
  • The seized platform combines SaaS exploit delivery, two-stage data fusion, and monetization through anonymous USDT payments and automated affiliate commissions.Paid-customer checks, anti-analysis measures, and hidden-image/XHR exfiltration support delivery and stealth.Source: §6.2 · p. 12
  • The platform enriches captured phone numbers with referrer, IP, geolocation, and User-Agent data, then links profiles to search keywords using customers’ analytics credentials and IP matching.The enrichment process has an initial capture stage and an automated server-side keyword-fusion stage.Source: §6.2 · p. 12
  • The platform’s database recorded covert collection and profiling of 14,100 unique victim phone numbers in three days, implying potential illicit revenue over 21,000 CNY at its minimum price floor of 1.5 CNY per number.Source: §6.2 · p. 13

7 Discussion

The discussion proposes user verification, privilege separation, and replacing static developer credentials to reduce OCL exposure. It also notes geographic and detection limits, with residual evasion chiefly risking false negatives.

7 Discussion

  • At least 148 affected sites deployed recommended defenses after disclosure, including masked-number completion, which preserves MSSO’s low-friction login experience while reducing OCL exposure.The proposed mitigations also include gating token issuance on user verification, preventing pre-authentication high-privilege tokens, and replacing static app credentials.Source: §7 · p. 13
  • Masked-number completion requires users to enter hidden digits before token issuance, adding participation while retaining MSSO’s low-friction experience.The paper recommends pairing this step with server-side rate limiting or temporary blocking against brute-force attempts.Source: §7 · p. 13
  • PDNS and search-index data from Chinese vendors limit geographic generalization, and adaptive cloaking or unexecuted code can withhold behavior, making detected deployment and abuse counts conservative lower bounds.Controlled validation and manual review support observed positives, while residual evasion primarily risks false negatives.Source: §7 · p. 13

8 Related Works

Prior work studies password and mobile-authentication weaknesses, Web SSO protocols and integrations, and phone-number abuse. This paper distinguishes web-based MSSO by examining MNO-held identity and one-click leakage through ordinary web entry points.

8 Related Works

  • Prior research covers password limitations, SMS OTP interception and SIM-swap weaknesses, Web SSO protocol properties, deployed integrations, and account or session compromise.The cited work addresses web IdP accounts, protocol tokens, SP integrations, and web sessions.Source: §8 · p. 13
  • Web-based MSSO shifts identity authority to the MNO, which maps an active mobile-data session to a verified phone identity, unlike the focus of much prior Web SSO research.Earlier cellular-network authentication studies identify unverifiable network authenticity and the SIMulation attack.Source: §8 · pp. 13–14
  • OCL differs from phishing by using an ordinary web entry point and exposed developer credentials to leak a verified mobile identity that can be linked to web context.Prior work links phone numbers to fraud, profiling, targeted abuse, and user enumeration.Source: §8 · p. 14

9 Conclusion

The paper characterizes web-based MSSO trust defects and measures their deployment and abuse, including evidence from one seized platform. It proposes mitigations and reports responsible disclosure to stakeholders.

9 Conclusion

  • Across 116,852 URLs and 729 apex domains, the study reports pre-consent high-privilege tokens on 27.1% of URLs, exposed developer credentials on 69.4%, and reseller-mediated integration on 31.8% of domains.The authors also identify 101 websites strongly associated with OCL behavior through scripts served by five upstream platforms; one seized platform collected 14,100 unique phone numbers in three days.Source: §9 · p. 14

A Open Science

The authors release code, sanitized analyses, safer-flow examples, and a controlled OCL demonstration while withholding sensitive raw records. They describe ethical safeguards and limit generative AI use to editorial assistance.

A Open Science

  • The public artifact includes OCL Detector code, sanitized analyses, safer-flow examples, and a controlled OCL demonstration, but excludes raw datasets and attack-enabling records.The passive DNS and search-engine data cannot be redistributed; raw HAR archives and site- and script-level materials are also withheld.Source: A Open Science · p. 15
  • Restricted datasets prevent full reproduction of the measurements, although the paper reports all quantitative findings and the artifact avoids materials that could enable attacks.The authors say the released analyses and controlled demonstration provide evidence of risk and real-world impact.Source: A Open Science · p. 15

B Ethical Considerations

  • Experiments and data handling followed legal and compliance oversight, used author-controlled SIMs, and avoided redeeming third-party tokens or obtaining users’ phone numbers.Probing was limited to publicly indexed pages, rate-limited, and accompanied by an opt-out mechanism; identified risks were disclosed to providers and CERT.Source: B Ethical Considerations · p. 16

C Generative AI Usage

  • Generative AI was used only for minor editorial assistance, while authors created and validated the technical work and manually reviewed AI-assisted text.Examples included grammar checking and light style polishing.Source: C Generative AI Usage · p. 16

D MSSO Provider

The provider landscape distinguishes direct MNOs, which control subscriber identity verification, from resellers that rebundle MNO capabilities. The provider table also supplies operational artifacts for detection and origin analysis.

D MSSO Provider

  • Direct MNOs control the mapping from an active mobile data session to a verified subscriber identity, while resellers purchase capabilities from multiple MNOs and rebundle them for service providers.Examples given are China Mobile, China Telecom, and China Unicom as MNOs, and Alibaba Cloud and Netease Yidun as resellers.Source: D MSSO Provider · p. 16
  • Reseller endpoints add a mediation layer that can hide the downstream service provider behind the reseller’s identity and developer credentials.The table’s seed endpoints and bundled-MNO information support both seed construction and origin-validation analysis.Source: D MSSO Provider · p. 16
  • The provider table categorizes key players by architectural role and service nature, alongside the operational artifacts used by OCL Detector.Its bundled-MNO column distinguishes single-MNO services from abstractions spanning CM, CT, and CU; seed endpoints identify MSSO traffic patterns.Source: D MSSO Provider · p. 16

E Feature Definitions for Script Profiling

The script profiling features combine code properties, deployment context, and runtime ties to MSSO traffic to support clustering and candidate selection. Masked-number completion adds a user-input step before issuance of a User Identity Token.

E Feature Definitions for Script Profiling

  • Script profiling combines intrinsic code properties, deployment context, and runtime relationships to MSSO traffic for density-based grouping and anomalous-candidate selection.Behavioral interpretation and abuse attribution then rely on feature analysis, manual review, upstream-provider analysis, and case studies.Source: E Feature Definitions for Script… · p. 16

F Masked-Number Completion Figure

  • Users must fill in the hidden digits of a partially masked phone number before the MNO issues a User Identity Token.This leaves the pre-authentication phase without enough information for an automated script to complete the flow alone; the user still confirms a phone number rather than entering a password or SMS code.Source: F Masked-Number Completion Figure · p. 16
  • A script can trigger background requests but cannot infer the missing digits without user input or brute force, which MNO-side rate limiting can make impractical.Figure 6 illustrates the masked-number completion verification mode.Source: F Masked-Number Completion Figure · p. 17, Figure 6 · p. 17

G Consent-Bypass Figure

The intended workflow reserves high-privilege tokens for after explicit user confirmation, but the consent-bypass flaw shifts issuance into pre-authentication. A page-load pre-fetch can consequently return identity-bearing material before a click.

G Consent-Bypass Figure

  • In the intended workflow, pre-authentication returns only display data, while high-privilege tokens are issued after the user explicitly confirms login.The low-privilege pre-authentication phase lets the user decide whether to continue.Source: G Consent-Bypass Figure · p. 17
  • The consent-bypass flaw moves high-privilege token issuance into pre-authentication, allowing an adversary-controlled page or script to obtain a token through the pre-fetch API.A request that appears to be a page-load optimization can return identity-bearing material before any user click.Source: G Consent-Bypass Figure · p. 17, Figure 7 · p. 18
Loading 2609.12037v2…