文章总结： 本文详述安全团队因发布移动支付应用DeepLink漏洞分析文章遭律师函投诉的事件。作者列举实验数据与厂商验证记录，驳斥商誉侵权指控，强调未指名特定主体且内容属实。核心发现包括iOS端无弹窗回传GPS隐患，厂商定性为正常功能存在矛盾。作者展示了负责任披露流程，呼吁保障用户知情权并建议第三方鉴定。 综合评分： 95 文章分类： 漏洞分析,移动安全,渗透测试,实战经验

---

支付宝安全研究遭律师函投诉一篇零次提及”支付宝”的文章如何构成”商誉侵权”？

原创

Feng Ning Feng Ning

AI-security-innora

2026年3月12日 07:49 新加坡

INNORA AI SECURITY RESEARCH

投诉单号 428526665 | 2026-03-12

2026年3月11日 18:16，我们在微信公众号发布了一篇移动支付应用的 DeepLink 攻击面技术分析文章 位置被秒偷！10多亿人每天在用的国民支付应用，17个「正常功能」细思极恐！。

同日 22:45 —— 发布仅 4小时29分钟 后 —— 北京格韵律师事务所代理提交了侵权投诉。

投诉分类：内容侵犯名誉/商誉/隐私/肖像。

我们认为该投诉不成立。以下是基于事实和法律的完整回应。

一、事实基础：文章全文零次提及”支付宝”

我们对被投诉文章进行了全文检索：

“支付宝” 出现次数：0

“Alipay” 出现次数：0

“蚂蚁集团” 出现次数：0

全文使用”国民支付应用””某头部支付平台””支付App”等通用表述。根据《民法典》第 1024 条，名誉权侵权需满足”针对特定主体”的要件。一篇未指名任何企业的技术分析文章，从逻辑起点上就不具备商誉侵权的构成基础。

我们理解，在行业语境下，读者可能通过技术细节推测文章所涉及的应用。但即便存在这种”可识别性”，根据《民法典》第 1025 条，只要内容属实、出于公共利益且未超出合理限度，即使影响他人名誉，也不承担民事责任。换言之，即使读者能猜出是谁，只要我们说的都是真的，就不构成侵权。

值得注意的是：投诉方通过主动提起投诉，反而自行确认了文章内容与其委托人的关联性。

二、内容属实：308 条日志、3 台设备、42 张截图

根据《民法典》第 1025 条，行为人为公共利益实施舆论监督，影响他人名誉的，不承担民事责任——前提是内容属实且未超出合理限度。

我们的文章基于以下可验证的实验数据：

测试设备：Samsung S25 Ultra（新西兰）、Redmi 12（马来西亚）、iPhone 16 Pro（中国杭州）

数据日志：308 条完整服务器回传记录，含 GPS 坐标、设备信息、时间戳

可视证据：42 张真机截图，完整记录每一步操作

独立验证：在线 PoC 页面（只读、不收集数据），任何安全研究人员可复现

这不是推测，不是揣测，不是”据传”。每一条结论都有对应的实验数据。

根据国际通用漏洞评分体系 CVSS 3.1，User Interaction: Required 是一项标准评分指标——需要用户交互的安全问题（如 XSS、CSRF、Clickjacking）在全球范围内均被认定为有效安全发现。我们的研究发现符合 CWE-939（Improper Authorization in Handler for Custom URL Scheme）和 CWE-749（Exposed Dangerous Method or Function）等国际分类标准。

如果投诉方认为数据不实，我们欢迎通过第三方技术鉴定机构进行验证。

三、逐条回应：投诉方三项”不实信息”主张

投诉方主张一：”点击链接无弹窗提示”是不实的

投诉方称支付宝具备 URL 风险检测机制，跳转第三方页面必须经过安全检测。

事实：我们描述的是 JSBridge API 调用环节——当外部网页已在 App 内置 WebView 中加载后，调用 getLocation、startApp 等敏感 API 时不会弹出任何二次确认对话框。初始跳转时确实存在一个”继续访问”提示，但该提示未告知用户外部页面将获得调用内部 API 的能力。这是两个不同层面的问题。

投诉方主张二：”摄像头权限被拿走”是不实的

投诉方称摄像头权限需要用户授权同意。

事实：我们的原文第④条描述的是通过 getSystemInfo API 读取”摄像头 / 麦克风授权状态“——即 cameraAuthorized: true/false 这一布尔值。获取的是”用户是否已授权摄像头”的状态信息，不是获取摄像头权限本身，更不是控制摄像头。投诉方将”读取权限状态”偷换为”获取摄像头权限”，属于对原文的歪曲。

投诉方主张三：”实时位置信息窃取”是不实的

投诉方称调用位置权限均以弹窗形式告知用户并获得授权同意。

事实：我们的原文明确标注了前提条件——”用户曾给 App 授过定位权限就会中招”。文章末尾”重要澄清”部分再次强调：”位置获取依赖用户此前已授予 App 的定位权限“。

我们的实测证明：在上述前提条件下，外部页面调用 getLocation 时不会弹出任何二次确认弹窗。GPS 坐标被直接返回并可通过 XHR 发送至外部服务器。这有 3 台设备的测试记录和 308 条服务器日志为证。

三项主张均建立在对原文的断章取义之上。投诉方选择性忽略了文章中的限定条件、技术上下文和免责声明。

四、厂商安全团队亲自验证：GPS 数据无弹窗直接回传

在私下报告阶段，厂商安全团队指派了一位安全业务负责人与我们对接，协同验证漏洞的真实性。该负责人使用自有 iPhone 16 Pro（iOS 26.3.1）在中国杭州进行测试。

验证结果：iPhone 无任何 GPS 授权声明

该验证人员在杭州点击测试链接后：

1. iPhone 全程未弹出任何 GPS 授权声明或提示 — 页面加载到 GPS 坐标回传仅 7 秒，中间无任何授权对话框

2. GPS 定位数据（坐标指向杭州市区）被直接回传至我们的服务器，3 轮测试中 GPS 精度从 17.4 米递进至 8.8 米，证明为实时 GPS 锁定而非缓存数据

3. 设备日志显示 locationReducedAccuracy: 0，即 iPhone 使用精确定位模式（非 iOS 14+ 的模糊定位），用户完全无感知

4. 我们的服务器日志完整记录了 3 次 GPS 数据回传（时间戳、坐标、精度值均保存）

这意味着：投诉方声称的”调用位置权限均以弹窗形式告知用户”，被厂商自己的安全业务负责人的 iPhone 实测彻底推翻。该负责人在使用自己的设备测试时，没有看到任何 GPS 授权声明——位置信息在他毫不知情的情况下被传到了我们的服务器。

正是这次厂商协同验证首次揭示了一个重要事实：iOS 版本的攻击面显著大于 Android 版本。在此之前，我们仅在 Android 设备上测试，尚不知道 iOS 受影响更严重。

iOS 额外暴露的 5 个敏感 API（Android 均被拦截）：

tradePay — 触发支付 SDK，弹出收银台界面

share — 调用系统分享，可将恶意链接传播至微信/QQ/钉钉（蠕虫传播向量）

getLocation — Android 需 checkJSAPI 权限校验，iOS 直接返回坐标

scan — 调用摄像头扫码功能

chooseImage — 访问用户相册

厂商安全团队在知悉上述全部事实后，仍然给出了”正常功能”的定性。当企业在内部验证确认风险存在后选择不修复，随后通过法律手段阻止公众知情——这一系列行为的逻辑值得公众审视。

五、逻辑矛盾：”正常功能”与”商誉侵权”不可能同时成立

时间线如下：

2026-03-10

厂商安全团队回复：”根据我们的评估，这些属于正常功能”

2026-03-11 ~18:03（截图泰国时间17:03+1h）

微信对话：厂商对接人确认”正常功能”，我方告知将公开讨论（详见第六节）

2026-03-11 18:16

我们发布技术分析文章，讨论上述”正常功能”的安全影响

2026-03-11 22:45

律师事务所投诉：”商誉侵权”

从”正常功能”到”商誉侵权”，间隔不到 48 小时。这两个立场在逻辑上互斥：

若确为正常功能——讨论一款应用的公开功能属于正当技术交流，正如讨论汽车的制动系统设计不构成对车企的商誉侵权。

若并非正常功能——那么厂商的”正常功能”回复本身就构成对问题的回避。而研究者在合理等待期后公开讨论未修复的安全隐患，属于行使公众知情权。

若讨论这些功能会损害商誉——恰恰说明厂商自身也认识到这些功能设计存在不足。真正影响商誉的不是安全研究文章，而是问题本身。

六、微信聊天记录：发布前的关键对话

以下是 2026年3月11日，我们与厂商安全团队对接人的微信聊天记录（完整截图已作为证据保存）。注：截图时间显示为泰国时区（UTC+7），对应中国时间需加1小时。

17:03 我方：“漏洞的 就是 zfb的正常功能，这是 最后官方解释了吧？”

厂商对接人：“嗯”

我方：“好的 那我拿素材写小说了”

厂商对接人：“咋还写”

我方：“不是漏洞 还不能说？”

我方：“你看：能造成危害，然后你们说正常功能 我也没说一定是漏洞。。”

我方：“总不能发声权利都没有吧”

我方：“我还是继续写小说去了”

厂商对接人：“卧槽”

厂商对接人：“你这话说的，我这几天可是一直在跟进沟通，不能结果不符你意就还发吧？”

我方：“我有点后悔和你们打交道了”

厂商对接人：“第一次报公司这边没及时处理确实有问题，这次你报个洞我们按照流程确认处置，你还不满意啊？”

厂商对接人：“你想怎么着，你说下你诉求”

17:30 我方：“满意啊”

我方：“都不是漏洞了 我公开说一下 总能说的吧？”

我方：“你也不能太强权的 不是漏洞 还不让我说？”

这段对话揭示了以下关键事实：

1. 厂商对接人亲口确认了”正常功能”定性。当我方问”漏洞的 就是 zfb的正常功能，这是最后官方解释了吧？”时，对方回复”嗯”。

2. 厂商对接人承认第一次报告处理有问题。“第一次报公司这边没及时处理确实有问题”——指2月25日的 TLS/SSL 报告，厂商直到3月6日才回复”无法被实际利用”。

3. 对接人在对话中使用了”洞”这一表述。“这次你报个洞我们按照流程确认处置”——虽然这只是私下非正式对话中的用词，不代表厂商官方定性，但至少说明厂商安全团队内部对这些发现的安全属性并非毫无认知。

4. 我方在文章发布前已告知厂商。截图时间为泰国时区（UTC+7），换算为中国时间（UTC+8）需加1小时：对话开始于北京时间约 18:03，文章 18:16 发布。厂商对接人在得知我方意图后未提出正式的暂缓发布请求。

5. 我方的逻辑清晰合理。“不是漏洞 还不能说？””你也不能太强权的 不是漏洞 还不让我说？”——既然定性为”正常功能”，公开讨论就不构成任何不当行为。

---

七、程序合规：完整的负责任披露流程

我们严格遵循国际安全社区通行的负责任披露准则（参考 ISO/IEC 29147:2018）。以下时间线的每一步均有邮件记录和服务器日志可查证：

2026-02-25 — 首次私下报告：TLS/SSL 中间人攻击 + 设备指纹问题，发送至厂商官方安全响应中心（厂商官方安全响应邮箱（3个收件地址））

注：此次报告的是 TLS/SSL 相关问题，DeepLink/JSBridge 攻击链尚未发现

2026-03-06 — 收到 AntSRC 回复首次报告：“经过我们安全工程师审核，无法被实际利用”

2026-03-07 04:08 — 第二次报告：发现 DeepLink+JSBridge 攻击链，提交 8 个漏洞（2 CRITICAL + 4 HIGH），发送至厂商安全团队对接人

2026-03-07 06:07 — 第三次报告（V3）：深度验证后扩展至 17 个漏洞，含资金操作风险（startApp 预填转账/tradePay 触发支付 SDK），附 308 条服务器日志 + 42 张截图

2026-03-07 07:54 — 第四次报告：端到端外部攻击完整演示，3 台设备跨国验证（新西兰/马来西亚/中国），含在线复现链接

2026-03-07 12:33 — 厂商安全团队对接人回复：“漏洞报告邮件已收到，我们会安排人尽快分析，完了给你回复”

2026-03-08 — 厂商安排安全业务负责人与我们协同验证，该人员在杭州使用 iPhone 16 Pro 测试，GPS 数据无弹窗回传（详见第四节）

2026-03-09 — 研究者测试账户因触发风控被封锁，我们向厂商发送解封申请

2026-03-10 — 收到厂商最终回复：“根据我们的评估，这些属于正常功能”

2026-03-11 ~18:03 — 微信对话（截图显示泰国时间17:03，+1h=北京时间）：厂商对接人确认”正常功能”定性，我方告知将公开讨论（详见第六节）

2026-03-11 18:16 — 公开研究成果（微信公众号 + innora.ai/zfb/）

2026-03-11 22:45 — 文章发布仅 4 小时 29 分钟后，北京格韵律师事务所提交侵权投诉

以上时间线中，每一封邮件均保存在我们的邮件服务器（Proton Mail 加密存储），厂商方回复同样有完整记录。

在一天之内（3月7日），我们连续提交了 3 份递进式报告（8个→17个漏洞→端到端攻击演示），每份都附带更完整的证据。厂商在安排人员亲自验证并确认可复现后，仍给出”正常功能”的定性。

关于等待期：Google Project Zero 的行业标准是给予厂商 90 天修复期。我们从首次报告到公开等待了 14 天，从 DeepLink 报告到公开等待了 4 天。关键在于：厂商并非”尚在评估中”，而是已明确给出”正常功能，不予修复”的最终定性。当厂商主动关闭了修复对话，等待期的意义已经终止——继续等待不会产生任何不同的结果。

证据保全声明：以上时间线涉及的所有邮件均保存在我们的加密邮件服务器。微信聊天记录的原始截图已保存。如进入司法程序，我们愿意对全部证据进行公证或可信时间戳认证。

八、公共利益：10 亿用户的知情权

《消费者权益保护法》第八条规定：消费者享有知悉其购买、使用的商品或者接受的服务的真实情况的权利。

当一款日活超过 10 亿的支付应用存在可被外部链接利用的攻击面时，用户有权知道：点击一条链接后，他们的设备信息、位置数据可能被以何种方式获取，他们看到的界面是否可能被伪造。

安全研究的价值不在于”攻击”，而在于”预警”。我们在文章中同时提供了 5 项具体的安全加固建议，这是建设性技术讨论，不是恶意抹黑。

九、我们的立场

Innora AI 是独立安全研究机构。我们与投诉方不存在任何商业竞争关系，不从事支付业务，不代表任何竞品利益。

我们的研究基于可复现的技术实验，结论附有完整证据链。文章中每一处涉及攻击条件的描述都标注了前提限定，每一处涉及资金操作的描述都注明了”仍需用户确认”。

我们已向微信公众平台提交完整的申诉材料。

如果投诉方对技术事实有异议，我们愿意通过以下方式解决：

1. 接受第三方技术鉴定机构对 308 条日志的真实性验证

2. 在中立技术专家见证下复现全部测试

3. 如经验证存在不实内容，我们将立即更正并公开致歉

但我们不会因为一封律师函就撤回基于事实的技术研究。用法律手段消除技术事实，从来不是解决安全问题的正确方式。

---

完整技术报告：https://innora.ai/zfb/

联系方式：[email protected]

法律声明：本文所有陈述均基于可验证的技术实验结果（308条服务器日志、3台设备、42张截图）。在线 PoC 页面为只读演示页面，仅展示现象描述与结果截图，不包含任何可直接执行的攻击代码，已禁用全部数据外传功能，不构成《网络安全法》第二十七条所述的”网络攻击工具”。研究遵循负责任披露流程（ISO/IEC 29147:2018），厂商已获充分响应时间并以”正常功能”明确关闭修复对话。根据《民法典》第1025条，为公共利益实施的舆论监督，内容属实且未超出合理限度的，不承担民事责任。根据《消费者权益保护法》第8条，消费者享有知悉其使用服务真实情况的权利。本文不构成法律文件，正式意见以书面法律文书为准。

最后更新：2026-03-12

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：AI-security-innora Feng Ning Feng Ning《支付宝安全研究遭律师函投诉一篇零次提及”支付宝”的文章如何构成”商誉侵权”？》