组件安全设计模式：最小权限、默认不导出、输入验证、输出过滤

各位同学好，今天我们来聊聊组件安全的设计模式。说实话，这部分内容是我在实际项目中踩坑最多的地方。很多开发者觉得安全设计就是加几行代码的事，其实不然。我个人的经验是，安全设计应该像呼吸一样自然，融入到你的编码习惯里。

咱们今天要讲的四个设计实践——最小权限原则、默认不导出、输入验证、输出过滤——说白了就是一套组合拳。你想想看，如果每个组件都像筛子一样到处漏，那再强的加密也没用。嗯，咱们一个一个来看。

1. 最小权限原则：别给组件开绿灯

什么叫最小权限？就是每个组件只拿它需要的那点权限，多一点都不给。我在项目中遇到过不少这样的案例：一个只用来显示图片的Activity，居然声明了读取通讯录的权限。这不是给自己挖坑吗？

举个例子，假设你有一个ShareActivity，它只需要接收外部传进来的文本并展示。那它的权限就应该只限于接收ACTION_SEND的Intent，别的不该碰。

<activity android:name=".ShareActivity">
    <intent-filter>
        <action android:name="android.intent.action.SEND" />
        <category android:name="android.intent.category.DEFAULT" />
        <data android:mimeType="text/plain" />
    </intent-filter>
</activity>

你看，这个Activity只处理文本分享，连文件都不碰。这就是最小权限的体现。我曾经接手过一个项目，里面有个Provider声明了READ_EXTERNAL_STORAGE权限，但实际上它只读数据库。这种多余权限，说白了就是给攻击者留后门。

2. 默认不导出：别让组件裸奔

这个原则其实很简单：除非你明确想让其他应用调用你的组件，否则就别导出。我记得Android 12之后，系统对未显式声明exported的组件会直接报错。但很多老项目还在用默认行为，这很危险。

为什么？因为默认情况下，如果组件包含intent-filter，它就会被导出。你想想看，一个本应只在内部使用的Activity，因为加了个intent-filter就暴露给全世界了，这合理吗？

正确的做法是：

<activity
    android:name=".InternalActivity"
    android:exported="false">
    <!-- 即使有intent-filter，也不会被外部调用 -->
</activity>

我曾经在审计一个金融App时发现，它的登录Activity居然被导出了。这意味着任何恶意应用都可以直接调起登录界面，甚至通过Intent注入恶意数据。嗯，这要是被利用了，后果不堪设想。

3. 输入验证：别信任何外来数据

这个原则听起来简单，做起来难。我见过太多开发者觉得"反正数据是从系统来的，应该没问题"。但你要知道，Intent可以伪造，Content URI可以篡改，甚至系统广播都可能被劫持。

输入验证的核心就一句话：永远不要信任外部输入。不管是来自其他App的Intent，还是通过ContentProvider查询的参数，都要做严格的校验。

来看一个典型的例子：

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    
    Intent intent = getIntent();
    if (intent == null || intent.getAction() == null) {
        finish();
        return;
    }
    
    // 验证action是否合法
    String action = intent.getAction();
    if (!action.equals(Intent.ACTION_SEND)) {
        Log.w("Security", "非法action: " + action);
        finish();
        return;
    }
    
    // 验证数据类型
    String type = intent.getType();
    if (!"text/plain".equals(type)) {
        Log.w("Security", "非法数据类型: " + type);
        finish();
        return;
    }
    
    // 安全地获取数据
    String text = intent.getStringExtra(Intent.EXTRA_TEXT);
    if (text == null || text.length() > MAX_TEXT_LENGTH) {
        finish();
        return;
    }
    
    // 处理数据...
}

你看，每一步都在做验证。action不对？直接退出。类型不对？直接退出。数据为空或超长？直接退出。这就是输入验证的典型流程。

4. 输出过滤：别把家底都亮出来

输出过滤和输入验证是孪生兄弟。输入验证防的是外部数据进来搞破坏，输出过滤防的是内部数据出去泄露机密。说白了，就是你的组件在返回数据给调用方时，要确保只返回必要的信息。

举个例子，一个ContentProvider查询用户信息，调用方可能只想要用户名，但你的Provider却把手机号、身份证号都返回了。这就是典型的输出过度。

正确的做法是：

@Override
public Cursor query(Uri uri, String[] projection, String selection,
                    String[] selectionArgs, String sortOrder) {
    // 限制返回的列
    if (projection == null) {
        // 默认只返回安全字段
        projection = new String[]{
            UserContract.COLUMN_USERNAME,
            UserContract.COLUMN_AVATAR_URL
        };
    } else {
        // 过滤掉敏感字段
        List<String> safeProjection = new ArrayList<>();
        for (String col : projection) {
            if (isSafeColumn(col)) {
                safeProjection.add(col);
            }
        }
        projection = safeProjection.toArray(new String[0]);
    }
    
    // 执行查询...
}

我曾经在项目中遇到过这样一个问题：一个Provider返回用户数据时，默认包含了password_hash字段。虽然调用方没请求这个字段，但Provider的默认实现把所有字段都返回了。嗯，这要是被内部员工滥用，后果很严重。

知识体系总览

说了这么多，咱们用一张图来总结一下这四个设计模式的关系。我画了一个简单的流程图，展示它们如何协同工作：

从这张图可以看出，这四个设计模式不是孤立的。它们从组件声明、到被调用、再到返回数据，形成了一个完整的防护链条。我个人习惯在项目初期就把这些原则固化到代码规范里，而不是等出了问题再补救。

总结一下

好了，今天的内容就到这里。咱们回顾一下：

• 最小权限原则：别给组件开绿灯，只给必要的权限
• 默认不导出：别让组件裸奔，显式声明exported
• 输入验证：别信任何外来数据，做严格校验
• 输出过滤：别把家底都亮出来，只返回必要信息

这四个原则说起来简单，但真正落地需要养成习惯。我建议你在每次新建组件时，都问自己三个问题：这个组件需要导出吗？它需要哪些权限？它返回的数据安全吗？养成这个习惯，你的App安全性会上一个大台阶。

---

公众号:蓝海资料掘金营，微信deep3321