3
年
来到社区 3 年
LEVEL 100
XP
一、背景：为什么不能把源码直接交给 AI
在移动应用安全审计中，AI 很适合解释代码、归纳告警、关联数据流和生成修复建议，但不适合在缺少证据时直接判断某个 APP 是否存在漏洞。Android 项目往往包含 Kotlin、Java、Manifest、WebView、第三方 SDK、Gradle 配置和服务端接口定义，仅截取一个函数，容易忽略调用条件、组件导出状态、系统版本以及服务端校验。
更可靠的做法是让传统工具负责发现事实，让 AI 负责分析上下文：Semgrep 查找源码模式，MobSF 汇总 Manifest、证书和组件风险，JADX 辅助检查本地授权样本，AI 则用于告警去重、攻击面建模、修复方案比较和复核清单生成。最终结论必须能回到文件、行号、配置项或可重复的本地测试结果，而不是依赖模型的一句话。
本文只针对自有代码、授权靶场或本地实验 APK，不涉及对真实第三方目标的未授权测试。
二、核心原理：把 AI 放在证据链中间
推荐采用“输入约束—工具扫描—AI 归纳—人工验证—回归测试”的流程。
1. 输入约束：明确应用版本、测试范围、最低 Android 版本、是否允许联网，以及哪些文件禁止上传。
2. 工具扫描：使用静态规则输出文件路径、行号和规则编号，避免只给 AI 一段脱离上下文的代码。
3. AI 归纳：要求模型区分“已确认事实”“合理推断”“待验证问题”，并引用证据编号。
4. 人工验证：安全工程师检查真实调用链、权限边界、数据来源及服务端防护。
5. 回归测试：修复后重新执行同一规则和单元测试，确保风险消失且业务没有被破坏。
这种设计的重点不是让 AI 取代审计人员，而是降低重复阅读成本，同时限制幻觉对最终报告的影响。
三、前置条件
准备一台本地 Linux、macOS 或 Windows 开发机，并确保拥有待审计项目的明确授权。建议具备以下环境：
• JDK 与项目匹配的 Android SDK；
• Python 3 和 Semgrep；
• Docker，用于隔离运行 MobSF；
• Android Studio 或项目自带的 Gradle Wrapper；
• 可选的 JADX，仅用于分析自有或授权 APK；
• 一个支持本地部署或企业数据隔离策略的语言模型环境。
安装 Semgrep：
python3 -m pip install semgrep
semgrep --version
启动本地 MobSF：
docker pull opensecurity/mobile-security-framework-mobsf:latest
docker run --rm -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
浏览器访问 http://127.0.0.1:8000，并且只上传获准分析的 APK。实际团队环境应固定镜像版本或摘要，对镜像进行来源校验，避免长期依赖浮动的 latest 标签。
四、分步骤实践
步骤 1：建立审计范围与资产清单
先记录项目提交号、构建变体和扫描日期：
git rev-parse HEAD
./gradlew tasks
建议将范围写入 audit-scope.txt，例如：
应用：内部 Android 演示项目
提交：填写实际 Git Commit
变体：debug
重点：导出组件、WebView、日志泄露、本地存储、TLS 配置
排除：生成代码、测试夹具、第三方开源依赖源码
数据要求：源码不得发送到公共模型
这一步可以避免 AI 将测试代码、废弃代码或第三方库告警误认为生产问题。
步骤 2：完成可重复构建
在项目根目录执行：
./gradlew clean assembleDebug
./gradlew testDebugUnitTest
如果构建失败，应先保存错误信息并解决依赖问题。无法构建不代表无法静态扫描，但会降低对构建变体、资源合并结果和最终 Manifest 的判断可信度。
步骤 3：运行基础静态扫描
对源码执行 Semgrep：
semgrep scan --config auto --json --output semgrep-results.json .
对自定义 Android 规则，建议单独建立 rules/android.yml。下面是一条用于发现 WebView 高风险组合的示例规则：
rules:
- id: android-webview-js-interface-review
languages: [java]
severity: WARNING
message: WebView 同时启用 JavaScript 与 JavaScript 接口，需要确认页面来源和接口暴露范围
patterns:
- pattern-inside: |
$W = ...;
...
- pattern: $W.getSettings().setJavaScriptEnabled(true)
- pattern: $W.addJavascriptInterface(...)
执行：
semgrep scan --config rules/android.yml --json --output android-review.json app/src
这类规则只能提示“需要复核”，不能单独证明漏洞成立。两个调用可能位于不同分支，WebView 也可能只加载受信任的本地页面，因此必须结合数据流和运行条件判断。
步骤 4：用 MobSF 提取应用级攻击面
构建 APK 后上传到本地 MobSF：
find app/build/outputs/apk -name "*.apk"
重点查看：
• Activity、Service、Receiver、Provider 的 exported 状态；
• 自定义权限及 protectionLevel；
• Network Security Config；
• WebView 配置与明文流量策略；
• 签名、调试标志和备份配置；
• 硬编码地址、令牌特征及第三方 SDK。
不要把 MobSF 的每一项提示都直接写成漏洞。例如，组件被导出可能是 Deep Link 的业务需要，真正需要确认的是：外部输入能否触发敏感操作、是否存在身份校验、参数校验和二次确认。
步骤 5：向 AI 提供结构化证据，而不是整个仓库
将告警整理成最小必要上下文：
证据 E-01：app/src/main/AndroidManifest.xml，第 42 至 55 行，PaymentActivity 设置 exported=true，并声明自定义 Scheme。
证据 E-02：PaymentActivity.kt，第 31 至 48 行，从 Intent 读取 orderId。
证据 E-03：PaymentRepository.kt，第 72 行，提交请求前会从本地会话读取用户令牌。
未知项：服务端是否校验 orderId 与当前用户的归属关系。
可使用如下提示模板：
“你是移动应用安全审计辅助工具。只根据提供的证据分析，不补充不存在的代码。输出：已确认事实、潜在攻击前提、需要人工验证的问题、修复建议、回归测试。每个判断引用证据编号；证据不足时明确写无法确认。不要把 exported=true 自动判定为漏洞。”
这种模板能明显减少模型过度下结论的问题。涉及源码、密钥、客户数据或未发布功能时，应优先使用本地模型；如必须调用外部服务，应先完成脱敏，并确认组织的数据处理政策。
步骤 6：人工验证一个 WebView 告警
假设源码中存在以下本地实验代码：
webView.settings.javaScriptEnabled = true
webView.addJavascriptInterface(AppBridge(), "AppBridge")
webView.loadUrl(intent.getStringExtra("url") ?: "file:///android_asset/index.html")
风险不只在于启用了 JavaScript，而在于页面地址可能来自外部 Intent，同时页面能够调用原生桥接对象。如果 AppBridge 暴露敏感能力，加载不受信任页面就可能扩大攻击面。
推荐修复思路：
1. 不需要 JavaScript 时直接关闭；
2. 不需要原生桥时移除 addJavascriptInterface；
3. 页面地址使用固定本地资源，或执行严格的协议、主机和路径白名单校验；
4. 桥接接口保持最小能力，不传递令牌，不直接执行支付、文件读取等敏感操作；
5. 对敏感业务动作在原生层和服务端同时重新鉴权；
6. 使用 WebViewClient 拦截非预期跳转，但不要仅用字符串 contains 判断域名。
一个更安全的本地页面方案是：
webView.settings.javaScriptEnabled = false
webView.loadUrl("file:///android_asset/index.html")
如果业务必须加载 HTTPS 页面，应先用 URI 解析结果检查 scheme 和 host，并结合实际重定向策略测试。白名单应使用精确主机匹配，不能把 evil-example.com 误认为 example.com 的子域。
步骤 7：验证导出组件和接口授权边界
对于 exported Activity，应检查 Intent 参数是否直接控制订单、账号、文件路径或 WebView URL。对于网络接口，应确认服务端是否根据当前认证身份重新校验资源归属，不能只信任客户端传入的 userId 或 orderId。
本地验证可通过 Android 单元测试、Instrumentation 测试或调试构建完成。测试目标是证明非法输入会被拒绝，而不是尝试访问真实用户数据。示例伪测试逻辑：
• 未登录状态打开敏感 Deep Link，应跳转登录页；
• 登录用户提交不属于自己的测试订单编号，测试服务端应返回拒绝；
• Scheme、Host 或路径不在白名单时，Activity 应立即结束；
• 超长、空值和编码异常参数不应造成崩溃或绕过。
步骤 8：形成可追踪报告并回归
每个问题至少记录：规则编号、证据位置、影响条件、可信度、修复负责人和回归结果。修复后重新执行：
semgrep scan --config rules/android.yml app/src
./gradlew testDebugUnitTest
./gradlew assembleDebug
如果使用 Git 管理规则，可以让 CI 在新增高置信度问题时失败，但建议先运行一段观察期，避免误报阻断开发。AI 生成的修复代码必须经过代码评审、编译、测试和安全复核，不能直接合并。
五、可靠性控制与风险注意事项
第一，防止源码泄露。不要把完整仓库、签名文件、配置中心密钥、生产接口样本或用户数据粘贴到公共模型。即使模型服务声明不用于训练，也应按组织合规要求评估数据存储位置、保留时间和访问控制。
第二，防止提示注入。仓库中的注释、README、资源文件和扫描样本都属于不可信输入。如果文件里出现“忽略之前规则”之类文本，AI 不应执行。系统应明确规定：代码内容只作为待分析数据，不能改变审计策略。
第三，警惕误报与漏报。模式匹配工具可能忽略反射、动态加载、JNI 和复杂数据流；AI 也可能虚构调用链。高风险结论必须至少有源码证据、构建产物证据或本地可重复测试中的一种，最好两种以上相互印证。
第四，修复不能只发生在客户端。移动客户端可被逆向和修改，鉴权、资源归属、交易限制等关键控制必须由服务端执行。客户端校验主要用于降低误操作和缩小攻击面，不能替代服务端授权。
第五，保留审计记录。建议保存模型版本、提示模板哈希、输入证据编号和最终人工决策，但不要在日志中重复保存敏感源码。这样才能在模型升级后比较结果变化。
六、常见问题
问：AI 能否直接替代 Semgrep 或 MobSF？
答：不建议。传统工具输出稳定的规则编号、文件位置和可重复结果，AI 更适合解释、归并和生成验证计划。两者组合比单独使用更可靠。
问：发现硬编码字符串就一定是密钥泄露吗？
答：不是。可能是测试值、公开 API 标识、占位符或无敏感性的常量。需要确认构建变体、实际权限、是否仍有效以及服务端是否把它当作认证凭据。不要为了验证而调用真实第三方接口。
问：exported=true 是否必须改为 false？
答：不一定。Deep Link、分享入口和系统回调可能需要导出。正确做法是最小化导出组件，并对调用来源、会话状态、参数和敏感动作进行验证。
问：如何衡量 AI 审计是否有效？
答：可建立一组经过人工确认的内部样例，统计高风险问题的准确率、召回情况、人工复核耗时和无证据结论比例。不要只看模型生成了多少条告警。
问：能否让 AI 自动提交修复代码？
答：可以生成候选补丁，但不应自动进入生产分支。至少需要编译、测试、人工评审和安全回归；涉及认证、加密、证书校验和支付流程时，还应由对应领域负责人复核。
七、总结
AI 在 Android 安全审计中的可靠价值，不是凭空寻找漏洞，而是把 Semgrep、MobSF、构建产物和人工经验连接起来。一个可落地的流程应做到：只处理授权目标；以工具证据为基础；明确区分事实、推断与未知项；控制源码和数据外泄；对高风险结论进行人工验证；修复后执行可重复回归。
对于安全团队而言，最值得持续建设的不是越来越长的提示词，而是版本化的审计规则、结构化证据格式、内部验证样例和回归测试。只有当每个结论都能追溯、每个修复都能验证、每次模型输出都受权限和数据边界约束时，AI 才能真正成为安全运营与移动代码审计中的可靠工具。
在移动应用安全审计中，AI 很适合解释代码、归纳告警、关联数据流和生成修复建议，但不适合在缺少证据时直接判断某个 APP 是否存在漏洞。Android 项目往往包含 Kotlin、Java、Manifest、WebView、第三方 SDK、Gradle 配置和服务端接口定义，仅截取一个函数，容易忽略调用条件、组件导出状态、系统版本以及服务端校验。
更可靠的做法是让传统工具负责发现事实，让 AI 负责分析上下文：Semgrep 查找源码模式，MobSF 汇总 Manifest、证书和组件风险，JADX 辅助检查本地授权样本，AI 则用于告警去重、攻击面建模、修复方案比较和复核清单生成。最终结论必须能回到文件、行号、配置项或可重复的本地测试结果，而不是依赖模型的一句话。
本文只针对自有代码、授权靶场或本地实验 APK，不涉及对真实第三方目标的未授权测试。
二、核心原理：把 AI 放在证据链中间
推荐采用“输入约束—工具扫描—AI 归纳—人工验证—回归测试”的流程。
1. 输入约束：明确应用版本、测试范围、最低 Android 版本、是否允许联网，以及哪些文件禁止上传。
2. 工具扫描：使用静态规则输出文件路径、行号和规则编号，避免只给 AI 一段脱离上下文的代码。
3. AI 归纳：要求模型区分“已确认事实”“合理推断”“待验证问题”，并引用证据编号。
4. 人工验证：安全工程师检查真实调用链、权限边界、数据来源及服务端防护。
5. 回归测试：修复后重新执行同一规则和单元测试，确保风险消失且业务没有被破坏。
这种设计的重点不是让 AI 取代审计人员，而是降低重复阅读成本，同时限制幻觉对最终报告的影响。
三、前置条件
准备一台本地 Linux、macOS 或 Windows 开发机，并确保拥有待审计项目的明确授权。建议具备以下环境：
• JDK 与项目匹配的 Android SDK；
• Python 3 和 Semgrep；
• Docker，用于隔离运行 MobSF；
• Android Studio 或项目自带的 Gradle Wrapper；
• 可选的 JADX，仅用于分析自有或授权 APK；
• 一个支持本地部署或企业数据隔离策略的语言模型环境。
安装 Semgrep：
python3 -m pip install semgrep
semgrep --version
启动本地 MobSF：
docker pull opensecurity/mobile-security-framework-mobsf:latest
docker run --rm -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
浏览器访问 http://127.0.0.1:8000，并且只上传获准分析的 APK。实际团队环境应固定镜像版本或摘要，对镜像进行来源校验，避免长期依赖浮动的 latest 标签。
四、分步骤实践
步骤 1：建立审计范围与资产清单
先记录项目提交号、构建变体和扫描日期：
git rev-parse HEAD
./gradlew tasks
建议将范围写入 audit-scope.txt，例如：
应用：内部 Android 演示项目
提交：填写实际 Git Commit
变体：debug
重点：导出组件、WebView、日志泄露、本地存储、TLS 配置
排除：生成代码、测试夹具、第三方开源依赖源码
数据要求：源码不得发送到公共模型
这一步可以避免 AI 将测试代码、废弃代码或第三方库告警误认为生产问题。
步骤 2：完成可重复构建
在项目根目录执行：
./gradlew clean assembleDebug
./gradlew testDebugUnitTest
如果构建失败，应先保存错误信息并解决依赖问题。无法构建不代表无法静态扫描，但会降低对构建变体、资源合并结果和最终 Manifest 的判断可信度。
步骤 3：运行基础静态扫描
对源码执行 Semgrep：
semgrep scan --config auto --json --output semgrep-results.json .
对自定义 Android 规则，建议单独建立 rules/android.yml。下面是一条用于发现 WebView 高风险组合的示例规则：
rules:
- id: android-webview-js-interface-review
languages: [java]
severity: WARNING
message: WebView 同时启用 JavaScript 与 JavaScript 接口，需要确认页面来源和接口暴露范围
patterns:
- pattern-inside: |
$W = ...;
...
- pattern: $W.getSettings().setJavaScriptEnabled(true)
- pattern: $W.addJavascriptInterface(...)
执行：
semgrep scan --config rules/android.yml --json --output android-review.json app/src
这类规则只能提示“需要复核”，不能单独证明漏洞成立。两个调用可能位于不同分支，WebView 也可能只加载受信任的本地页面，因此必须结合数据流和运行条件判断。
步骤 4：用 MobSF 提取应用级攻击面
构建 APK 后上传到本地 MobSF：
find app/build/outputs/apk -name "*.apk"
重点查看：
• Activity、Service、Receiver、Provider 的 exported 状态；
• 自定义权限及 protectionLevel；
• Network Security Config；
• WebView 配置与明文流量策略；
• 签名、调试标志和备份配置；
• 硬编码地址、令牌特征及第三方 SDK。
不要把 MobSF 的每一项提示都直接写成漏洞。例如，组件被导出可能是 Deep Link 的业务需要，真正需要确认的是：外部输入能否触发敏感操作、是否存在身份校验、参数校验和二次确认。
步骤 5：向 AI 提供结构化证据，而不是整个仓库
将告警整理成最小必要上下文：
证据 E-01：app/src/main/AndroidManifest.xml，第 42 至 55 行，PaymentActivity 设置 exported=true，并声明自定义 Scheme。
证据 E-02：PaymentActivity.kt，第 31 至 48 行，从 Intent 读取 orderId。
证据 E-03：PaymentRepository.kt，第 72 行，提交请求前会从本地会话读取用户令牌。
未知项：服务端是否校验 orderId 与当前用户的归属关系。
可使用如下提示模板：
“你是移动应用安全审计辅助工具。只根据提供的证据分析，不补充不存在的代码。输出：已确认事实、潜在攻击前提、需要人工验证的问题、修复建议、回归测试。每个判断引用证据编号；证据不足时明确写无法确认。不要把 exported=true 自动判定为漏洞。”
这种模板能明显减少模型过度下结论的问题。涉及源码、密钥、客户数据或未发布功能时，应优先使用本地模型；如必须调用外部服务，应先完成脱敏，并确认组织的数据处理政策。
步骤 6：人工验证一个 WebView 告警
假设源码中存在以下本地实验代码：
webView.settings.javaScriptEnabled = true
webView.addJavascriptInterface(AppBridge(), "AppBridge")
webView.loadUrl(intent.getStringExtra("url") ?: "file:///android_asset/index.html")
风险不只在于启用了 JavaScript，而在于页面地址可能来自外部 Intent，同时页面能够调用原生桥接对象。如果 AppBridge 暴露敏感能力，加载不受信任页面就可能扩大攻击面。
推荐修复思路：
1. 不需要 JavaScript 时直接关闭；
2. 不需要原生桥时移除 addJavascriptInterface；
3. 页面地址使用固定本地资源，或执行严格的协议、主机和路径白名单校验；
4. 桥接接口保持最小能力，不传递令牌，不直接执行支付、文件读取等敏感操作；
5. 对敏感业务动作在原生层和服务端同时重新鉴权；
6. 使用 WebViewClient 拦截非预期跳转，但不要仅用字符串 contains 判断域名。
一个更安全的本地页面方案是：
webView.settings.javaScriptEnabled = false
webView.loadUrl("file:///android_asset/index.html")
如果业务必须加载 HTTPS 页面，应先用 URI 解析结果检查 scheme 和 host，并结合实际重定向策略测试。白名单应使用精确主机匹配，不能把 evil-example.com 误认为 example.com 的子域。
步骤 7：验证导出组件和接口授权边界
对于 exported Activity，应检查 Intent 参数是否直接控制订单、账号、文件路径或 WebView URL。对于网络接口，应确认服务端是否根据当前认证身份重新校验资源归属，不能只信任客户端传入的 userId 或 orderId。
本地验证可通过 Android 单元测试、Instrumentation 测试或调试构建完成。测试目标是证明非法输入会被拒绝，而不是尝试访问真实用户数据。示例伪测试逻辑：
• 未登录状态打开敏感 Deep Link，应跳转登录页；
• 登录用户提交不属于自己的测试订单编号，测试服务端应返回拒绝；
• Scheme、Host 或路径不在白名单时，Activity 应立即结束；
• 超长、空值和编码异常参数不应造成崩溃或绕过。
步骤 8：形成可追踪报告并回归
每个问题至少记录：规则编号、证据位置、影响条件、可信度、修复负责人和回归结果。修复后重新执行：
semgrep scan --config rules/android.yml app/src
./gradlew testDebugUnitTest
./gradlew assembleDebug
如果使用 Git 管理规则，可以让 CI 在新增高置信度问题时失败，但建议先运行一段观察期，避免误报阻断开发。AI 生成的修复代码必须经过代码评审、编译、测试和安全复核，不能直接合并。
五、可靠性控制与风险注意事项
第一，防止源码泄露。不要把完整仓库、签名文件、配置中心密钥、生产接口样本或用户数据粘贴到公共模型。即使模型服务声明不用于训练，也应按组织合规要求评估数据存储位置、保留时间和访问控制。
第二，防止提示注入。仓库中的注释、README、资源文件和扫描样本都属于不可信输入。如果文件里出现“忽略之前规则”之类文本，AI 不应执行。系统应明确规定：代码内容只作为待分析数据，不能改变审计策略。
第三，警惕误报与漏报。模式匹配工具可能忽略反射、动态加载、JNI 和复杂数据流；AI 也可能虚构调用链。高风险结论必须至少有源码证据、构建产物证据或本地可重复测试中的一种，最好两种以上相互印证。
第四，修复不能只发生在客户端。移动客户端可被逆向和修改，鉴权、资源归属、交易限制等关键控制必须由服务端执行。客户端校验主要用于降低误操作和缩小攻击面，不能替代服务端授权。
第五，保留审计记录。建议保存模型版本、提示模板哈希、输入证据编号和最终人工决策，但不要在日志中重复保存敏感源码。这样才能在模型升级后比较结果变化。
六、常见问题
问：AI 能否直接替代 Semgrep 或 MobSF？
答：不建议。传统工具输出稳定的规则编号、文件位置和可重复结果，AI 更适合解释、归并和生成验证计划。两者组合比单独使用更可靠。
问：发现硬编码字符串就一定是密钥泄露吗？
答：不是。可能是测试值、公开 API 标识、占位符或无敏感性的常量。需要确认构建变体、实际权限、是否仍有效以及服务端是否把它当作认证凭据。不要为了验证而调用真实第三方接口。
问：exported=true 是否必须改为 false？
答：不一定。Deep Link、分享入口和系统回调可能需要导出。正确做法是最小化导出组件，并对调用来源、会话状态、参数和敏感动作进行验证。
问：如何衡量 AI 审计是否有效？
答：可建立一组经过人工确认的内部样例，统计高风险问题的准确率、召回情况、人工复核耗时和无证据结论比例。不要只看模型生成了多少条告警。
问：能否让 AI 自动提交修复代码？
答：可以生成候选补丁，但不应自动进入生产分支。至少需要编译、测试、人工评审和安全回归；涉及认证、加密、证书校验和支付流程时，还应由对应领域负责人复核。
七、总结
AI 在 Android 安全审计中的可靠价值，不是凭空寻找漏洞，而是把 Semgrep、MobSF、构建产物和人工经验连接起来。一个可落地的流程应做到：只处理授权目标；以工具证据为基础；明确区分事实、推断与未知项；控制源码和数据外泄；对高风险结论进行人工验证；修复后执行可重复回归。
对于安全团队而言，最值得持续建设的不是越来越长的提示词，而是版本化的审计规则、结构化证据格式、内部验证样例和回归测试。只有当每个结论都能追溯、每个修复都能验证、每次模型输出都受权限和数据边界约束时，AI 才能真正成为安全运营与移动代码审计中的可靠工具。
