OWASP MASTG Android ContentProvider 安全指南:URI 路由、SQL 查询构建与 SQL 注入防护

发布时间:2026/10/8 6:53:25
OWASP MASTG Android ContentProvider 安全指南:URI 路由、SQL 查询构建与 SQL 注入防护 文档教程网络安全【免费下载链接】mastgThe OWASP Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the OWASP Mobile Security Weakness Enumeration (MASWE) weaknesses, which are in alignment with the OWASP MASVS.项目地址https://gitcode.com/gh_mirrors/ow/mastg点击查看免费下载ContentProvider 是 Android 中通过 URI 接口向其他应用与系统服务暴露结构化数据的标准组件也是跨进程数据交换的核心入口之一。本文以 OWASP Mobile Application Security Testing GuideMASTG知识体系为骨架系统讲解 ContentProvider 的 URI 结构、UriMatcher 路由、SQLiteQueryBuilder 查询构建与 selection 参数化机制并基于仓库内的漏洞演示、Semgrep 检测规则与测试用例给出从原理分析到防护落地的完整实战方案。读完本文你将掌握 ContentProvider 的访问控制配置、识别两类典型 SQL 注入向量并学会用参数化查询与预编译语句修复漏洞。ContentProvider 概述与攻击面ContentProvider是 Android 四大组件之一它通过一套标准化的 URI 接口向其他应用和系统服务暴露结构化数据。Provider 支持 CRUD 操作query、insert、update、delete通常以 SQLite 数据库为存储后端但也可以是任何数据源。客户端通过ContentResolver与 Provider 交互在设备 shell 上则可以通过content命令访问。从安全角度看ContentProvider 是应用的重要 IPC 入口点。在 IPC 机制知识文章 中ContentProvider 与 Activity、Service、Broadcast Receiver 并列为四种通过AndroidManifest.xml声明、由android:exported属性控制可见性的组件入口。一旦 Provider 被导出且处理用户可控输入时缺少校验或参数化就会形成真实可利用的攻击面——尤其是 SQL 注入攻击者可借此绕过访问控制并提取敏感数据。URI 结构Content URI 遵循content://authority/path或content://authority/path/id的格式由三个部分组成Authority标识 Provider 的唯一字符串例如com.example.app.provider在 manifest 的provider android:authorities…元素中声明。Path标识资源类型或数据表例如students。ID 段附加在 Path 后的可选整数行标识例如students/3。在 MASTG-DEMO-0102 的示例中Authority 为org.owasp.mastestapp.provider路径包括students、students/#和students/filter/*分别对应数据集合、单行记录与任意过滤器三种资源形态。URI 解析 API在 Provider 实现内部Android 提供了多个 API 从 content URI 中提取组成部分Uri.getPathSegments()返回 authority 之后解码后的路径段列表。索引 0 通常是资源路径索引 1如果存在是 ID。Uri.getLastPathSegment()返回最后一个路径段。ContentUris.parseId(Uri)从 URI 路径末尾解析并返回long类型的 ID若该段不是合法整数则抛出NumberFormatException。关键的安全认知在于当 Provider 被导出android:exportedtrue时这些值完全由调用方攻击者控制。getPathSegments()的结果直接拼接进 SQL 语句正是仓库中 Semgrep 规则所检测的核心模式见后文。UriMatcher 路由UriMatcher将传入的 content URI 映射为整数常量使 Provider 可以按 URI 模式分发逻辑val uriMatcher UriMatcher(UriMatcher.NO_MATCH).apply { addURI(AUTHORITY, students, STUDENTS) addURI(AUTHORITY, students/#, STUDENT_ID) }通配符规则#匹配单个数字段numeric segment。*匹配任意字符串段any string segment。在 MastgTest.kt 的StudentProvider中三个路由分别注册为students常量 1、students/#常量 2与students/filter/*常量 3。注意students/#虽然被 UriMatcher 限定为数字段但在 Demo 的查询实现中数字 ID 同样被字符串拼接进 SQLqb.appendWhere(id id)因此仍可能被利用——这一点被 Semgrep 规则正确捕获说明数字约束不等于SQL 安全。SQLiteQueryBuilder构建查询的辅助类SQLiteQueryBuilder是ContentProvider.query()实现中构建 SELECT 语句的辅助类关键方法如下setTables(String)设置 FROM 子句。appendWhere(CharSequence)向 WHERE 子句追加条件。该字符串会被原样插入 SQL 查询不做参数化处理。appendWhereEscapeString(String)追加经过DatabaseUtils.sqlEscapeString()转义的条件。query(SQLiteDatabase, String[], String, String[], String, String, String)构建并执行查询selection参数会与appendWhere追加的子句做 AND 组合。以 Demo 中的漏洞路径为例STUDENT_FILTER分支从 URI 取出任意路径段后直接追加val filter uri.pathSegments[2] qb.appendWhere( filter)此时 URIcontent://org.owasp.mastestapp.provider/students/filter/id%3D2%20OR%201%3D1中的路径段被 URL 解码后即为id2 OR 11原样进入 SQL形成路径型注入。selection 与 selectionArgs参数化与注入的分水岭query()方法接受selection字符串和selectionArgs数组。selection中的每个?占位符会被替换为selectionArgs中对应的值且这些值严格作为数据处理不会被解释为 SQLval cursor qb.query(db, projection, selection, selectionArgs, null, null, sortOrder)因为值是绑定bound而非作为 SQL 解析所以参数化写法可以有效阻止 SQL 注入。作为对照以下两种做法会让用户输入成为 SQL 语句本身的一部分将值直接拼接进selection字符串将用户可控输入传给appendWhere。这两类做法正是 SQL 注入的常见来源。仓库在 MASTG-DEMO-0102 中提供了两个可直接复现的注入命令selection 型注入未校验的selection参数直达查询adb shell content query --uri content://org.owasp.mastestapp.provider/students --where name\Bob\ OR \1\\1\路径型注入students/filter/*路由接受任意路径输入adb shell content query --uri content://org.owasp.mastestapp.provider/students/filter/id%3D2%20OR%201%3D1注意content命令与adb shell配合时--where参数对应query()的selection参数因此它本身就是一条真实的注入通道而路径型向量则直接经由 URI 进入appendWhere。漏洞检测Semgrep 规则与逆向验证MASTG 仓库为这一漏洞提供了完整的静态检测闭环。检测规则位于 mastg-android-sql-injection-contentprovider.yml其核心模式为patterns: - pattern-either: - pattern: | $QB.appendWhere(... $VAR); - pattern: | $QB.appendWhere($VAR); - pattern-inside: | $VAR $URI.getPathSegments().get(...); ...即先定位getPathSegments().get(...)的赋值再检查该变量是否被拼接或直接传入appendWhere。Demo 通过 run.sh 对该用例的逆向版本 MastgTest_reversed.java 执行检测NO_COLORtrue semgrep -c ../../../../rules/mastg-android-sql-injection-contentprovider.yml ./MastgTest_reversed.java output.txtoutput.txt 中输出了 2 个 Code Findings命中 [MASVS-CODE-4]95┆ qb.appendWhere(id id); 99┆ qb.appendWhere(filter);第一个命中来自students/#数字路由第二个来自students/filter/*任意路径路由——后者由于接受任意路径输入是可实际利用的路径型注入。整个检测流程与测试用例 MASTG-TEST-0339映射 MASWE-0050一致先通过逆向工程分析应用再定位相关 API若发现getPathSegments()等未校验输入被直接拼接进 SQL或appendWhere()不安全使用则判定测试失败。访问控制manifest 属性与导出边界ContentProvider 对其他应用的可用性由 Android manifest 中的属性决定android:exported为true时其他应用可访问受权限约束为false时仅限同应用或共享同一 UID 的应用。自 Android 4.2 起若未定义intent-filter默认值为false。android:readPermission/android:writePermission分别将读、写操作限制为持有指定权限的调用方。android:permission对读、写操作统一施加单一权限要求。android:grantUriPermissions允许临时、URI 作用域的访问授权。签名级权限signature-level permissions将访问限制为使用同一证书签名的应用。导出且处理未校验用户输入的 Provider 是常见攻击面。在评估 Provider 安全时应首先在 AndroidManifest.xml 中确认android:exported与权限属性再结合 URI 解析逻辑判断输入可信度。防护实践参数化查询与预编译语句对应的最佳实践条目 MASTG-BEST-0039 给出了两条核心防护措施1. 使用参数化查询不要用字符串拼接构建 SQL改用selectionselectionArgs参数。修复示例val idSegment uri.getPathSegments()[1] val selection id ? val selectionArgs arrayOf(idSegment) val cursor qb.query(db, projection, selection, selectionArgs, null, null, sortOrder)此时idSegment作为绑定值传入即使内容为2 OR 11也不会改变查询结构。2. 使用预编译语句执行 insert、update、delete 时使用 SQLite 预编译语句如SQLiteStatement或支持参数绑定的SQLiteDatabase方法替代动态构造的 SQL。预编译语句确保不可信输入以参数形式绑定无法改变 SQL 结构即使输入来自 URI 或 IPC 调用也能有效防注入。小结ContentProvider 的安全边界由两层构成manifest 层的访问控制exported与权限属性决定谁可以调用实现层的查询构建方式决定输入如何进入 SQL。UriMatcher 的#/*通配符只约束 URI 形状而非数据内容appendWhere原样插入的特性与selection字符串拼接是 SQL 注入的温床而selection/selectionArgs的参数绑定与预编译语句则是标准解法。实际测试时可按照 MASTG-TEST-0339 的流程用content命令复现两类注入向量再借助 Semgrep 规则 做静态扫描最终以参数化查询完成修复验证。赞分享文档教程网络安全【免费下载链接】mastgThe OWASP Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the OWASP Mobile Security Weakness Enumeration (MASWE) weaknesses, which are in alignment with the OWASP MASVS.项目地址https://gitcode.com/gh_mirrors/ow/mastg点击查看免费下载相关推荐OWASP MASTG 最佳实践Android ContentProvider 中的 SQL 注入防护指南MASTG-BEST-0039OWASP MASTG 最佳实践Android ContentProvider 中的 SQL 注入防护指南MASTG BEST 0039 ContentP文档教程网络安全OWASP MASTG Android ContentProvider SQL 注入实战基于 MASTG-DEMO-0102 的 selection 与 URI Path 双向量检测与复现OWASP MASTG Android ContentProvider SQL 注入实战基于 MASTG DEMO 0102 的 selection 与 UR文档教程网络安全Fathom Lite查询构建器设计SQL注入防护Fathom Lite查询构建器设计SQL注入防护 背景与风险为何SQL注入防护至关重要 网站分析工具需要处理大量用户数据查询而不安全的数据库操作可能导致数据分析后端创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考