3
年
来到社区 3 年
LEVEL 100
XP
一、背景：为什么移动安全审计不能只靠“把代码丢给 AI”
在 Android、iOS 应用安全测试中，审计人员通常需要同时处理反编译代码、应用配置、第三方 SDK、抓包记录、接口文档和扫描器告警。AI 很适合归纳这些材料、追踪数据流并生成检查清单，但它也可能误解反编译代码、虚构不存在的调用路径，或者将正常业务逻辑判断为漏洞。
因此，可靠用法不是让模型直接宣布“发现高危漏洞”，而是让它充当证据整理与审计辅助工具：每一项结论必须绑定文件、行号、请求样本或可复现实验，并由人工或自动化规则复核。本文给出一套适用于授权靶场、本地测试应用和企业内部防御审计的工作流，重点覆盖 Android APK、移动端接口和抓包数据。所有操作都应限定在自有应用、明确授权项目或专用训练环境中。
二、核心原理：检索、规则和模型三者分工
可靠的 AI 安全审计可以拆成三层：
1. 确定性工具层：使用 JADX、Apktool、Semgrep、MobSF、mitmproxy 等工具获取事实，例如导出组件、危险权限、硬编码地址和实际 HTTP 请求。
2. 检索增强层：把代码片段、配置和脱敏后的流量记录建立索引。提问时只向模型提供相关材料，减少模型脱离证据自由发挥。
3. 推理与复核层：让模型提出风险假设、验证步骤和修复建议，而不是直接给出不可复核的定论。最终结论要经过规则扫描、人工代码审查或本地实验确认。
建议要求每条发现都采用统一格式：风险描述、证据位置、触发前提、验证状态、影响范围、修复方案、置信度。缺少证据时，只能标记为“待验证线索”。
三、前置条件
准备一台隔离的 Linux 或 macOS 测试机，并安装 Python 3、JDK、Android SDK、JADX、Apktool、Semgrep 和 mitmproxy。测试对象应为本地构建的 Debug APK、DIVA、InsecureShop 等授权靶场，或者企业明确授权的内部包。
可选组件包括本地大语言模型服务、企业内部模型网关和向量数据库。如果代码或流量包含商业机密、令牌、手机号、设备标识符等敏感信息，不应直接上传到公共模型服务。即使使用本地模型，也应设置访问控制、日志保留周期和磁盘加密。
建立工作目录：
mkdir -p mobile-ai-audit/{input,decompiled,traffic,findings,scripts}
cp demo-debug.apk mobile-ai-audit/input/app.apk
cd mobile-ai-audit
sha256sum input/app.apk | tee findings/sample_hash.txt
记录文件哈希的目的是保证后续分析对象一致，避免团队成员对不同版本得出冲突结论。
四、分步骤实践
步骤 1：提取 APK 的可验证事实
先反编译 APK，不要一开始就让 AI 猜测应用结构：
jadx -d decompiled/jadx input/app.apk
apktool d -f input/app.apk -o decompiled/apktool
重点保存 AndroidManifest.xml、network_security_config.xml、资源文件、Java 或 Kotlin 反编译结果。随后执行基础搜索：
grep -RInE 'http://|https://|api[_-]?key|secret|token|WebView|addJavascriptInterface' decompiled/jadx > findings/keyword_hits.txt
这些命中不等于漏洞。例如，源码中出现 token 可能只是字段名；出现 http 地址可能仅属于测试资源。AI 的任务是对命中项分类，并指出还需要什么证据。
步骤 2：使用 Semgrep 生成稳定的代码线索
可以先运行社区规则，再加入适合移动端的内部规则：
semgrep scan --config auto decompiled/jadx --json -o findings/semgrep.json
下面是一条简化的本地规则，用于寻找 WebView 中启用 JavaScript 的位置。它只是审计入口，不能单独证明存在可利用漏洞：
rules:
- id: android-webview-js-enabled
languages: [java]
message: WebView 启用了 JavaScript，请核对加载来源与桥接接口
severity: WARNING
patterns:
- pattern: $W.getSettings().setJavaScriptEnabled(true)
要求 AI 结合以下问题分析：WebView 加载的是固定可信资源还是外部可控 URL；是否存在 addJavascriptInterface；是否允许 file 或 content 访问；是否存在不安全的证书错误忽略逻辑。只有多项条件形成完整链路时，才能提升风险等级。
步骤 3：清洗抓包数据后再交给模型
在授权测试设备或模拟器上配置 mitmproxy，采集测试账号产生的业务流量：
mitmweb --listen-host 127.0.0.1 --listen-port 8080 -w traffic/demo.flows
不要为了抓包去破坏真实应用的安全控制。若自有 Debug 应用使用证书固定，应由开发团队提供仅限测试构建的调试开关或测试证书配置，生产版本仍需保持固定策略。
导出文本前，应删除 Authorization、Cookie、手机号、邮箱、设备 ID 和完整响应正文中的个人数据。可以通过 mitmproxy 脚本进行脱敏：
from mitmproxy import http
SENSITIVE = {"authorization", "cookie", "set-cookie", "x-api-key"}
def request(flow: http.HTTPFlow):
for key in list(flow.request.headers.keys()):
if key.lower() in SENSITIVE:
flow.request.headers[key] = "[REDACTED]"
def response(flow: http.HTTPFlow):
for key in list(flow.response.headers.keys()):
if key.lower() in SENSITIVE:
flow.response.headers[key] = "[REDACTED]"
运行方式：
mitmdump -s scripts/redact.py -r traffic/demo.flows -w traffic/demo-redacted.flows
步骤 4：设计“证据优先”的 AI 提示模板
不要使用“帮我找出所有漏洞”这种宽泛指令。推荐模板如下：
角色：移动应用安全审计助手。
约束：只能依据提供的代码、配置和脱敏请求作答；不得补全不存在的代码；证据不足时标记待验证。
任务：检查组件暴露、WebView、明文传输、凭据存储、接口鉴权和日志泄露。
输出字段：编号、风险假设、证据文件与行号、触发条件、验证步骤、误报可能性、修复方案、置信度。
风险评级规则：必须同时说明攻击前提和实际影响，否则不得评为高危。
如果使用检索增强，应以函数、类或配置节点为基本切片，并保留原始路径和行号。切片过小会丢失上下文，切片过大则会降低检索准确率。实践中可优先围绕 Activity、Service、ContentProvider、网络客户端和 WebView 封装类建立索引。
步骤 5：验证导出组件，而不是相信模型判断
假设模型根据 Manifest 提示某个 Activity 存在 android:exported="true"。下一步应检查它是否有权限保护、是否验证 Intent 参数，以及是否仅为系统回调所需。
在本地模拟器和自有 Debug 包中，可以使用以下命令确认组件信息：
adb shell dumpsys package com.example.demo | grep -A 20 Activity
adb shell am start -n com.example.demo/.DebugActivity
如果组件无法启动、要求签名权限，或者内部再次完成身份校验，就不能简单认定为未授权访问。反之，如果组件接受外部输入并执行敏感操作，应记录完整复现条件，同时修复为不导出、增加 signature 级权限或在入口进行调用方与业务权限校验。
步骤 6：审查接口鉴权与对象级权限
AI 可以将脱敏流量按接口、方法、状态码和资源类型聚类，帮助发现同类接口的鉴权方式不一致。例如同一业务下，大部分接口返回 401，而某个读取接口在无会话状态下返回 200，这是一条值得核查的线索。
验证必须在本地 API、专用测试环境和测试账号中完成。建议编写回归测试，而不是手工反复修改真实用户标识：
import requests
BASE = "http://127.0.0.1:8000"
def test_profile_requires_auth():
r = requests.get(f"{BASE}/api/profile/1001", timeout=5)
assert r.status_code in (401, 403)
针对对象级授权，应分别使用账号 A 和账号 B 创建的测试数据，确认服务端根据当前会话判断资源归属，而不是只相信客户端传入的 userId。修复重点始终在服务端；隐藏按钮、加密参数或在 APK 中增加判断都不能替代服务端授权。
步骤 7：输出可追踪的审计报告
每条发现建议保存为 JSON 或工单字段。例如：
{
"id": "MOB-007",
"status": "confirmed",
"category": "Exported Component",
"evidence": ["AndroidManifest.xml:84", "DebugActivity.java:41"],
"precondition": "同设备上的普通第三方应用可发送显式 Intent",
"impact": "可打开内部调试页面，但未观察到敏感数据读取",
"severity": "medium",
"confidence": 0.92,
"remediation": "生产构建移除调试组件，并设置 exported=false"
}
这里的置信度表达证据充分程度，不应由模型凭感觉给出。可以规定：只有规则命中、人工复核和实验复现三项均满足时，才允许高置信度；只有关键词命中时，最高只能标为低置信度。
五、风险与注意事项
第一，数据泄露风险。APK 反编译代码、接口响应和日志可能含有密钥、个人信息及未发布功能。上传外部模型前必须脱敏，并确认供应商的数据保留和训练政策。
第二，提示注入风险。代码注释、接口返回或日志内容都可能包含类似“忽略前述规则”的文本。检索系统应把这些内容视为不可信数据，不能让材料中的指令改变系统约束。
第三，幻觉和误报。模型可能把 Android 生命周期、混淆后的类名或第三方库逻辑解释错误。高风险结论必须能回到原始文件，并经过编译环境或模拟器验证。
第四，自动修复风险。不要让模型未经审查直接修改生产代码。安全修复可能影响单点登录、深链、推送、WebView 混合页面和证书轮换。应通过分支提交、代码评审和自动化测试落地。
第五，工具覆盖边界。静态分析看不到所有运行时拼接地址和服务端授权逻辑；动态抓包也无法覆盖所有业务状态。两者应交叉验证，并结合后端日志与接口测试。
六、常见问题
问题 1：可以直接让 AI 给 APK 打风险分吗？
不建议。总分容易掩盖证据不足。更合理的方式是先按组件、数据存储、网络传输、接口鉴权和第三方 SDK 分类，再对已确认问题评级。
问题 2：模型识别出硬编码密钥，就一定是高危吗？
不一定。需要判断它是公开标识符、测试值还是能够访问敏感资源的真实凭据。移动客户端无法安全保存长期共享秘密，真正敏感的权限应放在服务端，并支持轮换、最小权限和吊销。
问题 3：抓不到 HTTPS 流量怎么办？
优先使用企业自有 Debug 构建、测试证书和开发团队提供的日志能力。不要把绕过生产应用安全机制当作默认方案。很多鉴权问题也可以通过服务端集成测试和测试环境网关日志验证。
问题 4：怎样判断 AI 是否真的提高了效率？
可以记录人工确认率、误报率、平均定位时间、重复问题聚合率以及修复建议采纳率。若模型输出很多“可能存在风险”却无法给出文件和验证方法，就说明流程需要收紧。
七、总结
AI 在移动应用安全中的可靠价值，不是替代审计人员完成最终裁决，而是把分散的 APK 代码、配置、扫描结果和脱敏流量整理成可验证的风险假设。最稳妥的工作流是：确定性工具采集事实，检索系统提供相关上下文，模型生成带证据的分析，最后由授权实验和人工审查确认。
当每条结论都能回答“证据在哪里、什么条件下触发、如何安全复现、怎样修复、如何回归验证”时，AI 才真正进入安全工程流程，而不是成为另一个制造告警的黑盒。
在 Android、iOS 应用安全测试中，审计人员通常需要同时处理反编译代码、应用配置、第三方 SDK、抓包记录、接口文档和扫描器告警。AI 很适合归纳这些材料、追踪数据流并生成检查清单，但它也可能误解反编译代码、虚构不存在的调用路径，或者将正常业务逻辑判断为漏洞。
因此，可靠用法不是让模型直接宣布“发现高危漏洞”，而是让它充当证据整理与审计辅助工具：每一项结论必须绑定文件、行号、请求样本或可复现实验，并由人工或自动化规则复核。本文给出一套适用于授权靶场、本地测试应用和企业内部防御审计的工作流，重点覆盖 Android APK、移动端接口和抓包数据。所有操作都应限定在自有应用、明确授权项目或专用训练环境中。
二、核心原理：检索、规则和模型三者分工
可靠的 AI 安全审计可以拆成三层：
1. 确定性工具层：使用 JADX、Apktool、Semgrep、MobSF、mitmproxy 等工具获取事实，例如导出组件、危险权限、硬编码地址和实际 HTTP 请求。
2. 检索增强层：把代码片段、配置和脱敏后的流量记录建立索引。提问时只向模型提供相关材料，减少模型脱离证据自由发挥。
3. 推理与复核层：让模型提出风险假设、验证步骤和修复建议，而不是直接给出不可复核的定论。最终结论要经过规则扫描、人工代码审查或本地实验确认。
建议要求每条发现都采用统一格式：风险描述、证据位置、触发前提、验证状态、影响范围、修复方案、置信度。缺少证据时，只能标记为“待验证线索”。
三、前置条件
准备一台隔离的 Linux 或 macOS 测试机，并安装 Python 3、JDK、Android SDK、JADX、Apktool、Semgrep 和 mitmproxy。测试对象应为本地构建的 Debug APK、DIVA、InsecureShop 等授权靶场，或者企业明确授权的内部包。
可选组件包括本地大语言模型服务、企业内部模型网关和向量数据库。如果代码或流量包含商业机密、令牌、手机号、设备标识符等敏感信息，不应直接上传到公共模型服务。即使使用本地模型，也应设置访问控制、日志保留周期和磁盘加密。
建立工作目录：
mkdir -p mobile-ai-audit/{input,decompiled,traffic,findings,scripts}
cp demo-debug.apk mobile-ai-audit/input/app.apk
cd mobile-ai-audit
sha256sum input/app.apk | tee findings/sample_hash.txt
记录文件哈希的目的是保证后续分析对象一致，避免团队成员对不同版本得出冲突结论。
四、分步骤实践
步骤 1：提取 APK 的可验证事实
先反编译 APK，不要一开始就让 AI 猜测应用结构：
jadx -d decompiled/jadx input/app.apk
apktool d -f input/app.apk -o decompiled/apktool
重点保存 AndroidManifest.xml、network_security_config.xml、资源文件、Java 或 Kotlin 反编译结果。随后执行基础搜索：
grep -RInE 'http://|https://|api[_-]?key|secret|token|WebView|addJavascriptInterface' decompiled/jadx > findings/keyword_hits.txt
这些命中不等于漏洞。例如，源码中出现 token 可能只是字段名；出现 http 地址可能仅属于测试资源。AI 的任务是对命中项分类，并指出还需要什么证据。
步骤 2：使用 Semgrep 生成稳定的代码线索
可以先运行社区规则，再加入适合移动端的内部规则：
semgrep scan --config auto decompiled/jadx --json -o findings/semgrep.json
下面是一条简化的本地规则，用于寻找 WebView 中启用 JavaScript 的位置。它只是审计入口，不能单独证明存在可利用漏洞：
rules:
- id: android-webview-js-enabled
languages: [java]
message: WebView 启用了 JavaScript，请核对加载来源与桥接接口
severity: WARNING
patterns:
- pattern: $W.getSettings().setJavaScriptEnabled(true)
要求 AI 结合以下问题分析：WebView 加载的是固定可信资源还是外部可控 URL；是否存在 addJavascriptInterface；是否允许 file 或 content 访问；是否存在不安全的证书错误忽略逻辑。只有多项条件形成完整链路时，才能提升风险等级。
步骤 3：清洗抓包数据后再交给模型
在授权测试设备或模拟器上配置 mitmproxy，采集测试账号产生的业务流量：
mitmweb --listen-host 127.0.0.1 --listen-port 8080 -w traffic/demo.flows
不要为了抓包去破坏真实应用的安全控制。若自有 Debug 应用使用证书固定，应由开发团队提供仅限测试构建的调试开关或测试证书配置，生产版本仍需保持固定策略。
导出文本前，应删除 Authorization、Cookie、手机号、邮箱、设备 ID 和完整响应正文中的个人数据。可以通过 mitmproxy 脚本进行脱敏：
from mitmproxy import http
SENSITIVE = {"authorization", "cookie", "set-cookie", "x-api-key"}
def request(flow: http.HTTPFlow):
for key in list(flow.request.headers.keys()):
if key.lower() in SENSITIVE:
flow.request.headers[key] = "[REDACTED]"
def response(flow: http.HTTPFlow):
for key in list(flow.response.headers.keys()):
if key.lower() in SENSITIVE:
flow.response.headers[key] = "[REDACTED]"
运行方式：
mitmdump -s scripts/redact.py -r traffic/demo.flows -w traffic/demo-redacted.flows
步骤 4：设计“证据优先”的 AI 提示模板
不要使用“帮我找出所有漏洞”这种宽泛指令。推荐模板如下：
角色：移动应用安全审计助手。
约束：只能依据提供的代码、配置和脱敏请求作答；不得补全不存在的代码；证据不足时标记待验证。
任务：检查组件暴露、WebView、明文传输、凭据存储、接口鉴权和日志泄露。
输出字段：编号、风险假设、证据文件与行号、触发条件、验证步骤、误报可能性、修复方案、置信度。
风险评级规则：必须同时说明攻击前提和实际影响，否则不得评为高危。
如果使用检索增强，应以函数、类或配置节点为基本切片，并保留原始路径和行号。切片过小会丢失上下文，切片过大则会降低检索准确率。实践中可优先围绕 Activity、Service、ContentProvider、网络客户端和 WebView 封装类建立索引。
步骤 5：验证导出组件，而不是相信模型判断
假设模型根据 Manifest 提示某个 Activity 存在 android:exported="true"。下一步应检查它是否有权限保护、是否验证 Intent 参数，以及是否仅为系统回调所需。
在本地模拟器和自有 Debug 包中，可以使用以下命令确认组件信息：
adb shell dumpsys package com.example.demo | grep -A 20 Activity
adb shell am start -n com.example.demo/.DebugActivity
如果组件无法启动、要求签名权限，或者内部再次完成身份校验，就不能简单认定为未授权访问。反之，如果组件接受外部输入并执行敏感操作，应记录完整复现条件，同时修复为不导出、增加 signature 级权限或在入口进行调用方与业务权限校验。
步骤 6：审查接口鉴权与对象级权限
AI 可以将脱敏流量按接口、方法、状态码和资源类型聚类，帮助发现同类接口的鉴权方式不一致。例如同一业务下，大部分接口返回 401，而某个读取接口在无会话状态下返回 200，这是一条值得核查的线索。
验证必须在本地 API、专用测试环境和测试账号中完成。建议编写回归测试，而不是手工反复修改真实用户标识：
import requests
BASE = "http://127.0.0.1:8000"
def test_profile_requires_auth():
r = requests.get(f"{BASE}/api/profile/1001", timeout=5)
assert r.status_code in (401, 403)
针对对象级授权，应分别使用账号 A 和账号 B 创建的测试数据，确认服务端根据当前会话判断资源归属，而不是只相信客户端传入的 userId。修复重点始终在服务端；隐藏按钮、加密参数或在 APK 中增加判断都不能替代服务端授权。
步骤 7：输出可追踪的审计报告
每条发现建议保存为 JSON 或工单字段。例如：
{
"id": "MOB-007",
"status": "confirmed",
"category": "Exported Component",
"evidence": ["AndroidManifest.xml:84", "DebugActivity.java:41"],
"precondition": "同设备上的普通第三方应用可发送显式 Intent",
"impact": "可打开内部调试页面，但未观察到敏感数据读取",
"severity": "medium",
"confidence": 0.92,
"remediation": "生产构建移除调试组件，并设置 exported=false"
}
这里的置信度表达证据充分程度，不应由模型凭感觉给出。可以规定：只有规则命中、人工复核和实验复现三项均满足时，才允许高置信度；只有关键词命中时，最高只能标为低置信度。
五、风险与注意事项
第一，数据泄露风险。APK 反编译代码、接口响应和日志可能含有密钥、个人信息及未发布功能。上传外部模型前必须脱敏，并确认供应商的数据保留和训练政策。
第二，提示注入风险。代码注释、接口返回或日志内容都可能包含类似“忽略前述规则”的文本。检索系统应把这些内容视为不可信数据，不能让材料中的指令改变系统约束。
第三，幻觉和误报。模型可能把 Android 生命周期、混淆后的类名或第三方库逻辑解释错误。高风险结论必须能回到原始文件，并经过编译环境或模拟器验证。
第四，自动修复风险。不要让模型未经审查直接修改生产代码。安全修复可能影响单点登录、深链、推送、WebView 混合页面和证书轮换。应通过分支提交、代码评审和自动化测试落地。
第五，工具覆盖边界。静态分析看不到所有运行时拼接地址和服务端授权逻辑；动态抓包也无法覆盖所有业务状态。两者应交叉验证，并结合后端日志与接口测试。
六、常见问题
问题 1：可以直接让 AI 给 APK 打风险分吗？
不建议。总分容易掩盖证据不足。更合理的方式是先按组件、数据存储、网络传输、接口鉴权和第三方 SDK 分类，再对已确认问题评级。
问题 2：模型识别出硬编码密钥，就一定是高危吗？
不一定。需要判断它是公开标识符、测试值还是能够访问敏感资源的真实凭据。移动客户端无法安全保存长期共享秘密，真正敏感的权限应放在服务端，并支持轮换、最小权限和吊销。
问题 3：抓不到 HTTPS 流量怎么办？
优先使用企业自有 Debug 构建、测试证书和开发团队提供的日志能力。不要把绕过生产应用安全机制当作默认方案。很多鉴权问题也可以通过服务端集成测试和测试环境网关日志验证。
问题 4：怎样判断 AI 是否真的提高了效率？
可以记录人工确认率、误报率、平均定位时间、重复问题聚合率以及修复建议采纳率。若模型输出很多“可能存在风险”却无法给出文件和验证方法，就说明流程需要收紧。
七、总结
AI 在移动应用安全中的可靠价值，不是替代审计人员完成最终裁决，而是把分散的 APK 代码、配置、扫描结果和脱敏流量整理成可验证的风险假设。最稳妥的工作流是：确定性工具采集事实，检索系统提供相关上下文，模型生成带证据的分析，最后由授权实验和人工审查确认。
当每条结论都能回答“证据在哪里、什么条件下触发、如何安全复现、怎样修复、如何回归验证”时，AI 才真正进入安全工程流程，而不是成为另一个制造告警的黑盒。