# 支付宝安全研究遭律师函投诉：完整法律与技术反驳 | Innora AI
回应针对支付宝安全研究的法律投诉(#428526665)：从未提及品牌名的文章不构成声誉侵权。完整法律与技术反驳。
Author: Innora AI Security Research

最后更新: 2026-03-25Last updated: 2026-03-25
LEGAL RESPONSE

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

Innora AI Security Research | 2026-03-12 | 投诉单号 #428526665

2026年3月11日 18:16，我们在微信公众号发布了一篇移动支付应用的 DeepLink 攻击面技术分析文章。

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

投诉单号：428526665

投诉时间：2026-03-11 22:45:59

投诉方：北京格韵律师事务所（31110000MD0196493T）

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

投诉依据：《微信公众平台运营规范》4.1.2条

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

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

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

0
"支付宝"
0
"Alipay"
0
"蚂蚁集团"

全文使用"国民支付应用""某头部支付平台""支付App"等通用表述。

根据《民法典》第 1024 条，名誉权侵权需满足"针对特定主体"的构成要件。一篇未指名任何企业的技术分析文章，从逻辑起点上就不具备商誉侵权的构成基础。

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

## 二、内容属实：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）在中国杭州进行测试。测试过程中：

1. 点击测试链接后，页面加载到 GPS 数据回传仅历时约 7 秒

2. 全程未弹出任何 GPS 授权声明或提示（iPhone 未出现任何系统级或应用级弹窗）

3. 共进行 3 轮测试，GPS 精度逐轮提升：17.4m → 8.8m，均返回 `locationReducedAccuracy: 0`（精确定位模式）

4. 我们的服务器日志完整记录了此次数据回传，坐标指向杭州市区

5. 这次验证首次揭示了 iOS 攻击面显著大于 Android 这一此前未知的事实

这意味着：投诉方声称的"调用位置权限均以弹窗形式告知用户"，被厂商自己的安全团队验证人员的实测所推翻。

更重要的是，这次协同验证还揭示了一个此前未知的事实：iOS 版本的攻击面显著大于 Android 版本。

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

API | Android | iOS | 风险
--- | --- | --- | ---
`tradePay` | 已拦截 | 可用 | 触发支付 SDK，弹出收银台
`share` | 已拦截 | 可用 | 蠕虫传播 — 分享至微信/QQ/钉钉
`getLocation` | 需 checkJSAPI | 直接返回 | 无二次确认获取 GPS
`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. 厂商对接人亲口确认了"正常功能"定性。对方回复"嗯"确认。

2. 厂商对接人承认第一次报告处理有问题。"第一次报公司这边没及时处理确实有问题"——指2月25日的 TLS/SSL 报告。

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

4. 我方在文章发布前已告知厂商。截图泰国时间17:03（北京时间约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 个漏洞，含资金操作风险，附 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
公开研究成果
2026-03-11 22:45
文章发布仅 4 小时 29 分钟后，北京格韵律师事务所提交侵权投诉

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

在一天之内（3月7日），我们连续提交了 3 份递进式报告（8个→17个漏洞→端到端攻击演示），每份都附带更完整的证据。厂商在安排人员亲自验证并确认漏洞可复现后，仍给出"正常功能"的定性。Google Project Zero 的行业标准是给予厂商 90 天。我们从 DeepLink 漏洞报告到公开等待了 4 天，在此期间厂商已明确回复不予修复。

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

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

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

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

## 九、我们的立场

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

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

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

- 接受第三方技术鉴定机构对 308 条日志的真实性验证
- 在中立技术专家见证下复现全部测试
- 如经验证存在不实内容，我们将立即更正并公开致歉

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

← 返回完整技术报告

联系我们：feng@innora.ai

↑