The disadvantage of "unreliable initialization" when creating an SQL connection

Question

I did 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); }); } 

The client uses the VERACODE tool to parse the code, and VERACODE has detected a "Poor Initialization" error on

 return new SqlConnection(csBuilder.ConnectionString); 

In addition, dbConfig 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 do I need to do to fix this? Also according to this link , I create a connection string using SqlConnectionStringBuilder , which is safe to create a connection string.

Thank you in advance...

Answer 1

Description for the problem with unreliable initialization:

Applications should be reluctant to trust variables that have been initialized outside of its trust boundary. Incorrect initialization refers to instances in which the application allows external control of system settings or variables, which can interrupt service or cause the application to behave in unpredictable ways. For example, if an application uses values ​​from the environment, assuming that the data cannot be changed, they can use this data in a dangerous way.

In your case, you are reading data for dbConfig from a file:

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

Please note that the warning you receive should also contain a line number (to describe the error code). Almost everything that you indicated in the code can generate this problem (I don’t see where sqlCredentials comes sqlCredentials , but it can be another source of security problems if they are in clear text or decryption code is available in your application).

From the cited paragraph: "... the application allows external control of system settings or variables that may interfere with maintenance ...", This is the core of this problem: if your application uses external data without direct control over them, then its behavior can be changed by changing this data. What is this external data? The list is not exhaustive:

• Environment variables (for example, to resolve the path to another file or program), because the user can change them. The source files are not affected, but you are reading something else.
• Ways (to download code or data), because the user can redirect to something else (again, the source files are not touched, but you are reading something else).
• Support files, because the user can change them (in your case, for example, specify a different server and / or directory).
• Configuration files, as the user can change them (the same as above).
• Databases, as they may be accessible to other users, and they may be changed (but they may be protected).

How can an attacker use this? Imagine that each user is connected to a different directory (according to their rule in the organization). It cannot be changed and configured during installation. If they can access your configuration files, they can change the directory to something else. They can also change the hostname of the database in the tunnel, where they can sniff the data (if they have physical access to someone else).

Also note that they also say: "... if the data cannot be changed, they can use this data in a dangerous way." This means that, for example, if your application is running on a web server and physical access is protected, you can consider this data safe.

Remember that your application will be safe as a less secure element throughout your system. Please note that to ensure the security of the application (I know this term is rather vague), password encryption is not enough.

If support files can be processed, it is best to encrypt them using public / private key encryption. A less optimal solution is to calculate the CRC or hash (for example) that you will apply to the configuration files before using them (they can change them, but your application will detect this problem).

To summarize:, you can ignore this problem, but you must prove to your client that the data you rely on cannot be tampered with . You can reasonably prove that at least one of these conditions is satisfied:

1) The system in which the support files are located is not accessible to anyone except your application. The security of your application cannot be higher than the security of the system.

2) Your support files are valid for each machine (to avoid copying between different machines), and they are encrypted in such a way that they cannot be changed (intentionally or not) by anyone. 3) Your support files are valid for each machine, and they are hashed in such a way that your application can detect external changes.

4) No matter what users do with your configuration files, the application itself cannot change its behavior because of this (for example, this is the only installation in which there is only one DB and one directory).

Answer 2

Most important for connection strings is how they are stored. If they are stored in clear text, this creates a security risk. Therefore, it is desirable to store them in encrypted form, and in the application to decrypt and use.