K1.11.4deep link parameter validation设计研究

深链接参数的合法性需要校验,否则成为攻击入口

别名: 深链接校验 · URL scheme hijacking · intent spoofing

概念解释

深链接带着路径和参数进来,这些字段与用户在界面上点出来的输入不同:它们来自邮件、网页、别的应用、甚至短信里的任意字符串。不校验就执行,链接就变成攻击入口——打开不该打开的用户资料、把内置网页指到钓鱼页、用文件路径读沙盒外的内容、用伪造的支付回调把订单标成已付。这条只谈参数作为不可信输入,不谈落点是不是首页,不谈没装时的回退,也不谈办完事怎么回来源。

机制

自定义 URL 方案在不少系统上谁都可以发起,目标应用无法从「链接被点了」推出「发起者可信」。通用链接用域名关联提高了门槛,但查询串、路径段、fragment 仍是调用方写的。应用若把参数直接拼进 SQL、文件路径、WebView 地址或「标记为已支付」的接口,就等于把外部字符串当成了内部命令。常见载荷包括:改 user= 看别人的资料;改 redirect= 让授权结束后打开攻击者的页;用 file:// 或目录穿越读本地文件;伪造 status=success 骗过支付回跳。校验必须在路由分发之前:白名单主机、类型化的标识符、不可从链接写入的状态变更。界面上「看起来像我们自己的一页」并不能证明参数合法,因为深链接本来就会打开应用内真实的页面骨架。

怎么研究

用恶意载荷清单做路由测试,而不是只测产品自己发出的那几条快乐路径。

自变量:参数类型(对象 ID、回调 URL、状态枚举、文件路径)、发起方(本应用、外部浏览器、另一应用)、是否做主机与类型校验。 因变量:是否打开未授权对象、WebView 是否离开可信域、本地文件是否被读到、支付或登录状态是否被链接改写。

安全研究里的意图欺骗、URL 方案劫持、未授权源跨越,用的就是这类载荷。实验室若只从应用内按钮生成链接,永远测不到外部调用方。不要把「通用链接已验证域名」读成参数安全——验证的是主机,不是查询串里的字段。

边界

公开内容的只读深链接(一篇帮助文章的 ID)被猜到,损失通常是信息暴露而不是账户接管,校验强度可以低于写操作。来自同一应用、经系统关联验证的回调仍要把状态改写限制在服务端可核对的一次性令牌上,不能只信查询串里的 success。调试用的内部方案在发版后若仍可被外部唤起,等于把调试入口留在生产。桌面端的自定义协议有类似问题,但移动端还叠加了应用可被任意其他应用唤起这一层。

怎么落地

  • 把所有深链接字段当不可信输入:对象 ID 要在当前用户权限下可解析,回调 URL 只允许白名单主机,状态变更不得只靠链接里的枚举完成。
  • 内置网页只加载允许列表上的地址;拒绝 javascript:、未知方案和目录穿越路径。
  • 验证:构造三条产品自己不会发出的链接——别人的对象 ID、指向外部主机的跳转、把订单标为成功的回调。应分别落到无权限、拒绝跳转、忽略状态改写;若任何一条改变了不该改变的数据,路由在执行前没有完成校验。

延伸

  • 同组K1.11.1 深链接指向应用内具体页面而非仅打开首页 · K1.11.2 目标应用未安装时需要有回退路径而非直接失败 · K1.11.3 跳转后返回来源应用的路径需要保留
  • 相邻K8.01 任务接续 · O3.04 钓鱼识别线索
  • 站内检索intent spoofing · URL scheme hijacking · deep link validation

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/K1.11.4