c# - "Untrusted initialization"缺陷 - 创建 SQL 连接时

Question

我做了以下...

private static IDbConnectionProvider CreateSqlConnectionProvider(DbConfig dbConfig)
{
    return new QcDbConnectionProvider(() =>
        {
            SqlConnectionStringBuilder csBuilder = new SqlConnectionStringBuilder();

            if (!string.IsNullOrEmpty(dbConfig.DataSource)) 
                csBuilder.DataSource = dbConfig.DataSource;

            if (!string.IsNullOrEmpty(dbConfig.Database))
                csBuilder.InitialCatalog = dbConfig.Database;

            .
            .
            .
            .

            return new SqlConnection(csBuilder.ConnectionString);
        });
}

客户端正在使用 VERACODE 工具进行代码分析，VERACODE 在

检测到缺陷“不受信任的初始化”

return new SqlConnection(csBuilder.ConnectionString);

此外，dbConfig 正在初始化，如下所示...

DbConfig configDbConfig = new DbConfig
{
    Database = codeFile.ConfigurationDb,
    DataSource = codeFile.DataSource,
    IntegratedSecurity = sqlCredentials.UseWindowsAuthentication ? 1 : 0,
    UserId = sqlCredentials.UseWindowsAuthentication ? null : sqlCredentials.SqlUserName,
    ClearTextPassword = sqlCredentials.UseWindowsAuthentication ? null : sqlCredentials.SqlUserPassword
};

为了修复此缺陷，我还需要做什么？同样根据 this link ，我正在使用 SqlConnectionStringBuilder 创建连接字符串，它可以安全地创建连接字符串。

提前致谢...

Answer 1

不受信任的初始化问题的描述是:

Applications should be reluctant to trust variables that have been initialized outside of its trust boundary. Untrusted initialization refers to instances in which an application allows external control of system settings or variables, which can disrupt service or cause an application to behave in unexpected ways. For example, if an application uses values from the environment, assuming the data cannot be tampered with, it may use that data in a dangerous way.

在您的情况下，您正在从文件中读取 dbConfig 的数据:

 if (TryReadCodeFile(configurationProfileFile...)) {
     DbConfig configDbConfig = new DbConfig...
}

请注意，您收到的警告还应带有行号(以限制错误 代码)。您发布的代码中的几乎所有内容都会产生此问题(我不知道 sqlCredentials 来自哪里，但如果它们是明文形式，它甚至可能是安全问题的另一个来源 - 或者要解密的代码是在您的应用程序中访问)。

来自引用的段落:“...应用程序允许外部控制系统设置或变量，这可能会中断服务。 ..”。这是这个问题的核心:如果您的应用程序使用外部数据而没有对其进行直接控制，那么它的行为可以通过修改该数据来改变。这些外部数据是什么？列表是全部但并非详尽无遗:

• 环境变量(例如解析另一个文件或程序的路径)，因为用户可能会更改它们。原始文件未被触及，但您阅读了其他内容。
• 路径(用于加载代码或数据)，因为用户可能会重定向到其他内容(同样，原始文件未被触及，但您阅读了其他内容)。
• 支持文件，因为用户可以更改它们(例如，在您的情况下，指向另一个服务器和/或目录)。
• 配置文件，因为用户可以更改它们(同上)。
• 数据库，因为其他用户也可以访问它们并且它们可能会被更改(但它们可能会受到保护)。

恶意用户如何使用它？想象一下，每个用户都连接到不同的目录(根据他们在组织中的规则)。这不能更改，它是在安装期间配置的。如果他们可以访问您的配置文件，他们可能会将目录更改为其他内容。他们还可以将数据库主机名更改为一个隧道，他们可以在其中嗅探数据(如果他们可以物理访问其他人的机器)。

另请注意，他们还说“...假设数据无法被篡改，它可能会以危险的方式使用该数据”。这意味着，例如，如果您的应用程序在 Web 服务器上运行并且物理访问是安全的，那么您可能会认为该数据安全。

请注意，您的应用程序将作为整个系统中安全性较低的项目而变得安全。请注意，要使应用程序安全(我知道，这个术语很模糊)加密密码是不够的。

如果支持文件可能被操纵，那么您能做的最好的事情就是使用公钥/私钥加密来加密它们。一个不太理想的解决方案是计算 CRC 或散列(例如)您将在使用配置文件之前应用它们(它们能够更改它们，但您的应用程序会检测到此问题)。

总结:您可以忽略这个问题，但您必须向您的客户证明您所依赖的数据无法被篡改。如果至少满足以下条件之一，您可以合理地证明:

1) 除了您的应用程序之外，其他任何人都无法访问支持文件所在的系统。您的应用程序安全性不能高于系统安全性。

2) 您的支持文件在每台机器上都是有效的(以避免在不同机器之间复制)，并且它们以任何人都无法(有意或无意)更改的方式进行加密。3) 您的支持文件对每台机器都是有效的，并且它们以您的应用程序可以检测到外部更改的方式被散列。

4) 无论用户对您的配置文件做什么，应用程序本身都不能因此改变其行为(例如，它是一个单一安装，其中只有一个数据库和一个目录)。