安全漏洞修复与预防实战

—— 别等“被通报”了，才想起安全这回事

我是 Echo_Wish。
写鸿蒙、做系统、搞应用这些年，我越来越深刻地体会到一句话：

安全问题，永远不是“会不会发生”，而是“什么时候发生、发生在谁身上”。

而最讽刺的是——
很多漏洞，开发阶段就已经埋好了，只是没人点破。

今天这篇文章，我就按你给的结构来，聊聊：

鸿蒙应用中，安全漏洞到底该怎么修、又该怎么提前防。

不高大上，但全是实战味。

一、引子：安全漏洞，往往不是“黑客写的”，而是“我们写的”

先说一个你可能很熟的场景：

• 功能联调 OK
• UI 验收 OK
• 性能测试 OK
• 上线一周后，被安全团队点名

理由很简单：

“应用存在权限滥用 / 数据泄露 / 组件暴露风险。”

然后你回头一看代码：

“这不是我照着官方 Demo 写的吗？”

兄弟，Demo 是教你怎么跑，不是教你怎么抗攻击的。

在鸿蒙（HarmonyOS）里：

• 分布式能力很强
• 系统权限粒度很细
• 组件通信很灵活

但一旦用错，漏洞也来得更快。

二、原理讲解：鸿蒙安全，核心就三件事（通俗版）

我们别一上来就讲“安全模型”，我用一句人话总结鸿蒙应用安全的底层逻辑：

权限要最小、数据要隔离、入口要可控。

拆开来看。

1️⃣ 权限不是“能用就行”，而是“用多少给多少”

很多新手最容易犯的错是：

"reqPermissions": [
  {
    "name": "ohos.permission.READ_MEDIA"
  },
  {
    "name": "ohos.permission.WRITE_MEDIA"
  }
]

理由往往是：

“以后可能会用到。”

但在安全世界里：

“以后可能” = “现在就危险”。

鸿蒙的权限体系本身就很细，
滥用权限，直接等于扩大攻击面。

2️⃣ 组件暴露 = 给别人留后门

鸿蒙的 Ability 非常强，但也非常“直”。

"abilities": [
  {
    "name": "MainAbility",
    "exported": true
  }
]

很多漏洞就出在这一句 exported: true。

这意味着什么？

任何三方应用，只要知道你的 Ability 名字，就可能拉起它。

3️⃣ 数据不是“存在本地就安全”

不少开发者有个误区：

“我没上云，数据在本地，应该没事吧？”

但现实是：

• 日志
• 明文配置
• 未加密缓存

照样能被逆向拿走。

三、实战代码：几个最常见漏洞的修与防

下面我挑几个真实项目里最容易翻车的点，直接上代码。

🧨 漏洞一：Ability 被任意拉起（组件暴露）

❌ 问题写法

{
  "name": "PayAbility",
  "exported": true
}

只要被拉起，就可能执行支付逻辑。

✅ 修复方式：不暴露 + 校验调用方

{
  "name": "PayAbility",
  "exported": false
}

如果确实需要跨应用调用，一定要校验来源：

onStart(want) {
  const caller = want.parameters?.callerBundleName;
  if (caller !== 'com.example.trusted') {
    return;
  }
}

一句话总结：

不是不能开放，是要“有门禁”。

🧨 漏洞二：敏感数据明文存储

❌ 问题写法

preferences.put("token", userToken);
preferences.flush();

这在逆向面前，几乎等于白给。

✅ 修复方式：使用加密能力

import cryptoFramework from '@ohos.security.cryptoFramework';

const cipher = cryptoFramework.createCipher('AES256');
const encrypted = cipher.doFinal(userToken);

preferences.put("token", encrypted);

本地数据不加密，本质上就是“等人来拿”。

🧨 漏洞三：日志泄露敏感信息

❌ 问题写法

console.info("login success, token = " + token);

开发阶段爽了，
上线之后就成事故隐患。

✅ 修复方式：分级日志 + 脱敏

console.info("login success");

或者：

console.debug("token length = " + token.length);

四、场景应用：把“安全”真正融进开发流程

安全不是写完代码“补一刀”，而是流程的一部分。

1️⃣ 开发阶段

• 权限最小化
• Ability 默认不导出
• 敏感数据默认加密

2️⃣ 构建阶段

• 静态扫描（权限、组件、API）
• 禁止 debug 配置进生产包

3️⃣ 上线前

• 自查 Ability 暴露清单
• 检查日志级别
• 检查本地存储内容

安全不是某个人的事，是流程兜底的事。

五、Echo_Wish 式思考：安全，其实是一种“职业习惯”

写到这里，我想说点不太技术、但很重要的话。

这些年我发现：

安全意识强的开发者，不一定技术最牛，但一定活得最久。

他们有几个共同点：

• 对“默认配置”保持怀疑
• 对“方便写法”保持警惕
• 对“无所谓吧”保持克制

在鸿蒙这种系统级生态里，这点尤其重要。

因为你写的，不只是一个 App，而是：

• 能不能被别的应用调用
• 能不能成为系统攻击链的一环

六、最后一句话，送给正在写鸿蒙的你

安全漏洞从来不是“突然出现的”，
而是“早就写好了，只是没人提醒”。