移动应用中的代码注入 — 定义、攻击类型与防护

什么是代码注入？

代码注入——一种攻击类别，攻击者通过不可信的输入数据将可执行代码注入应用程序。在移动应用中，攻击可能通过输入字段、深层链接、推送通知、二维码和文件交换进行。

与操作系统级别的攻击不同，代码注入利用应用程序自身代码中的逻辑错误：缺乏转义、不安全的字符串拼接或对外部数据源的信任。根据Positive Technologies（2025）的报告，注入攻击占金融行业移动应用中所有漏洞的23%。

代码注入的主要风险——数据完全泄露：攻击者可以访问数据库、设备文件系统或其他用户的账户。对于处理支付数据或医疗信息的移动应用程序，后果可能非常严重。

开发人员必须了解注入类型，并在所有层面——从数据输入到显示和存储——应用防护机制。现代框架提供了内置的防护工具，但使用它们需要有意识的方法。

移动应用中代码注入的主要类型

代码注入的分类在移动开发背景下包括三种主要攻击类型。每种类型利用应用程序的不同组件，需要特定的防护方法。

移动应用中的SQL注入

SQL注入（SQLi）——通过查询参数将恶意SQL代码注入本地或远程数据库。在移动应用中，漏洞出现在设备上不安全的SQLite操作或通过字符串拼接构建REST API的HTTP请求时。

典型的攻击向量——搜索或筛选字段，其值直接插入SQL查询。如果开发人员使用原始拼接而不是参数化查询，攻击者可以发送像1' OR '1'='1这样的字符串。根据OWASP移动Top 10（2024），SQL注入仍然是不安全数据存储类别中移动应用中第二常见的严重漏洞。

针对SQL注入的防护基于三个层面：使用参数化查询（Java中的PreparedStatement，Android中带bindArgs的rawQuery），客户端和服务器端的输入数据验证，以及最小数据库权限。

WebView中的跨站脚本攻击（XSS）

移动应用中的XSS攻击针对WebView组件——显示HTML内容的内置浏览器。如果应用程序在没有清理的情况下将外部来源的数据加载到WebView，攻击者可以注入JavaScript代码，该代码将在应用程序上下文中执行。

XSS分为两种子类型：存储型XSS——恶意脚本存储在服务器上，每次页面查看时执行；反射型XSS——代码通过URL或POST参数传递并一次性执行。在移动应用中，通过评论、评论或用户内容在WebView中向其他用户显示的存储型XSS尤其危险。

防护包括在不需要时禁用WebView中的JavaScript，使用内容安全策略（CSP），以及通过诸如Android的Jsoup或iOS的SwiftSoup等库进行HTML内容清理。

通过Intent和Shell的命令注入

命令注入——通过未受保护的Runtime.exec()、ProcessBuilder或NSTask调用在设备上执行系统命令。在移动应用中，如果应用程序将用户数据传递给shell命令或带操作的Intent，攻击是可能的。

最脆弱的地方是文件转换、媒体处理（ffmpeg、ImageMagick）和外部库安装功能。攻击者可以发送带有管道或重定向符号的命令，在设备上执行任意代码。Android通过沙箱部分限制shell访问，但具有root权限或提权漏洞的应用程序可能被入侵。

推荐的防护——完全放弃使用Runtime.exec()处理用户数据，使用具有安全API的库，以及严格隔离外部进程。

代码注入在Android和iOS上如何工作

代码注入的机制在Android和iOS平台上因架构差异而不同。在Android上，注入通常与Intent相关——在应用程序组件之间传递的系统消息。攻击者可以发送带有包含SQL代码或shell命令的额外数据的恶意Intent。

在iOS上，攻击更常通过进程间通信（XPC）、通用链接和URL方案处理机制发生。接收来自外部来源的数据而不加检查的应用程序容易受到注入攻击。根据Apple安全研究（2025），iOS应用中约12%的漏洞与输入数据清理不足有关。

两个平台的共同向量——通过本地存储（SQLite、Realm、UserDefaults）进行攻击。如果恶意应用程序可以写入共享目录，它可以注入在目标应用程序读取时执行的代码。

典型攻击过程包括三个阶段：侦察——分析应用程序的入口点（表单、深层链接、文件）；注入——通过找到的入口点发送恶意载荷；利用——执行注入以获取数据或功能访问权限。理解这个周期有助于开发人员在每个阶段设计防护。

代码示例：脆弱和安全的实现

让我们来看一下Android的Kotlin和iOS的Swift中代码注入的具体示例。每个示例展示一个脆弱模式及其安全替代方案。

SQL注入：Kotlin中的脆弱代码

第一个示例——查询字符串与用户输入的直接拼接。当userInput = "1' OR '1'='1"时，查询将返回表的所有行而不是一行。

// 脆弱：字符串拼接
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

// 安全：参数化查询
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

WebView中的XSS防护：iOS的Swift

第二个示例演示了在WKWebView中错误和正确地加载用户HTML内容。使用SwiftSoup可以在显示之前删除恶意脚本。

// 脆弱：直接加载HTML
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// 安全：通过SwiftSoup进行清理
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

命令注入：Kotlin中针对shell攻击的防护

第三个示例——使用用户参数调用Runtime.exec()的风险以及通过固定API库的安全替代方案。

// 脆弱：带用户输入的shell命令
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// 安全：参数隔离
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

保护移动应用免受注入攻击的方法

针对代码注入的防护需要系统化的方法，涵盖代码、基础设施和开发流程。没有单一方法能保证完全安全——需要组合各种实践。

第一层——预防：严格验证所有输入数据。应用程序从用户、其他应用或网络接收的每个字段都应检查类型、长度和格式。像OWASP ESAPI这样的库为常见场景提供了现成的验证器。

第二层——清理和转义：在数据用于SQL查询、HTML模板或shell命令之前进行转换。参数化查询完全消除SQL注入，HTML转义防止XSS。在Android上，使用Room——一种自动应用绑定参数的ORM——来处理SQLite。

第三层——最小化权限：应用程序应以最小必要权限运行。对数据库、文件系统和进程间通信采用最小权限原则。iOS通过应用沙箱实现此原则，Android通过权限模型和进程隔离实现。

第四层——监控和响应：记录可疑操作、检测异常并在重复攻击时自动阻止。像Firebase App Check这样的工具有助于检测来自被入侵客户端的虚假后端请求。集成RASP（运行时应用程序自我保护）可以在运行时阻止注入。

根据Google Project Zero（2025）的研究，这四个层面的组合将代码注入成功攻击的风险降低了94%。建议开发人员在架构设计阶段实施防护机制，而不是在发现漏洞之后。