mirror of
https://github.com/openharmony/ability_ability_runtime.git
synced 2026-08-24 12:43:16 -04:00
openharmony_ci
e73561bfbb
fix: 擦除want参数 Created-by: SkyQAQ Commit-by: songkeyuan Merged-by: openharmony_ci Description: **IssueNo**: https://gitcode.com/openharmony/ability_ability_runtime/issues/16042 **Description**: fix: 擦除want参数 **稳定性自检：** | 自检项 | 自检结果 | | ------------------------------------------------------------ | -------- | | 涉及跨进程调用的相关操作需要抛至主线程或加锁防止并发 | | | 成员变量进行赋值或创建需要排查并发 | | | 谨慎在lambda表达式中使用引用捕获 | | | 谨慎在未经拷贝的情况下使用外部传入的string、C字符串 | | | map\vector\list\set等stl模板类使用时需要排查并发 | | | 谨慎考虑加锁范围 | | | 在IPC通信中谨慎使用同步通信方式 | | | 禁止传递this指针至其他模块或线程（特别是eventhandler任务） | | | 禁止将外部传入的裸指针在内部直接构造智能指针 | | | 禁止多个独立创建的智能指针管理同一地址 | | | 禁止在析构函数中抛异步任务 | | | 禁止js对象在非js线程（例如在IPC线程）创建、使用或销毁 | | | 禁止在对外接口中未经判空直接使用外部传入的指针 | | | 禁止接口返回局部变量引用 | | | 禁止在信号函数中加锁 | | | 禁止在关键流程（SA启动、应用启动等主流程）执行耗时的操作 | | | 禁止将同一个cpp编译在不同的so中 | | **安全编码自检：** | 自检项 | 自检结果 | | -------------------------------------------------------------- | -------- | | 裸指针避免通过隐式转换构造为sptr | | | json对象在取值之前必须先判断类型，避免类型不匹配 | | | 序列化时必须对传入的数组大小进行校验，避免出现超大数组 | | | 避免使用未明确位宽的整型，选择使用int8_t、uint8_t等类型 | | | 外部传入的路径要做规范化校验，对路径中的.、..、../等特殊字符严格校验 | | | 指针变量、表示资源描述符的变量、bool变量必须赋初值 | | | readParcelable获取的对象使用前需要判空 | | | 分配和释放内存的函数需要成对出现 | | | 申请内存后异常退出前需要及时进行内存释放 | | | 内存申请前必须对内存大小进行合法性校验 | | | 内存分配后必须判断是否成功 | | | 禁止使用realloc、alloca函数 | | | 禁止打印文件路径、口令等敏感信息，如有需要，使用private修饰 | | | 禁止打印内存地址 | | | 整数之间运算时必须严格检查，确保不会出现溢出、反转、除0 | | | 禁止对有符号整数进行位操作符运算 | | | 禁止对指针进行逻辑或位运算 | | | 循环次数如果收外部数据控制，需要检验其合法性 | | | 禁止使用内存操作类危险函数，需要使用安全函数 | | | 谨慎使用不可重入函数 | | | 必须检查安全函数的返回值，并进行正确处理 | | | 禁止仅通过TokenType类型判断绕过权限校验 | | **TDD Result**: **XTS Result**: ### 是否已执行L0用例 - [ ] 已验证 - [ ] 不涉及。如不涉及，请写明理由 ### AI检视评分（使用本地代码检视skills扫描）: # 代码检视报告 — commit2c6d4c2de2擦除want参数（JS 层剥离 pass-through 标志）（Round 1 / 最新提交） > 统一报告由 codecheck 工作台生成，**用于门禁管控**。检视范围：最新提交 `2c6d4c2de2`（fix: 擦除want参数）所涉 `napi_common_want.cpp::WrapWant` 对 `PARAM_SET_URI_WITH_ORIGIN_STRING` 的非系统应用剥离逻辑及对应单测。 > 遗留承接：Round 1（`bd18a71838`，报告 `codecheck_report_commit_e034d803af_20260822.md`）的 F-01（非标准 scheme 分支无测试覆盖）本轮仍未补齐，本文 F-03 承接其 F-02（token 污染）并给出本轮新证据。 --- ## 报告元数据 <!-- codecheck-report-metadata:start --> ```yaml codecheck_report: schema_version: "1.0" scope: "commit2c6d4c2de2擦除want参数" round: 1 commit_id: "2c6d4c2de2d1c96c4d08d33e23a754f6693fb829" change_id: "N/A" report_id: "2c6d4c2d-R1" date: "2026-08-23" gate_decision: "approve" risk_level: "low" score: 91 dimensions_required: ["api-scanner", "security-scanner", "logic-scanner"] dimensions_executed: ["api-scanner", "security-scanner", "logic-scanner"] findings_total: 3 findings_by_severity: {P0: 0, P1: 0, P2: 1, P3: 2} gate_blockers: [] must_fix: [] followups: ["F-01", "F-02", "F-03"] ``` <!-- codecheck-report-metadata:end --> --- ## 1. 门禁结论 | 项目 | 结论 | | ----------------- | ----------- | | 决策 | **approve** | | 风险等级 | 🟢 low | | 评分 | **91/100** | | 阻塞项 | 无 | | 必须修复（P0/P1） | 0 项 | | 建议跟进（P2/P3） | 3 项 | **一句话结论**：JS NAPI 层在 `WrapWant` 中按进程 token 剥离 pass-through 标志，是服务端 `SanitizeWantParams`（`ability_manager_stub.cpp:63-72`）之外的合理纵深防御，方向正确、无 P0/P1 缺陷；主要问题是修复**未覆盖 ANI 绑定**（`ani_common_want.cpp`）导致双绑定行为不一致，另有两处 P3（无条件深拷贝、测试 token 恢复仅在成功路径）。 --- ## 3. 必须立即处理（P0/P1） **无。** 详情见第 6 节。 --- ## 4. 建议本轮或下一补档处理（P2/P3） | ID | 优先级 | 问题 | 建议行动 | 排期 | | ---- | ------ | ------------------------------------------------------------ | ------------------------------------------------------------ | -------- | | F-01 | P2 | ANI 绑定未同步 pass-through 权限化处理：`ani_common_want.cpp::WrapWant` 对非系统应用不剥离 `PARAM_SET_URI_WITH_ORIGIN_STRING`；`ani_common_want.cpp::UnwrapWant` 对 raw uri 无透传保真。与 JS 侧（`napi_common_want.cpp:1103-1107`/`:1221-1237`）不对称 | 在 `ani_common_want.cpp` 的 WrapWant 中按 `IPCSkeleton::GetSelfTokenID` + `TokenIdKit::IsSystemAppByFullTokenID` 做同等剥离；UnwrapWant 中按 JS 版 `SetUriWithPassThroughFlag` 语义处理 uri | 本轮补档 | | F-02 | P3 | `WrapWant` 无条件深拷贝整个 `Want`（`napi_common_want.cpp:1103`），系统应用/无标志场景也拷贝；`WrapWant` 位于 `onCreate`/`onNewWant` 等热路径 | 先 `want.GetBoolParam(...)` 短路，仅当"含标志且非系统应用"时才执行拷贝 | 下一补档 | | F-03 | P3 | 新增两个测试的 token/env 恢复仅在成功路径（`napi_common_want_test.cpp:273-274`、`:311-312`）；`ASSERT` 失败即泄漏 `SetSelfTokenID(0)/fake 系统 token` 与未释放的 JsEnv 到同进程后续用例（承接 Round 1 F-02） | 用 RAII 作用域守卫或 `SetUp/TearDown` 统一恢复 token 与 `RemoveJsEnv` | 下一补档 | --- ## 5. 分维度速览 | 维度 | 结果 | 关键说明 | | ---------------- | ---------------- | ------------------------------------------------------------ | | security-scanner | ✅ 通过 | 服务端 `SanitizeWantParams`（`ability_manager_stub.cpp:63-72`）仍是权威安全边界：非系统调用者即使带标志/raw uri，也会被剥标志并重跑 `SetUri` 校验，非标准 scheme 被清空。本提交新增的 JS 层剥离为纵深防御，方向正确。无 P0/P1 | | logic-scanner | ✅ 通过 | 剥离逻辑（`napi_common_want.cpp:1103-1107`）在 wrap 输出前、且复制品上执行，不影响原 `want`；fds/parameters/entities 均改用 `wrapWant` 读取，一致性正确。主要问题为 ANI 侧未同步（F-01）与无条件拷贝（F-02） | | api-scanner | ✅ 通过（有限面） | 无对外签名/.d.ts/错误码变更；行为面变化为"第三方应用 JS 侧 `want.parameters` 不再含内部 `PARAM_SET_URI_WITH_ORIGIN_STRING`"，属预期收敛，不构成公共 API 不兼容。新增 2 条用例覆盖"非系统剥离/系统保留"两分支；建议补充"无标志基线"与"剥离后 fds/parameters 完整性"用例（并入 F-03 排期） | --- ## 6. 关键发现详情 ### [F-01] ANI 绑定未同步 pass-through 权限化处理 (P2, scanner=security-scanner + logic-scanner) - **位置**：`frameworks/ets/ani/ani_common/src/ani_common_want.cpp:1084`（WrapWant）、`:1265`（UnwrapWant） - **触发路径**：系统应用 A 向第三方应用 B 转发带 pass-through 标志 + raw uri 的 want（服务端因 A 为系统调用者不拦截，`ability_manager_stub.cpp:63-72`）→ B 为 ArkTS-static 应用时，B 的 ANI 运行时入口（如 `ets_ui_ability.cpp:586/1047/2161`、`ets_service_extension.cpp:294` 等）调用 `ani_common_want.cpp:1084 WrapWant` → 标志原样出现在 B 的 TS 侧 `want.parameters`。 - **影响**：修复目标"标志不得暴露给第三方应用"在 ArkTS-static 绑定下未完整落地（内部参数信息暴露 + 双绑定行为不一致）。因服务端 `SanitizeWantParams` 对非系统调用者仍强制拦截，无权限绕过，故定为 P2 而非 P1。反向不对称：`ani_common_want.cpp:1285` 直接 `want.SetUri(uri)`，系统静态应用无法保真转发非标准 scheme raw uri（Uri 构造函数重新校验 scheme）。 - **证据**：`napi_common_want.cpp:1103-1107`（JS 版已按 token 剥离）vs `ani_common_want.cpp:1084-1130`（ANI 版全量 wrap 无过滤）；`ani_common_want.cpp:1285`（unwrap 无 `SetUriWithPassThroughFlag` 等价处理）vs `napi_common_want.cpp:1221-1237, 1269`。 - **建议**：`ani_common_want.cpp` 的 WrapWant 做同等剥离、UnwrapWant 按 JS 版语义处理 uri；两处逻辑建议抽取公共工具避免再次漂移。 ### [F-02] WrapWant 无条件深拷贝整个 Want (P3, scanner=logic-scanner) - **位置**：`frameworks/js/napi/inner/napi_common/napi_common_want.cpp:1103` - **触发路径**：`WrapWant` 被 `js_ui_ability.cpp:553/1015/2117`、`js_ui_extension.cpp`、`js_service_extension.cpp` 等热路径调用；`Want wrapWant = want;` 在**每次**调用（含系统应用、无标志 want）都深拷贝 params map。 - **影响**：微秒级额外拷贝开销，非正确性问题；仅当 want 带标志且调用者非系统应用时才真正需要拷贝。 - **证据**：`napi_common_want.cpp:1103`（无条件拷贝）+ `:1105`（条件剥离）。 - **建议**：`if (want.GetBoolParam(Want::PARAM_SET_URI_WITH_ORIGIN_STRING, false) && !IsSystemAppByFullTokenID(GetSelfTokenID()))` 短路后再拷贝。 ### [F-03] 新增测试 token/env 恢复仅在成功路径 (P3, scanner=logic-scanner) - **位置**：`test/unittest/napi_common_want_test/napi_common_want_test.cpp:273-274`、`:311-312` - **触发路径**：两用例在用例末尾执行 `RemoveJsEnv` + `SetSelfTokenID(originalToken)`；若中间 `ASSERT_NE(jsEnv, nullptr)` 或 `ASSERT_NE(jsWant, nullptr)` 失败，恢复语句被跳过。 - **影响**：`SetSelfTokenID(0)` / fake 系统 token 与未释放的 `JsRuntimeLite` env 泄漏到同进程后续用例，造成测试间污染与 flaky（承接 Round 1 F-02）。 - **证据**：`napi_common_want_test.cpp:273-274`（非系统用例恢复）、`:311-312`（系统用例恢复）。 - **建议**：token 与 env 生命周期用 RAII/`SetUp`/`TearDown` 管理；顺带补充"无标志 want 基线 wrap"与"剥离后 fds/parameters 完整性"断言。 See merge request: openharmony/ability_ability_runtime!20283