Open Database

The database is used as the main storage for sensitive data in the majority of products. Protecting the data your company collects and manages is essential. Database security can protect against compromising your database, which may lead to financial loss, reputational damage, destruction of consumer trust, and non-compliance with government regulations. If the database is not protected properly, access is open for external clients/servers/networks, and weak authentication methods are used - all this provides a wide range of possibilities for an attacker.

🚧

This test is not supported when using a Repeater.

This vulnerability allows an attacker to read and modify the application data.

• The issue can be found in the server configuration.
• The issue can be found in the database configuration.

It is necessary to configure the server and the database on several key aspects.

The main objectives:

• Restrict access to the database only to the necessary points
• Provide strong authentication mechanism
• Grant minimum required permissions for the database users

Connection to the database:

The backend database used by the application should be isolated as much as possible in order to prevent malicious or undesirable users from being able to connect to it.Direct connections should never be made from an untrusted client/system to the backend database. The following options could be used to protect the database connection:

• Disabling network (TCP) access and requiring entire access over a local socket file or named pipe.
• Configuring the database to only bind on localhost.
• Restricting access to the network port to specific hosts with firewall rules.
• Placing the database server in a separate DMZ isolated from the application server.
• Configuring the database to only allow encrypted connections.

Authentication:

The database should be configured to always require authentication, including connections from the local server. Database accounts should be:

• Protected with strong and unique passwords.
• Used by a single application or a service.
• Configured with the minimum permissions required.

Database credentials should never be stored in the application source code. Instead, they should be stored in a configuration file that:

• Is outside of the webroot.
• Has appropriate permissions so that it can only be read by the required users.
• Is not checked into source code repositories.

Permissions:

The permissions assigned to the database user accounts should be based on the least privilege principle: the accounts should only have the minimal permissions required for the application to function. The following steps should be applicable to all environments:

• Do not use the built-in root, sa or SYS accounts.
• Do not grant the account administrative rights over the database instance.
• Allow the account to connect only from allowed hosts.
  • This would often be localhost or the address of the application server.
• Grant the account access to only the specific databases it needs.
  • Development, UAT and Production environments should all use separate databases and accounts.
• Only grant the required permissions to the databases.
  • Most applications would only need SELECT, UPDATE and DELETE permissions.
  • The account should not be the owner of the database as this can lead to privilege escalation vulnerabilities.
• Avoid using database links or linked servers.
  • Where they are required, use an account that has been granted access to only the minimum databases, tables, and system privileges required.

• CWE-284
• CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

• https://cwe.mitre.org/data/definitions/284.html
• https://owasp.org/www-project-proactive-controls/v3/en/c3-secure-database