“不受信任的初始化"；缺陷-在创建SQL连接时 [英] "Untrusted initialization" flaw - while creating SQL Connection

问题描述

我已经完成了以下工作...

I have done the following...

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在

The client is using VERACODE tool for doing code analysis and the VERACODE has detected a flaw "Untrusted initialization" at

return new SqlConnection(csBuilder.ConnectionString);

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

Also, the dbConfig is being initialized as shown below...

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
};

要修复此缺陷，我还需要做什么?同样根据

What else I need to do in order to fix this flaw? Also as per this link, I am creating the connection string using the SqlConnectionStringBuilder which is safe of creating the connection string.

预先感谢...

推荐答案

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

应用程序不应该信任已在其信任边界之外初始化的变量.不受信任的初始化是指实例，其中应用程序允许对系统设置或变量进行外部控制，这可能会中断服务或导致应用程序以意外方式运行.例如，如果应用程序使用环境中的值，则假设无法篡改数据，则它可能会以危险方式使用该数据.

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的数据:

In your case you're reading data for dbConfig from file:

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

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

Note that warning you get should also come with a line number (to circumscribe erroneous code). Almost everything in code you posted can generate this issue (I don't see where sqlCredentials comes from but it may even be another source of security problems if they're in clear text - or code to decrypt is accessible in your application).

从引用的段落开始:"...应用程序允许外部控制系统设置或变量，这可能会中断服务. ..".这是此问题的核心:如果您的应用程序使用外部数据而没有对其的直接控制，则可以更改其行为以修改该数据.这些外部数据是什么?列表是全部但并非详尽无遗:

From cited paragraph: "...application allows external control of system settings or variables, which can disrupt service...". This is the core of this issue: if your application uses external data without a direct control over them then its behavior can be changed modifying that data. What these external data are? List is all but not exhaustive:

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

恶意用户可能如何使用它?想象每个用户都连接到一个不同的目录(根据他们在组织中的规则).此设置无法更改，并且在安装过程中进行了配置.如果他们可以访问您的配置文件，则可以将目录更改为其他目录.他们还可以将数据库主机名更改为 tunnel ，在其中可以嗅探数据(如果他们可以物理访问其他人的计算机).

How a malicious user may use this? Imagine each user is connected to a different catalog (according to their rule in organization). This cannot be changed and it's configured during installation. If they can have access to your configuration files they may change catalog to something else. They may also change DB host name to a tunnel where they may sniff data (if they have physical access to someone else's machine).

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

Also note that they also say "...assuming the data cannot be tampered with, it may use that data in a dangerous way". It means if, for example, your application runs on a web server and physical access is secured then you may consider that data safe.

请注意，您的应用程序将是安全的，因为它在整个系统中的安全性较低.请注意，使应用程序安全(我知道，这个术语很模糊)不足以对密码进行加密.

Be aware your application will be secure as less secure item in your whole system. Note that to make an application safe (I know, this term is pretty vague) to encrypt password is not enough.

如果可以操纵支持文件，那么最好的办法是使用公钥/私钥加密对它们进行加密.较不理想的解决方案是计算CRC或哈希(例如)，然后在使用配置文件之前将它们应用于配置文件(它们可以更改它们，但您的应用程序会检测到此问题).

If support files may be manipulated then best thing you can do is to encrypt them with a public/private key encryption. A less optimal solution is to calculate a CRC or hash (for example) you'll apply to configuration files before you use them (they are able to change them but your application will detect this issue).

总结:您可以忽略此问题，但是必须向客户证明您依赖的数据不会被篡改.如果至少满足以下条件之一，则可以合理地<证明>证明:

To summarize: you can ignore this issue but you have to prove your customer that data you rely on cannot be tampered. You can reasonably prove if at least one of these conditions is satisfied:

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

1) System where support files reside is not accessible by anyone else than your application. Your application security cannot be higher than system security.

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

2) Your support files are valid per-machine (to avoid copies between different machines) and they're encrypted in a way they cannot be changed (intentionally or not) by anyone. 3) Your support files are valid per-machine and they're hashed in a way your application can detect external changes.

4)用户使用您的配置文件做什么都没有关系，因此应用程序本身无法更改其行为(例如，它是一个安装，其中只有一个DB和一个目录).

4) It doesn't matter what users do with your configuration files, application itself cannot change its behavior because of that (for example it's a single installation where only one DB and one catalog exist).

这篇关于“不受信任的初始化"；缺陷-在创建SQL连接时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！