DataDirect for JDBC drivers use connection properties to configure driver behavior and connection settings. Although applications often require end users to provide information that is used to configure these properties and establish a connection, it is important to restrict access to only approved users, control which properties are configurable by the end user, and validate the values provided. Failure to do so can potentially expose security vulnerabilities and introduce behavior that the application has not been tested against.

The following sections describes some steps you can take to protect your connection property values as well as a list of common connection properties to which you should restrict access.

Secure the connection URL

If your application passes a connection URL to establish the JDBC connection, it is important to secure it if it contains sensitive credentials. To keep your sensitive information safe, observe the following security best practices when using a connection URL:
  • Do not hard code the connection URL in the application source code or configuration files. The application should retrieve the connection URL or configuration information from a secure storage mechanism.
  • If applications need configuration files to connect, make sure the persisted location is fully secured and not accessible to unauthorized users.

Validate connection property values

Some applications build connection URLs dynamically based on user inputs. In such cases, user inputs need to be validated to avoid unintended values that might cause any malicious behavior.

Restrict access to properties

The first step in protecting your property values is to restrict the connection properties specified by the user. Your application interface should expose only properties that you trust the user to configure. See "Connection properties that require restricted access" for more information on exposing and restricting access to connection properties.

Deployment-specific validation of connection property values

After restricting which connection properties that can be set by the user, you should consider additional validation of the values for those properties. For instance, the connection property TrustStore accepts a file path; therefore, you may need to add validation to ensure the specified path aligns with the expectations appropriate for your application and deployment.

Validate connection property values to prevent injection

Connection property values need to be validated to prevent the user from specifying additional connection properties. For instance, an application that performs no validation may accept the following value for the ServerName property: 

192.168.1.123;encryptionMethod=noEncryption

In this case, in addition to specifying the host, the user also set the connection property to disable encryption.

Connection properties that require restricted access

The lists in this section document common connection properties that we recommend that you restrict end users from configuring. Note that this is not an exhaustive list of properties for which you should restrict user access. Depending on how your application uses functionality controlled by other supported properties, you may want to prevent the user from configuring some or all of those properties as well. Additionally, each driver might have driver-specific properties that can affect driver behavior and, therefore, impact your application. Application developers should review all the properties supported by a driver to determine which properties should be restricted.

For a complete list of supported connection properties, refer to the "Connection property descriptions" section of the user's guide for your driver.

Connection properties that affect driver libraries

The drivers support multiple properties that allow users to specify alternate implementations of libraries used by the driver. By allowing an end user to provide values for these properties, they could configure the driver to use an implementation of a library that your application was not tested against.

For example, the LoadLibraryPath property allows alternate library implementations. This property is exposed by drivers that support NTLM authentication, like the Oracle and SQL Server drivers. We recommend that the application restrict end users from specifying LoadLibraryPath or other properties that allow you to specify alternate libraries.

Connection properties that affect driver behavior

Certain supported properties can change the behavior of the driver and, therefore, impact the performance of your application. For example, there are properties that change what columns are returned in metadata calls (CatalogOptions) or issue SQL commands at connection (InitializationString). Changing the values of these properties to something other than what the application was tested with or is expecting could cause errors in the application. The following are common properties that change the driver behavior:
  • CatalogOptions
  • CreateMap
  • InitializationString
  • RefreshSchema
  • ReadAhead
  • SpyAttributes
  • StmtCallLimit