Skip to main content

Enabled default credentials

Need

Implementation of strong and unique credentials for all system resources

Context

  • Usage of Scala for building scalable and high-performance applications
  • Usage of Slick for database access in Play Framework
  • Usage of slick.jdbc.JdbcProfile for database access and manipulation in Scala

Description

Non compliant code

import play.api.db.slick.DatabaseConfigProvider
import slick.jdbc.JdbcProfile

class Application @Inject()(protected val dbConfigProvider: DatabaseConfigProvider) extends Controller {
val dbConfig = dbConfigProvider.get[JdbcProfile]

def index = Action {
val connection = dbConfig.db.createSession().conn
val statement = connection.createStatement()
val resultSet = statement.executeQuery("SELECT * FROM users")
Ok(views.html.index(resultSet))
}
}

The above code is vulnerable due to the use of default credentials to access the database. In the application.conf file, the database URL includes the username and password as query parameters. This is a common but insecure practice, as it exposes the credentials in plain text.

The Application class uses the DatabaseConfigProvider to get the database configuration, which includes the credentials. It then creates a new session and executes a query to retrieve all users. If an attacker gains access to the configuration file, they can easily retrieve the credentials and gain unauthorized access to the database.

This vulnerability could lead to data leakage, unauthorized data manipulation, and potentially even more serious attacks such as privilege escalation if the database user has high-level permissions.

Steps

  • Step 1: Change the default credentials for the database connection.
  • Step 2: Use strong and unique credentials for the database connection.
  • Step 3: Avoid hardcoding the credentials in the code. Instead, use a secure configuration file or environment variables to store the credentials.
  • Step 4: Implement proper authentication and authorization mechanisms to control access to system resources.
  • Step 5: Regularly review and update the credentials to ensure they remain secure.
  • Step 6: Consider implementing additional security measures such as encryption for the database connection.

Compliant code

import play.api.db.slick.DatabaseConfigProvider
import slick.jdbc.JdbcProfile
import play.api.Configuration
import javax.inject.Inject

class Application @Inject()(protected val dbConfigProvider: DatabaseConfigProvider, config: Configuration) extends Controller {
val dbConfig = dbConfigProvider.get[JdbcProfile]

def index = Action {
val connection = dbConfig.db.createSession().conn
val statement = connection.createStatement()
val resultSet = statement.executeQuery("SELECT * FROM users")
Ok(views.html.index(resultSet))
}
}

The above code is a Scala backend application using the Play framework. It connects to a database using the Slick library. The DatabaseConfigProvider is used to get the database configuration, which includes the credentials for the database connection.

The vulnerability in this code is that it uses default, low-strength credentials to connect to the database. This can be exploited by attackers to gain unauthorized access to the database and the data it contains.

To fix this vulnerability, we need to change the default credentials and use strong, unique credentials instead. These credentials should not be hardcoded in the code. Instead, they should be stored in a secure configuration file or environment variables. The Play framework provides the Configuration class for this purpose, which can be used to read the credentials from a configuration file or environment variables.

In the fixed code, we inject the Configuration class and use it to get the database credentials. This ensures that the credentials are not exposed in the code and can be securely managed.

Additionally, proper authentication and authorization mechanisms should be implemented to control access to the database. Regular reviews and updates of the credentials should be carried out to ensure they remain secure. Consider implementing additional security measures such as encryption for the database connection.

References