S 4.73 Specification of upper limits for selectable records

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator, Application Developer

In order to improve the ability to control access to a database system and the performance, upper limits should be specified for certain parameters of database systems.

In addition, the likelihood of certain types of denial-of-service attacks can be reduced by implementing this safeguard (see T 5.65 Denial of services in a database system).

Examples include:

The following information in particular should be considered in this context:

Specification of upper limits for selectable records

A maximum number of records allowed to be selected within the framework of a data access should be defined, especially when there are large amounts of data stored in a database.

If no such upper limits are specified, users may intentionally or unintentionally execute select operations returning enormous amounts of data. This not only slows down the individual user while working, but may also cause long response times for all other users of the database under some circumstances. If the records are selected to be modified, these records will be blocked for all other users until the transaction has been completed.

The upper limits must be defined within the framework of the applications that access the database. In this case, suitable controls and/or locks must be implemented to monitor the upper limits and ensure they are not exceeded. If an application provides search functionalities, unrestricted searches should be rejected as a rule and the user should be prompted to enter search criteria.

If the application program and database are far apart physically (for example when they are connected using the Internet), the results of searches should be transmitted in blocks and upper limits must be defined for these blocks as well.

Example:

An application program accesses a database using an internet connection. The queries passed by the application program to the database have the potential to return very large amounts of data. To avoid the risk of slowing down the transmission to the application due to excessively large blocks of results, the query is encapsulated in a procedure on the database. This procedure transmits a specified amount of data (5 records, for example) each time it is called. A loop in the application software sends queries to the DBMS and re-assembles the partial results received or may even display the partial results.

Specification of resource restrictions

Another option provided by some manufacturers to restrict the use of a database is the specification of resource restrictions.

Examples:

In an Oracle database, the following command limits the size of the temporary tablespace "Temp" to 100 MB for the database user ID "Meier":

ALTER USER Meier TEMPORARY TABLESPACE Temp QUOTA 100M ON Temp;

With the following command, a profile called "Tester" is created that limits the total number of sessions, the maximum CPU utilisation per session, the maximum database connection time, and the maximum idle time (IDLE). This profile can then be assigned to individual users.

CREATE PROFILE Tester LIMIT

An Ingres database allows setting of limits for users and user groups for the maximum input and output per query or the maximum number of records per query, for example.

Furthermore, the number of users allowed to simultaneously access the database can also be restricted. Depending on the licence model, limiting the number of simultaneous accesses by setting certain parameters in the DBMS may also ensure under some circumstances that the maximum available number of licences for the database software is not exceeded.

In addition, numerous users accessing the database in parallel place a high workload on the database server and may exceed its capacity. As a result, the average transaction time increases. If expanding the resources of the database system is impossible or not desired in this case, limiting the maximum possible number of parallel users accesses may also help in this regard.

On the other hand, limiting the maximum possible number of parallel user accesses may also significantly reduce the performance available to the users. For this reason, this functionality should only be used after closer examination or only temporarily, for example during peak times.

If the number of database users increases and it is foreseeable that the current resources will not be able to meet future requirements regarding performance or that more licences will be needed, a corresponding extension of the database should be considered and planned.

The foreseeable future requirements should already be specified when selecting the standard database software so that a concept for the implementation of resource restrictions can be drawn up, if necessary (see S 2.124 Selection of suitable database software).

Review questions:

© Federal Office for Information Security. All rights reserved.