Automatized or semi-automatized solutions for data migration are being constantly adopted to optimize software engineering processes.This kind of process aims to manage, in an incremented way, the changes occurred in relational databases. However, this practice may become potentially dangerous when users have more permissions than necessary, which may make it easier for a cybercriminal to gain access to a system.
The data migration routines are commonly performed with the use of programing languages, frameworks or independent tools (like Flyway or Liquidbase). Some frameworks, like Rails and Django, have their own tools to perform this task. However, Object-relational mapping libraries, like GORM for Golang, offer such flexibility at their migration features that they make it tempting to have the inclusion of these processes directly at the application code.
On such flexible scenarios, vulnerabilities related to data access by an application, i.e. SQL Injection, could provide an attacker with much more possibilities, enabling him to exploit both the data and the database structure. Besides that, the credentials for accessing the database on the application are generally placed in configuration files, which enables other types of attacks, including the direct access to the database. An attacker could, for example, create triggers that would silently alter values in specific database tables.
Restricting the privileges
As a good management practice, it is recommended to grant as few privileges as possible for users or outsourced applications to interact with a given system. This also applies in the case of databases. There is an additional concern, however, with respect to the privileges given to applications for them to define and manipulate registry. Migration routines in relational databases normally demand both DDL (Data Definition Language) and DML (Data Manipulation Language) permissions.
In this way, it is recommended that the data migration routines be performed by a different user than the username used by the application. In addition, the application user must have restricted privileges, and should only perform strictly defined operations on very specific tables, reducing the risks inherent to a potential vulnerability. It is important to note that this recommendation also applies to frameworks that segregate application and migration functionalities.
Relational databases like PostgreSQL allow to limit the access of users to some operations (SELECT, INSERT, UPDATE, DELETE, CREATE, etc.) in specific tables. This feature enables to restrict what the application database user can do. It is also possible to ensure that the developer has different privileges when programming for data migration or application.
Importantly, even in the case of attacks exploiting vulnerabilities such as SQL Injection or credential theft, it would not be possible for a hypothetical attacker to exploit additional privileges granted to an application user in an environment where these privileges were not granted. That is, ensuring multilevel security reduces potential damage from a vulnerability, even if it has not yet been detected.
