JCamargo104365 (Community Member) asked a question.

November 18, 2021 at 5:02 PM
CWE 15 Reading connection string properties from a database table

Hello,

We are getting a CWE 15 flaw in a static scan. I have read through most posts on this and the basic gist is that if the connection string properties are read from user controlled variables then a attacker can gain access by controlling the variables he has access to.

 

Having said that, in our case the connection string is controlled by user authentication to our system. When a user authenticates to our system, we know what database to connect them to based on their credentials. User access to these variables don't exist.

 

Is this a proper candidate for mitigation by OS Environment or Network Environment? The database in this case is considered a safe area because only authenticated users to our network have access to these table values.

  • 5 answers
  • 2.18K views

  • Florian, Security Consultant (Veracode)

    Hi @JCamargo104365 (Community Member)​,

     

    Yes, we report CWE 15 whenever we can see that parts of a connection string come from outside the application, such as your database. There are two main concerns here:

    1. Outside influence of the connection string, e.g. by end-users
    2. Secure storage of credentials at rest (plaintext storage of credentials is a security issue)

     

    It's not necessarily a good idea to consider the database as generally safe as, often, values in the database are directly derived from user input.

     

    I would recommend going through the steps provided by @Boy, Security Consultant (Veracode)​ (https://community.veracode.com/s/question/0D52T00004ovKsP/external-control-of-system-or-configuration-setting-cwe-id-15), in your case starting with step 2.

     

    Afterwards, the remaining risk might be acceptable for your organization's Security Team and all controls in place can be documented in a mitigation proposal (I would recommend Mitigation By Design). You can find more information on how to propose a mitigation here: https://docs.veracode.com/r/improve_mitigation

     

    Thank you,

    Florian Walter

    Expand Post

    • JCamargo104365 (Community Member)

      Thanks Florian for your reply. I have a few followup questions.

      1. If the connection string is not influenced by the end users input, how do we resolve the warning for this? Is this considered a false positive?
      2. FYI Credentials are integrated, so its not stored in plain text.

      • Florian, Security Consultant (Veracode)

        From our point of view, this would not be a false-positive but can potentially be mitigated by design. I would recommend doing the following:

         

        1. Ensure you are using a Connection String Builder if you are dynamically creating the connection string (https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/connection-string-builders)
        2. Investigate if you should encrypt the connection string: https://docs.microsoft.com/en-us/previous-versions/ms178372(v=vs.140)
        3. Review any dynamic data in the connection string and replace it, if possible, with a hardcoded value.
        4. If not possible, ensure you have validation in place for the dynamic data

         

        Afterwards, all existing controls should be documented in a mitigation proposal which then needs to be reviewed by your Security Team.

         

        Regarding your 2nd point: Could you please elaborate on what you mean by "integrated"?

         

        Thank you,

        Florian Walter

        Expand Post

      • JCamargo104365 (Community Member)

        1. We will use connection string builder, for these
        2. The connection string is not stored in web config. Instead we build it dynamically based on a user's table
        3. The connection string is: String.Format("Data Source={0};Initial Catalog={1};Integrated Security=SSPI", ServerName, DBName)
          1. In the above string servername and dbname are not user inputs. The user doesn't have control over these variables
          2. Integrated meant Integrated Security=SSPI
          3. These can't be hard coded because the database they connect to is dependent on who the user is
        4. The user doesn't have control over the servername or dbname variables. So I believe validation is not needed.

        So given how we have these connection strings built, all we have to do is use the connection string builder and mark it mitigated by Design?

         

        Expand Post

      • Florian, Security Consultant (Veracode)

        Hi @JCamargo104365 (Community Member)​,

         

        I appreciate that the dynamic data comes from the database and is not directly controllable by an attacker. However, we would still recommend applying some validation. Ideally, your application should run securely in a potentially hostile environment and not rely on the database being considered trusted.

         

        Using the `SqlConnectionStringBuilder` will help prevent adding additional arguments by an attacker but won't be able to prevent changing the server name e.g. to "my-evil-database-host.com".

         

        We recommend validating the database configuration against an allow-list of servers you trust, as well as making sure the database is one of the databases you want to access here. Using an allow-list is also something that Veracode Static Analysis is automatically able to detect and close the flaw if applied like this: https://community.veracode.com/s/article/Using-an-Allow-list-in-a-Way-Static-Analysis-can-Detect

         

        Thanks,

        Florian Walter

        Expand Post

Topics (3)

No articles found
Loading

Ask the Community

Get answers, share a use case, discuss your favorite features, or get input from the community.