diff --git a/index.html b/index.html index 69c919e..df3cc6a 100644 --- a/index.html +++ b/index.html @@ -721,6 +721,12 @@ body.lang-en .en { display: block; }
  • 修复建议Remediation Recommendations
    • +
  • + 用户自我保护User Self-Protection +
    • +
  • + 社区质疑回应Community Questions & Responses +
  • 全球监管机构响应Global Regulatory Response
    • @@ -2089,6 +2095,25 @@ Language/zh-Hant Region/CN

    Note: To protect ongoing investigations, certain case reference numbers and contact emails have been redacted. This table will be updated as investigations progress.

    + + +
    +

    + 独立佐证：美国顶级科技政策智库的平行评估 + Independent Corroboration: Parallel Assessment by Top US Tech Policy Think Tank +

    +
    +

    2026年3月6日——早于我们公开披露5天——美国信息技术与创新基金会 (ITIF) 发表文章 "Alipay Presents Real Risks — But Don't Rush to Ban It"。

    +

    ITIF 被宾夕法尼亚大学评为全球最权威的科技政策智库。文章独立指出支付宝收集"购买记录、设备位置、身份证件、健康数据和生物特征标记"，并呼吁 FTC 和 CFPB 对支付宝进行数据审计。文章还引用中国《国家情报法》第7条，指出中国政府可合法要求企业提交所收集的数据。

    +

    这一完全独立的评估与我们的技术发现高度一致：当白名单绕过允许任意攻击者获取支付宝用户的GPS和设备信息时，数据主权风险被进一步放大。

    +
    +
    +

    On March 6, 2026 — 5 days before our public disclosure — the Information Technology & Innovation Foundation (ITIF) published "Alipay Presents Real Risks — But Don't Rush to Ban It."

    +

    ITIF is ranked by the University of Pennsylvania as the world's most authoritative science and technology policy think tank. The article independently identifies Alipay as collecting "purchase histories, device locations, government IDs, health data, and biometric markers," and calls for FTC and CFPB audits. It cites China's National Intelligence Law Article 7, noting the government can legally compel companies to share collected data.

    +

    This entirely independent assessment is highly consistent with our technical findings: when a whitelist bypass allows arbitrary attackers to obtain users' GPS and device information, data sovereignty risks are amplified further.

    +
    +
    + @@ -2190,6 +2215,277 @@ Language/zh-Hant Region/CN + + + +
    +

    🛡️ + 用户自我保护指南 + User Self-Protection Guide +

    + +
    +

    在厂商修复这些问题之前，普通用户可以采取以下措施降低风险：

    +
    +
    +

    Until the vendor addresses these issues, ordinary users can take the following steps to reduce risk:

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    #措施Measure说明Description防护范围Coverage
    1不点击陌生链接Don't click unknown links收到含 ds.alipay.com 或 alipays:// 的链接时保持警惕，尤其是来自群聊、短信、邮件的链接Be cautious with links containing ds.alipay.com or alipays://, especially from group chats, SMS, or emails全部漏洞All vulnerabilities
    2关闭定位权限Disable location permission在系统设置中将支付宝的定位权限改为"仅在使用时允许"或"关闭"，需要时临时开启In system settings, change Alipay's location permission to "While Using" or "Off"; enable temporarily when neededGPS 静默外泄Silent GPS exfiltration
    3验证转账信息Verify transfer details任何弹出的转账/付款页面，务必仔细核对收款方信息，不要因为页面看起来"正常"就直接确认For any transfer/payment page that appears, carefully verify recipient information — don't confirm just because the page "looks normal"转账预填攻击Transfer pre-fill attack
    4关闭小额免密Disable small-amount password-free payments设置 → 支付设置 → 免密支付 → 关闭小额免密。确保每笔支付都需要密码/指纹确认Settings → Payment Settings → Password-free Payment → Disable. Ensure every payment requires password/biometric confirmation支付接口调用Payment interface invocation
    5保持应用更新Keep app updated如果厂商悄悄修复了部分问题（有社区反馈表明部分接口已变化），更新到最新版可获得保护If the vendor silently patches issues (community feedback suggests some APIs have changed), updating to the latest version provides protection已修补的接口Patched interfaces
    +
    + + +
    +

    💬 + 社区质疑回应 + Community Questions & Responses +

    + +
    +

    本研究在 GitHub、V2EX、LINUX DO 等平台引发了专业讨论。我们感谢所有参与技术讨论的安全从业者，并在此逐条回应主要质疑。

    +
    +
    +

    This research has sparked professional discussions on GitHub, V2EX, LINUX DO and other platforms. We thank all security professionals who participated in the technical discussion and address the main questions below.

    +
    + + +
    +

    + Q1：「DeepLink / URL Scheme 是正常设计，不算漏洞」 + Q1: "DeepLink / URL Scheme is normal design, not a vulnerability" +

    +
    +

    来源：GitHub Issue #4 (sevck), V2EX (Puteulanus)

    +

    我们同意：DeepLink 机制本身是移动生态的通用设计。我们从未将「DeepLink 存在」定义为漏洞。

    +

    但核心问题是：支付宝自有域名 ds.alipay.com 的开放重定向允许任何人通过白名单域名将任意外部页面加载到支付宝的特权 WebView 中，获得完整的 JSBridge API 访问权限。这不是「DeepLink 存在」的问题，而是安全边界被完全突破。

    + +

    类比：门锁是正常设计。但如果任何人可以用一张纸条打开你家门锁，那就是门锁的安全漏洞——不是「门锁这种设计不算漏洞」。

    +
    +
    +

    Source: GitHub Issue #4 (sevck), V2EX (Puteulanus)

    +

    We agree: DeepLink is a standard mechanism in the mobile ecosystem. We never defined "the existence of DeepLink" as a vulnerability.

    +

    But the core issue is: Alipay's own domain ds.alipay.com has an open redirect that allows anyone to load arbitrary external pages into Alipay's privileged WebView via the whitelisted domain, gaining full JSBridge API access. This is not about "DeepLink existing" — it is about the security boundary being completely breached.

    + +

    Analogy: A door lock is a normal design. But if anyone can open your door lock with a slip of paper, that's a vulnerability in the lock — not "door locks aren't vulnerabilities."

    +
    +
    + + +
    +

    + Q2：「GPS 获取在用户已授权权限的前提下是正常行为」 + Q2: "GPS access under existing user permissions is normal behavior" +

    +
    +

    来源：GitHub Issue #4 (sevck, rama291041610)

    +

    这是一个权限委托 vs 权限滥用的问题。

    + + + + + + +
    场景用户期望实际行为
    用户授权支付宝使用 GPS支付宝自身功能使用✅ 正常
    外部攻击者通过 WebView 获取 GPS不在用户预期内❌ 权限滥用
    标准浏览器请求用户位置弹窗请求确认✅ W3C 标准行为
    支付宝 WebView 中外部页面请求位置应当弹窗确认❌ 无弹窗，静默获取
    +

    正如参与讨论的 nailchu 所指出的：「我授权是授给你支付宝的，攻击方想拿就拿算怎么个事儿？就算浏览器也会跳'该网站正在请求位置信息'啊」

    +

    用户把位置权限授予支付宝，是信任支付宝——不是信任任何能够加载到支付宝 WebView 中的随机网页。当攻击者的页面可以通过白名单绕过进入 WebView 并静默调用 getLocation，这就是对用户信任的滥用。

    +

    实测证据：308 条服务器日志记录了从 3 台真实设备静默获取的 GPS 坐标（8.8m 精度），7 秒内完成，0 次用户交互。GitHub Issue #5 的 freshnn 也独立确认 Android 上「无感 GPS」成功。

    +
    +
    +

    Source: GitHub Issue #4 (sevck, rama291041610)

    +

    This is a question of permission delegation vs. permission abuse.

    + + + + + + +
    ScenarioUser ExpectationActual Behavior
    User grants Alipay GPS permissionUsed by Alipay's own functions✅ Normal
    External attacker accesses GPS via WebViewNot within user's expectation❌ Permission abuse
    Standard browser requests locationShows confirmation dialog✅ W3C standard
    External page in Alipay WebView requests locationShould show dialog❌ No dialog, silent access
    +

    As nailchu pointed out in the discussion: "I authorized Alipay, not any attacker who wants my location. Even browsers show 'This website is requesting your location.'"

    +

    When users grant location permission to Alipay, they trust Alipay — not any random webpage that can be loaded into Alipay's WebView. When an attacker's page enters the WebView via whitelist bypass and silently calls getLocation, this is an abuse of user trust.

    +

    Evidence: 308 server log entries documenting GPS coordinates silently obtained from 3 real devices (8.8m accuracy), completed in 7 seconds, with 0 user interactions. freshnn on GitHub Issue #5 also independently confirmed "silent GPS" works on Android.

    +
    +
    + + +
    +

    + Q3：「转账预填需要用户确认，类似 Chrome 表单预填」 + Q3: "Transfer pre-fill requires user confirmation, similar to Chrome form auto-fill" +

    +
    +

    来源：GitHub Issue #4 (sevck, rama291041610)

    +

    我们部分同意：转账确实需要用户至少 2 次点击 + 密码/生物认证确认，不能自动完成。本报告已在相关章节明确标注此前提条件。

    +

    但 Chrome 类比不准确：

    +
      +
    • Chrome 预填的是用户自己保存的表单数据 — 攻击者无法指定预填内容
      • +
    • 支付宝的预填是攻击者通过 URL 参数指定收款账号和金额 — 性质完全不同
      • +
    • 结合 UI 欺骗能力（setTitle/showToast），攻击者可以伪造合法转账理由，降低用户警惕
      • +
    +

    参与讨论的 cxxsheng 独立编写了 PoC，结论：「还是认为这个功能是漏洞，但是危害性会低一些」。他还引用了 CVE-2024-40676（Android 先例）：减少用户交互步骤本身可以构成漏洞。

    +
    +
    +

    Source: GitHub Issue #4 (sevck, rama291041610)

    +

    We partially agree: Transfers indeed require at least 2 clicks + password/biometric confirmation and cannot complete automatically. This precondition is already explicitly stated in the relevant sections of this report.

    +

    But the Chrome analogy is inaccurate:

    +
      +
    • Chrome auto-fills data previously saved by the user — attackers cannot specify the pre-filled content
      • +
    • Alipay's pre-fill is specified by the attacker via URL parameters for recipient account and amount — fundamentally different
      • +
    • Combined with UI spoofing (setTitle/showToast), attackers can fabricate legitimate-looking transfer reasons, reducing user vigilance
      • +
    +

    cxxsheng independently wrote a PoC and concluded: "I still consider this a vulnerability, but with lower severity." He also cited CVE-2024-40676 (Android precedent): reducing user interaction steps itself can constitute a vulnerability.

    +
    +
    + + +
    +

    + Q4：「iOS 上无法复现数据外泄」 + Q4: "Cannot reproduce data exfiltration on iOS" +

    +
    +

    来源：GitHub Issue #5 (freshnn)

    +

    freshnn 报告 iOS 可以调用并打开相关页面，但服务端收不到数据；Android 上「无感 GPS」则复现成功。

    +

    可能原因：

    +
      +
    • 域名/HTTPS 配置 — iOS WKWebView 对混合内容和 CORS 策略更严格，PoC 服务器需使用有效 HTTPS 证书且设置正确的 CORS 头
      • +
    • 支付宝版本差异 — 不同版本的 JSBridge 鉴权策略可能不同，建议使用最新版测试
      • +
    • CSP（内容安全策略） — iOS 上可能有更严格的 CSP 头限制外部请求
      • +
    +

    关键事实：我们的 iPhone 16 Pro (iOS 18.3) 测试确实成功获取了 GPS 数据（记录在服务器日志中），蚂蚁集团安全负责人的 iPhone 在杭州的测试也被我们成功获取了坐标。iOS 复现需要满足特定的服务器配置条件，并非漏洞不存在。

    +

    我们将在 Issue #5 中提供详细的 iOS 复现排查指南。

    +
    +
    +

    Source: GitHub Issue #5 (freshnn)

    +

    freshnn reported that iOS can invoke and open the relevant pages, but the server receives no data; Android "silent GPS" was successfully reproduced.

    +

    Possible causes:

    +
      +
    • Domain/HTTPS configuration — iOS WKWebView enforces stricter mixed content and CORS policies; PoC server needs valid HTTPS certificate with correct CORS headers
      • +
    • Alipay version differences — Different versions may have different JSBridge authentication policies; test with the latest version
      • +
    • CSP (Content Security Policy) — Stricter CSP headers on iOS may restrict external requests
      • +
    +

    Key fact: Our iPhone 16 Pro (iOS 18.3) test did successfully obtain GPS data (recorded in server logs). Ant Group's security lead's iPhone in Hangzhou was also successfully captured. iOS reproduction requires specific server configuration — the vulnerability exists, but the PoC setup matters.

    +

    We will provide a detailed iOS reproduction troubleshooting guide in Issue #5.

    +
    +
    + + +
    +

    + Q5：「这是浏览器通用设计问题，不是支付宝特有问题」 + Q5: "This is a general browser design issue, not specific to Alipay" +

    +
    +

    来源：V2EX (Puteulanus)

    +

    支付宝 WebView ≠ 标准浏览器。关键区别：

    + + + + + + + +
    能力标准浏览器支付宝 WebView (Nebula)
    位置请求弹窗确认静默获取
    支付接口无tradePay 可调用
    内部页面导航无startApp 可跳转敏感页面
    设备指纹标准 User-AgentIMEI/品牌/型号/运营商
    UI 控制受限setTitle/showToast 可伪造
    +

    白名单的存在本身就证明支付宝自己认为需要限制哪些页面可以访问这些特权 API。绕过白名单 = 绕过支付宝自己设定的安全边界。

    +
    +
    +

    Source: V2EX (Puteulanus)

    +

    Alipay WebView ≠ standard browser. Key differences:

    + + + + + + + +
    CapabilityStandard BrowserAlipay WebView (Nebula)
    Location requestConfirmation dialogSilent access
    Payment APINonetradePay callable
    Internal navigationNonestartApp navigates to sensitive pages
    Device fingerprintStandard User-AgentIMEI/Brand/Model/Carrier
    UI controlLimitedsetTitle/showToast spoofable
    +

    The very existence of the whitelist proves that Alipay itself recognizes the need to restrict which pages can access these privileged APIs. Bypassing the whitelist = bypassing Alipay's own security boundary.

    +
    +
    + + +
    +

    + 独立验证与机构背书 + Independent Verification & Institutional Recognition +

    +
    +

    本研究的有效性已获得多个独立第三方的验证：

    +
      +
    • Packet Storm Security — 审核通过并发布 Advisory #217089
      • +
    • MITRE — 受理 6 个 CVE 申请 (Ticket #2005801)
      • +
    • Apple Product Security — 主动启动调查 (Case OE01052449093014)
      • +
    • Google Play — 启动政策违规调查 (Case 9-7515000040640)
      • +
    • CSSF 卢森堡 — 4 个部门确认收到，ICT Risk Supervision 明确记录
      • +
    • PDPC 新加坡 — 启动正式数据保护调查 (#00629724)
      • +
    • CIRCL 卢森堡 CERT — 事件处理人员主动代为联系 Alibaba SRC
      • +
    • HKMA 香港金管局 — 立案调查 (Case CE20260313175412)
      • +
    • cxxsheng（GitHub 安全研究者）— 独立编写 PoC 后确认漏洞存在
      • +
    • freshnn（GitHub 用户）— 独立确认 Android 无感 GPS 复现成功
      • +
    +
    +
    +

    The validity of this research has been verified by multiple independent third parties:

    +
      +
    • Packet Storm Security — Reviewed and published Advisory #217089
      • +
    • MITRE — Accepted 6 CVE applications (Ticket #2005801)
      • +
    • Apple Product Security — Proactively launched investigation (Case OE01052449093014)
      • +
    • Google Play — Policy violation investigation (Case 9-7515000040640)
      • +
    • CSSF Luxembourg — 4 departments confirmed receipt, ICT Risk Supervision explicitly noted
      • +
    • PDPC Singapore — Formal data protection investigation (#00629724)
      • +
    • CIRCL Luxembourg CERT — Incident handler proactively contacted Alibaba SRC on our behalf
      • +
    • HKMA Hong Kong — Case filed (CE20260313175412)
      • +
    • cxxsheng (GitHub researcher) — Independently wrote PoC and confirmed vulnerability exists
      • +
    • freshnn (GitHub user) — Independently confirmed silent GPS reproduction on Android
      • +
    +
    +
    +
    +