openharmony-security-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

OpenHarmony Security Review

OpenHarmony 安全审查

Overview

概述

OpenHarmony system services run with high privileges and handle untrusted inputs via IPC and network interfaces. This skill provides a structured approach to identifying critical security vulnerabilities in four key areas: external input handling, multithreading race conditions, sensitive information leakage, and permission validation.
OpenHarmony系统服务以高权限运行,并通过IPC和网络接口处理不可信输入。本技能提供了结构化的方法,用于识别四大关键领域的严重安全漏洞:外部输入处理、多线程竞争条件、敏感信息泄露以及权限验证。

When to Use

适用场景

dot
digraph when_to_use {
    "Reviewing OpenHarmony code?" [shape=diamond];
    "Is it C++ system service?" [shape=diamond];
    "Handles IPC/network data?" [shape=diamond];
    "Has shared state?" [shape=diamond];
    "Logs data?" [shape=diamond];
    "Use this skill" [shape=box];
    "Different skill needed" [shape=box];

    "Reviewing OpenHarmony code?" -> "Different skill needed" [label="no"];
    "Reviewing OpenHarmony code?" -> "Is it C++ system service?" [label="yes"];
    "Is it C++ system service?" -> "Different skill needed" [label="no"];
    "Is it C++ system service?" -> "Handles IPC/network data?" [label="yes"];
    "Handles IPC/network data?" -> "Use this skill" [label="yes"];
    "Handles IPC/network data?" -> "Has shared state?" [label="no"];
    "Has shared state?" -> "Use this skill" [label="yes"];
    "Has shared state?" -> "Logs data?" [label="no"];
    "Logs data?" -> "Use this skill" [label="yes"];
    "Logs data?" -> "Different skill needed" [label="no"];
}
Use this skill when:
  • Reviewing OpenHarmony C++ system service code (xxxService, xxxStub implementations)
  • Code handles IPC (MessageParcel) or network data (JSON/XML/Protobuf)
  • Code has multithreaded access to shared state
  • Code performs logging of user data or pointers
  • Code validates permissions or accesses protected resources
Do NOT use for:
  • Application-layer code (use standard secure coding practices instead)
  • Non-OpenHarmony C++ code (use general security review skills)
  • Performance optimization (use different skill)
dot
digraph when_to_use {
    "Reviewing OpenHarmony code?" [shape=diamond];
    "Is it C++ system service?" [shape=diamond];
    "Handles IPC/network data?" [shape=diamond];
    "Has shared state?" [shape=diamond];
    "Logs data?" [shape=diamond];
    "Use this skill" [shape=box];
    "Different skill needed" [shape=box];

    "Reviewing OpenHarmony code?" -> "Different skill needed" [label="no"];
    "Reviewing OpenHarmony code?" -> "Is it C++ system service?" [label="yes"];
    "Is it C++ system service?" -> "Different skill needed" [label="no"];
    "Is it C++ system service?" -> "Handles IPC/network data?" [label="yes"];
    "Handles IPC/network data?" -> "Use this skill" [label="yes"];
    "Handles IPC/network data?" -> "Has shared state?" [label="no"];
    "Has shared state?" -> "Use this skill" [label="yes"];
    "Has shared state?" -> "Logs data?" [label="no"];
    "Logs data?" -> "Use this skill" [label="yes"];
    "Logs data?" -> "Different skill needed" [label="no"];
}
适用本技能的场景:
  • 审查OpenHarmony C++系统服务代码(xxxService、xxxStub实现)
  • 代码处理IPC(MessageParcel)或网络数据(JSON/XML/Protobuf)
  • 代码存在多线程访问共享状态的情况
  • 代码记录用户数据或指针日志
  • 代码验证权限或访问受保护资源
不适用本技能的场景:
  • 应用层代码(请使用标准安全编码规范)
  • 非OpenHarmony的C++代码(请使用通用安全审查技能)
  • 性能优化(请使用其他技能)

Code Traversal Strategy

代码遍历策略

Header file input (.h/.hpp): Analyze corresponding xxxService.cpp and xxxStub.cpp Stub file input (xxxStub.cpp): Extend analysis to xxxService.cpp (core logic + shared state) External calls: Flag cross-component concurrency risks for separate review
头文件输入(.h/.hpp): 分析对应的xxxService.cpp和xxxStub.cpp Stub文件输入(xxxStub.cpp): 将分析范围扩展至xxxService.cpp(核心逻辑+共享状态) 外部调用: 标记跨组件并发风险,以便单独审查

Quick Reference: Critical Vulnerability Checklist

快速参考:严重漏洞检查表

CategoryCritical ChecksSeverity
IPC DeserializationAll MessageParcel reads checked for successHIGH
Logical ValidationArray lengths/indices validated AFTER deserializationHIGH
Integer BoundsSize variables:
0 <= size <= MAX_ALLOWED_BUFFER
HIGH
Object LifecycleRemoteObjects/fd validated before use (nullptr check)HIGH
Parser SecurityNetwork parsers reject malformed input, prevent recursion attacksHIGH
Container Thread SafetyAll container operations protected (read/write, write/write)HIGH
Iterator Invalidation**No modification while iteratingHIGH
Lock ConsistencyAll shared state access protected by mutexHIGH
Deadlock RiskNested locks acquired in consistent orderHIGH
TOCTOUState checks immediately followed by dependent actionHIGH
PII in LogsNo phone numbers, contacts, SMS, biometrics in logsHIGH
Input Events in Logs**No raw KeyEvents, touch coordinates, screen boundsHIGH
Pointer AddressesNo
%p
or
&variable
in logs (ASLR bypass)
HIGH
Permission CheckAll privileged operations validate caller permissionsHIGH
类别关键检查项严重程度
IPC反序列化所有MessageParcel读取操作均检查是否成功
逻辑验证数组长度/索引在反序列化后验证
整数边界大小变量满足
0 <= size <= MAX_ALLOWED_BUFFER
对象生命周期RemoteObjects/fd在使用前验证(空指针检查)
解析器安全网络解析器拒绝畸形输入,防止递归攻击
容器线程安全所有容器操作均受保护(读/写、写/写)
迭代器失效迭代时不修改容器
锁一致性所有共享状态访问均受互斥锁保护
死锁风险嵌套锁按一致顺序获取
TOCTOU状态检查后立即执行依赖操作,无间隙
日志中的个人可识别信息(PII)日志中无电话号码、联系人、短信、生物特征数据
日志中的输入事件日志中无原始KeyEvents、触摸坐标、屏幕边界
指针地址日志中无
%p
&variable
(避免ASLR绕过)
权限检查所有特权操作均验证调用者权限

1. External Input Handling (IPC & Network)

1. 外部输入处理(IPC与网络)

1.1 IPC Deserialization Integrity

1.1 IPC反序列化完整性

Rule: Every MessageParcel read operation must check return value.
Anti-pattern:
cpp
// ❌ VULNERABLE: No validation
parcel.ReadInt32(val);
int32_t size = parcel.ReadInt32();
Required pattern:
cpp
// ✅ SECURE: Always check return value
if (!parcel.ReadInt32(val)) {
    HILOG_ERROR("Failed to read value");
    return ERR_INVALID_DATA;
}
if (!parcel.ReadInt32(size)) {
    HILOG_ERROR("Failed to read size");
    return ERR_INVALID_DATA;
}
Verification: Confirm read data size matches expected type size. Stop processing immediately on read failure.
规则: 每个MessageParcel读取操作必须检查返回值。
反模式:
cpp
// ❌ 存在漏洞:未验证
parcel.ReadInt32(val);
int32_t size = parcel.ReadInt32();
规范写法:
cpp
// ✅ 安全:始终检查返回值
if (!parcel.ReadInt32(val)) {
    HILOG_ERROR("Failed to read value");
    return ERR_INVALID_DATA;
}
if (!parcel.ReadInt32(size)) {
    HILOG_ERROR("Failed to read size");
    return ERR_INVALID_DATA;
}
验证要点: 确认读取的数据大小与预期类型大小匹配。读取失败时立即停止处理。

1.2 Post-Deserialization Logical Validation

1.2 反序列化后逻辑验证

Rule: After deserializing, validate values are within logical bounds BEFORE use.
Attack vector: Attacker sends
size = 0xFFFFFFFF
to cause memory exhaustion or integer overflow in
new char[size]
.
Anti-pattern:
cpp
// ❌ VULNERABLE: No bounds validation
int32_t size = parcel.ReadInt32();
std::vector<char> buffer(size);  // May allocate gigabytes or overflow
Required pattern:
cpp
// ✅ SECURE: Validate bounds immediately
int32_t size = 0;
if (!parcel.ReadInt32(size)) {
    return ERR_INVALID_DATA;
}
constexpr int32_t MAX_ALLOWED_BUFFER = 1024 * 1024;  // 1MB
if (size < 0 || size > MAX_ALLOWED_BUFFER) {
    HILOG_ERROR("Invalid size: %{public}d", size);
    return ERR_INVALID_DATA;
}
std::vector<char> buffer(size);
Validation targets: Array lengths, indices, loop counters, buffer sizes
规则: 反序列化后,必须在使用前验证值是否在逻辑边界内。
攻击向量: 攻击者发送
size = 0xFFFFFFFF
导致内存耗尽或整数溢出,例如在
new char[size]
中。
反模式:
cpp
// ❌ 存在漏洞:未验证边界
int32_t size = parcel.ReadInt32();
std::vector<char> buffer(size);  // 可能分配千兆字节内存或溢出
规范写法:
cpp
// ✅ 安全:立即验证边界
int32_t size = 0;
if (!parcel.ReadInt32(size)) {
    return ERR_INVALID_DATA;
}
constexpr int32_t MAX_ALLOWED_BUFFER = 1024 * 1024;  // 1MB
if (size < 0 || size > MAX_ALLOWED_BUFFER) {
    HILOG_ERROR("Invalid size: %{public}d", size);
    return ERR_INVALID_DATA;
}
std::vector<char> buffer(size);
验证目标: 数组长度、索引、循环计数器、缓冲区大小

1.3 Object Lifecycle & Ownership

1.3 对象生命周期与所有权

Rule: Validate RemoteObjects and file descriptors before use.
Required pattern:
cpp
// ✅ SECURE: Validate before use
if (remoteObject == nullptr) {
    HILOG_ERROR("Received null RemoteObject");
    return ERR_NULL_OBJECT;
}
if (fd < 0) {
    HILOG_ERROR("Invalid file descriptor");
    return ERR_INVALID_FD;
}
规则: RemoteObjects和文件描述符在使用前必须验证。
规范写法:
cpp
// ✅ 安全:使用前验证
if (remoteObject == nullptr) {
    HILOG_ERROR("Received null RemoteObject");
    return ERR_NULL_OBJECT;
}
if (fd < 0) {
    HILOG_ERROR("Invalid file descriptor");
    return ERR_INVALID_FD;
}

1.4 External Network Data

1.4 外部网络数据

Rule: Network parsers must reject malformed input and prevent recursion attacks.
Checks:
  • JSON parsers configured to reject malformed input
  • Protection against "Zip Bomb" attacks
  • Limits on deeply nested recursion
规则: 网络解析器必须拒绝畸形输入并防止递归攻击。
检查项:
  • JSON解析器配置为拒绝畸形输入
  • 防范“压缩炸弹”攻击
  • 限制深层嵌套递归

2. Multithreading & Concurrency

2. 多线程与并发

2.1 Container Thread Safety (Highest Priority)

2.1 容器线程安全(最高优先级)

Rule: All concurrent container operations must be protected by locks.
Critical risks:
  • Read/Write: One thread reads while another writes
  • Write/Write: Multiple threads modify simultaneously
  • Iterator invalidation: One thread modifies while another iterates
Anti-pattern:
cpp
// ❌ VULNERABLE: Unprotected concurrent access
std::vector<int> items_;

void AddItem(int item) {
    items_.push_back(item);  // Unsafe if called concurrently
}

void ProcessItems() {
    for (auto& item : items_) {  // Iteration
        // If AddItem called here, iterator invalidates → CRASH
    }
}
Required pattern:
cpp
// ✅ SECURE: All access protected
std::vector<int> items_;
std::mutex itemsMutex_;

void AddItem(int item) {
    std::lock_guard<std::mutex> lock(itemsMutex_);
    items_.push_back(item);
}

void ProcessItems() {
    std::lock_guard<std::mutex> lock(itemsMutex_);
    for (auto& item : items_) {
        // Safe - lock held during iteration
    }
}
Container types to scrutinize:
std::vector
,
std::map
,
std::list
,
std::unordered_map
,
std::string
Scrutinize operations:
push_back
,
insert
,
erase
,
operator[]
,
at
, iteration
规则: 所有并发容器操作必须受锁保护。
严重风险:
  • 读/写: 一个线程读取时另一个线程写入
  • 写/写: 多个线程同时修改
  • 迭代器失效: 一个线程修改时另一个线程迭代
反模式:
cpp
// ❌ 存在漏洞:无保护的并发访问
std::vector<int> items_;

void AddItem(int item) {
    items_.push_back(item);  // 并发调用时不安全
}

void ProcessItems() {
    for (auto& item : items_) {  // 迭代
        // 如果在此处调用AddItem,迭代器会失效 → 崩溃
    }
}
规范写法:
cpp
// ✅ 安全:所有访问均受保护
std::vector<int> items_;
std::mutex itemsMutex_;

void AddItem(int item) {
    std::lock_guard<std::mutex> lock(itemsMutex_);
    items_.push_back(item);
}

void ProcessItems() {
    std::lock_guard<std::mutex> lock(itemsMutex_);
    for (auto& item : items_) {
        // 安全 - 迭代期间持有锁
    }
}
需重点检查的容器类型:
std::vector
,
std::map
,
std::list
,
std::unordered_map
,
std::string
需重点检查的操作:
push_back
,
insert
,
erase
,
operator[]
,
at
, 迭代

2.2 Locking Mechanisms

2.2 锁机制

Rule: All shared resources must be consistently protected.
Shared resources requiring protection:
  • Global/static variables
  • Class member variables
  • Heap-allocated objects shared between threads
Lock types:
std::mutex
,
std::shared_mutex
,
SpinLock
Anti-pattern:
cpp
// ❌ VULNERABLE: Inconsistent protection
class Service {
    std::map<int, Data> dataMap_;
    std::mutex mutex_;

    void Update(int key, const Data& data) {
        std::lock_guard<std::mutex> lock(mutex_);
        dataMap_[key] = data;
    }

    Data Lookup(int key) {
        // ❌ NO LOCK - race condition with Update
        return dataMap_[key];
    }
};
Required pattern:
cpp
// ✅ SECURE: Consistent protection
class Service {
    std::map<int, Data> dataMap_;
    std::mutex mutex_;

    void Update(int key, const Data& data) {
        std::lock_guard<std::mutex> lock(mutex_);
        dataMap_[key] = data;
    }

    Data Lookup(int key) {
        std::lock_guard<std::mutex> lock(mutex_);
        return dataMap_[key];
    }
};
规则: 所有共享资源必须持续受保护。
需要保护的共享资源:
  • 全局/静态变量
  • 类成员变量
  • 线程间共享的堆分配对象
锁类型:
std::mutex
,
std::shared_mutex
,
SpinLock
反模式:
cpp
// ❌ 存在漏洞:保护不一致
class Service {
    std::map<int, Data> dataMap_;
    std::mutex mutex_;

    void Update(int key, const Data& data) {
        std::lock_guard<std::mutex> lock(mutex_);
        dataMap_[key] = data;
    }

    Data Lookup(int key) {
        // ❌ 无锁 - 与Update存在竞争条件
        return dataMap_[key];
    }
};
规范写法:
cpp
// ✅ 安全:持续一致的保护
class Service {
    std::map<int, Data> dataMap_;
    std::mutex mutex_;

    void Update(int key, const Data& data) {
        std::lock_guard<std::mutex> lock(mutex_);
        dataMap_[key] = data;
    }

    Data Lookup(int key) {
        std::lock_guard<std::mutex> lock(mutex_);
        return dataMap_[key];
    }
};

2.3 Deadlock Prevention

2.3 死锁预防

Rule: Assess deadlock risk in nested lock scenarios.
Deadlock conditions:
  • Multiple locks acquired in different orders by different code paths
  • Lock held while calling external function that might acquire locks
Anti-pattern:
cpp
// ❌ VULNERABLE: Deadlock risk
void Path1() {
    std::lock_guard<std::mutex> lock1(mutex1_);
    std::lock_guard<std::mutex> lock2(mutex2_);  // Order: 1 then 2
}

void Path2() {
    std::lock_guard<std::mutex> lock2(mutex2_);
    std::lock_guard<std::mutex> lock1(mutex1_);  // Order: 2 then 1 → DEADLOCK
}
Required pattern:
cpp
// ✅ SECURE: Consistent lock order
void Path1() {
    std::lock_guard<std::mutex> lock1(mutex1_);
    std::lock_guard<std::mutex> lock2(mutex2_);  // Order: 1 then 2
}

void Path2() {
    std::lock_guard<std::mutex> lock1(mutex1_);  // Same order: 1 then 2
    std::lock_guard<std::mutex> lock2(mutex2_);
}
规则: 评估嵌套锁场景下的死锁风险。
死锁条件:
  • 不同代码路径以不同顺序获取多个锁
  • 持有锁时调用可能获取锁的外部函数
反模式:
cpp
// ❌ 存在漏洞:死锁风险
void Path1() {
    std::lock_guard<std::mutex> lock1(mutex1_);
    std::lock_guard<std::mutex> lock2(mutex2_);  // 顺序:1然后2
}

void Path2() {
    std::lock_guard<std::mutex> lock2(mutex2_);
    std::lock_guard<std::mutex> lock1(mutex1_);  // 顺序:2然后1 → 死锁
}
规范写法:
cpp
// ✅ 安全:一致的锁顺序
void Path1() {
    std::lock_guard<std::mutex> lock1(mutex1_);
    std::lock_guard<std::mutex> lock2(mutex2_);  // 顺序:1然后2
}

void Path2() {
    std::lock_guard<std::mutex> lock1(mutex1_);  // 相同顺序:1然后2
    std::lock_guard<std::mutex> lock2(mutex2_);
}

2.4 TOCTOU (Time-of-Check to Time-of-Use)

2.4 TOCTOU(检查时间到使用时间)

Rule: State checks must be immediately followed by dependent action without gaps.
Anti-pattern:
cpp
// ❌ VULNERABLE: TOCTOU window
if (fileExists(path)) {
    // Attacker can delete/replace file here
    file = openFile(path);  // May open different file
}
Required pattern:
cpp
// ✅ SECURE: Atomic check-and-use
file = openFile(path);
if (file.isValid()) {
    // Use file
}
规则: 状态检查后必须立即执行依赖操作,无时间间隙。
反模式:
cpp
// ❌ 存在漏洞:TOCTOU窗口
if (fileExists(path)) {
    // 攻击者可在此处删除/替换文件
    file = openFile(path);  // 可能打开不同的文件
}
规范写法:
cpp
// ✅ 安全:原子性检查与使用
file = openFile(path);
if (file.isValid()) {
    // 使用文件
}

3. Sensitive Information Protection

3. 敏感信息保护

3.1 Strict PII Redaction

3.1 严格的个人可识别信息(PII)脱敏

Rule: Logging must redact all Personally Identifiable Information (PII).
PII requiring redaction:
  • User privacy: Phone numbers, contacts, SMS content, biometric data
  • Input events: Raw KeyEvents, touch coordinates (x, y), screen position bounds (Rect)
Anti-pattern:
cpp
// ❌ VULNERABLE: Logs PII
HILOG_INFO("Phone: %{public}s", phoneNumber.c_str());
HILOG_ERROR("Touch at (%{public}d, %{public}d)", x, y);
Required pattern:
cpp
// ✅ SECURE: Redact or suppress
HILOG_INFO("Phone: %{private}s", phoneNumber.c_str());  // Redacted
// Better: Don't log PII at all
HILOG_INFO("Processing phone number");
Policy: Prefer complete suppression in release builds. Use
%{private}
format specifier only when absolutely necessary for debugging.
规则: 日志必须脱敏所有个人可识别信息(PII)。
需要脱敏的PII:
  • 用户隐私: 电话号码、联系人、短信内容、生物特征数据
  • 输入事件: 原始KeyEvents、触摸坐标(x, y)、屏幕位置边界(Rect)
反模式:
cpp
// ❌ 存在漏洞:日志包含PII
HILOG_INFO("Phone: %{public}s", phoneNumber.c_str());
HILOG_ERROR("Touch at (%{public}d, %{public}d)", x, y);
规范写法:
cpp
// ✅ 安全:脱敏或不记录
HILOG_INFO("Phone: %{private}s", phoneNumber.c_str());  // 已脱敏
// 更佳方案:完全不记录PII
HILOG_INFO("Processing phone number");
策略: 发布版本中优先选择完全不记录。仅在调试绝对必要时使用
%{private}
格式说明符。

3.2 Memory Layout Leakage (ASLR Bypass)

3.2 内存布局泄露(ASLR绕过)

Rule: Never log raw pointer addresses.
Anti-pattern:
cpp
// ❌ VULNERABLE: Leaks addresses for ASLR bypass
HILOG_INFO("Object at %p", &object);
HILOG_DEBUG("Buffer address: %{public}p", buffer);
Required pattern:
cpp
// ✅ SECURE: No address logging
HILOG_INFO("Object created");
// Use opaque IDs instead of pointers
HILOG_INFO("Object ID: %{public}d", object.id_);
Rationale: Leaking heap/stack addresses helps attackers bypass ASLR (Address Space Layout Randomization).
规则: 绝不要记录原始指针地址。
反模式:
cpp
// ❌ 存在漏洞:泄露地址以绕过ASLR
HILOG_INFO("Object at %p", &object);
HILOG_DEBUG("Buffer address: %{public}p", buffer);
规范写法:
cpp
// ✅ 安全:不记录地址
HILOG_INFO("Object created");
// 使用不透明ID替代指针
HILOG_INFO("Object ID: %{public}d", object.id_);
原理: 泄露堆/栈地址会帮助攻击者绕过ASLR(地址空间布局随机化)。

4. Permission Validation

4. 权限验证

Rule: All privileged operations must validate caller permissions.
Anti-pattern:
cpp
// ❌ VULNERABLE: No permission check
int32_t Service::DeleteFile(const std::string& path) {
    // Any caller can delete any file!
    return unlink(path.c_str());
}
Required pattern:
cpp
// ✅ SECURE: Validate permissions
int32_t Service::DeleteFile(const std::string& path) {
    // Verify caller has permission to access this path
    if (!HasPermission(callerToken_, path, Permission::DELETE)) {
        HILOG_ERROR("Permission denied for path: %{private}s", path.c_str());
        return ERR_PERMISSION_DENIED;
    }

    // Verify path is within allowed sandbox
    if (!IsPathInSandbox(path)) {
        HILOG_ERROR("Path outside sandbox: %{private}s", path.c_str());
        return ERR_INVALID_PATH;
    }

    return unlink(path.c_str());
}
Permission checks required for:
  • File system operations (read, write, delete)
  • System settings modifications
  • Hardware access (camera, microphone, location)
  • Inter-process communication
  • Network operations
规则: 所有特权操作必须验证调用者权限。
反模式:
cpp
// ❌ 存在漏洞:无权限检查
int32_t Service::DeleteFile(const std::string& path) {
    // 任何调用者都可以删除任意文件!
    return unlink(path.c_str());
}
规范写法:
cpp
// ✅ 安全:验证权限
int32_t Service::DeleteFile(const std::string& path) {
    // 验证调用者是否有权限访问该路径
    if (!HasPermission(callerToken_, path, Permission::DELETE)) {
        HILOG_ERROR("Permission denied for path: %{private}s", path.c_str());
        return ERR_PERMISSION_DENIED;
    }

    // 验证路径是否在允许的沙箱内
    if (!IsPathInSandbox(path)) {
        HILOG_ERROR("Path outside sandbox: %{private}s", path.c_str());
        return ERR_INVALID_PATH;
    }

    return unlink(path.c_str());
}
需要权限检查的操作:
  • 文件系统操作(读、写、删除)
  • 系统设置修改
  • 硬件访问(摄像头、麦克风、位置)
  • 进程间通信
  • 网络操作

Common Mistakes

常见错误

MistakeConsequenceFix
Forgetting to check MessageParcel return valuesUninitialized data use, crashesAlways check return value
Validating size but not lower bound (negative)Negative sizes pass validationCheck
0 <= size <= MAX
Protecting write but not read on shared containerRace condition during readsProtect ALL access
Using iterator after container modificationIterator invalidation, crashesHold lock during iteration
Logging with
%{public}
for PII
Information leakageUse
%{private}
or don't log
Printing pointer addresses for debuggingASLR bypassUse opaque IDs
Skipping permission check "because it's internal"Privilege escalation if called externallyAlways validate
错误后果修复方案
忘记检查MessageParcel返回值使用未初始化数据、崩溃始终检查返回值
验证大小但未验证下限(负数)负数大小通过验证检查
0 <= size <= MAX
保护写入但未保护读取共享容器读取时出现竞争条件保护所有访问操作
容器修改后使用迭代器迭代器失效、崩溃迭代期间持有锁
对PII使用
%{public}
记录日志
信息泄露使用
%{private}
或不记录
调试时打印指针地址ASLR被绕过使用不透明ID
跳过权限检查“因为是内部调用”若被外部调用则会导致权限提升始终验证权限

Review Output Format

审查输出格式

Flag violations with this format:
**[HIGH SECURITY RISK] <Category>**

Location: <file_path>:<line_number>

Issue: <description>

Anti-pattern:
```cpp
<code>
Required fix:
cpp
<code>
Impact: <attacker capability if exploited>
undefined
使用以下格式标记违规:
**[高安全风险] <类别>**

位置:<文件路径>:<行号>

问题描述:<说明>

反模式:
```cpp
<code>
修复方案:
cpp
<code>
影响:<被利用后攻击者可执行的操作>
undefined

Real-World Impact

实际影响

Container race conditions: Use-after-free crashes, privilege escalation through corrupted state IPC validation failures: Remote code execution via deserialization exploits, memory exhaustion DoS PII leakage: Privacy violations, GDPR compliance failures ASLR bypass: Enables exploitation of memory corruption vulnerabilities Missing permission checks: Unauthorized access to sensitive data, system modification
容器竞争条件: 释放后使用崩溃、通过损坏状态提升权限 IPC验证失败: 通过反序列化漏洞执行远程代码、内存耗尽拒绝服务 PII泄露: 隐私侵犯、GDPR合规性失败 ASLR绕过: 启用内存损坏漏洞的利用 缺失权限检查: 未经授权访问敏感数据、修改系统