10、命令行参数与环境变量：命令行注入、环境变量污染、安全的参数解析

说实话，命令行参数和环境变量这块，是我早期做C开发时踩坑最多的领域之一。那时候我总觉得，用户传进来的参数嘛，不就是字符串吗？直接拿来用不就完了？结果呢？被现实狠狠教育了几次之后，我才真正重视起这块的安全问题。

今天咱们就好好聊聊这个话题。我会把我在项目中遇到的那些坑，以及后来总结出的防御手段，都摊开来跟你讲讲。

10.1 命令行注入：一个空格就能搞垮你的程序

先说说命令行注入。这玩意儿说白了，就是攻击者通过精心构造的参数，让你的程序执行了本不该执行的命令。

我举个例子你就明白了。假设你写了个工具，需要根据用户输入的文件名来执行某个系统命令：

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void process_file(const char *filename) {
    char cmd[256];
    snprintf(cmd, sizeof(cmd), "cat %s", filename);
    system(cmd);  // 危险！直接拼接用户输入
}

int main(int argc, char *argv[]) {
    if (argc < 2) {
        fprintf(stderr, "用法: %s <文件名>\n", argv[0]);
        return 1;
    }
    process_file(argv[1]);
    return 0;
}

你看，这段代码有什么问题？问题大了去了。如果用户输入的是 test.txt; rm -rf /，那你的程序就会先执行 cat test.txt，然后执行 rm -rf /。嗯，后果你自己想。

我在一个嵌入式项目中就遇到过类似的事。当时有个同事写了个日志查看工具，用户输入日期参数，程序就调用 grep 去搜索日志文件。结果测试的时候，有人输入了 2024-01-01; shutdown -h now，整个系统直接关机了。那次事故之后，我们团队定了个规矩：能用库函数解决的问题，绝不用 system()。

10.2 安全的参数解析：别偷懒，用标准库

那怎么安全地处理命令行参数呢？我个人习惯用 getopt() 或者 getopt_long()。这两个函数是POSIX标准提供的，能帮你做参数校验和解析。

来看看正确的做法：

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

int main(int argc, char *argv[]) {
    int opt;
    char *input_file = NULL;
    int verbose = 0;
    
    // 使用 getopt 安全解析参数
    while ((opt = getopt(argc, argv, "i:v")) != -1) {
        switch (opt) {
            case 'i':
                input_file = strdup(optarg);
                if (input_file == NULL) {
                    perror("strdup");
                    exit(EXIT_FAILURE);
                }
                break;
            case 'v':
                verbose = 1;
                break;
            default:
                fprintf(stderr, "用法: %s -i <文件> [-v]\n", argv[0]);
                exit(EXIT_FAILURE);
        }
    }
    
    if (input_file == NULL) {
        fprintf(stderr, "错误: 必须指定输入文件\n");
        exit(EXIT_FAILURE);
    }
    
    // 这里用安全的文件操作，而不是 system()
    FILE *fp = fopen(input_file, "r");
    if (fp == NULL) {
        perror("fopen");
        free(input_file);
        exit(EXIT_FAILURE);
    }
    
    // 处理文件内容...
    printf("正在处理文件: %s (详细模式: %s)\n", 
           input_file, verbose ? "开启" : "关闭");
    
    fclose(fp);
    free(input_file);
    return 0;
}

你想想看，用标准库函数来解析参数，不仅代码更简洁，而且安全性有保障。为什么还要自己手写解析逻辑呢？

10.3 环境变量污染：看不见的威胁

环境变量这块，很多人容易忽视。我刚开始做C开发时也觉得，环境变量不就是系统设置吗？能有什么安全问题？

后来我才明白，环境变量可以被攻击者控制。比如通过 LD_PRELOAD 环境变量，攻击者可以加载恶意共享库，劫持你的函数调用。

来看一个典型的漏洞场景：

#include <stdio.h>
#include <stdlib.h>

int main() {
    char *path = getenv("PATH");
    if (path == NULL) {
        path = "/usr/bin:/bin";
    }
    
    // 危险！使用环境变量中的路径
    char cmd[256];
    snprintf(cmd, sizeof(cmd), "%s/ls -la", path);
    system(cmd);  // 攻击者可以修改 PATH 指向恶意程序
    
    return 0;
}

攻击者可以设置 PATH=/tmp/malicious，然后在 /tmp/malicious/ 下放一个恶意的 ls 程序。你的程序就会执行这个恶意程序。

10.4 安全处理环境变量的最佳实践

那怎么安全地处理环境变量呢？我总结了几个要点：

1. 使用 secure_getenv()：这个函数在setuid/setgid程序中使用时，会返回NULL，防止环境变量污染。
2. 清理敏感环境变量：在程序启动时，清除 LD_PRELOAD、LD_LIBRARY_PATH 等危险变量。
3. 使用绝对路径：调用外部程序时，永远使用绝对路径。

来看一个安全的实现：

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

void sanitize_environment() {
    // 清除危险的环境变量
    unsetenv("LD_PRELOAD");
    unsetenv("LD_LIBRARY_PATH");
    unsetenv("LD_AUDIT");
    unsetenv("LD_DEBUG");
    
    // 使用 secure_getenv 获取环境变量
    const char *home = secure_getenv("HOME");
    if (home == NULL) {
        // 在安全上下文中，HOME 不可用
        home = "/tmp";
    }
    
    printf("用户目录: %s\n", home);
}

int main() {
    sanitize_environment();
    
    // 使用绝对路径调用外部程序
    execl("/bin/ls", "ls", "-la", NULL);
    
    // 如果 execl 返回，说明出错了
    perror("execl");
    return 1;
}

10.5 知识体系总览

说了这么多，我画了张图帮你梳理一下整个知识体系。这样你一眼就能看清命令行参数和环境变量安全的核心要点：

10.6 我曾经踩过的坑

最后，分享一个我亲身经历的教训。有一次我写了个网络服务程序，需要根据环境变量来决定日志级别。代码大概是这样的：

char *log_level = getenv("LOG_LEVEL");
if (log_level != NULL && strcmp(log_level, "DEBUG") == 0) {
    enable_debug_logging();
}

看起来没什么问题对吧？但问题出在，这个程序运行在共享主机上，其他用户可以通过修改环境变量来让我的程序输出调试信息。调试信息里包含了数据库连接字符串和密钥！

那次之后，我养成了一个习惯：所有敏感信息都从配置文件读取，而不是环境变量。环境变量只用来控制一些非敏感的行为，比如是否显示彩色输出。

好了，关于命令行参数和环境变量的安全处理，我就讲这么多。记住一句话：在安全领域，偷懒的代价往往是你无法承受的。每次写代码时多问自己一句「这个输入能被攻击者控制吗？」，就能避免很多问题。