Common mistakes in two-tier applications

Paladion
By Paladion

June 15, 2007

In previous articles, we have talked about some of the attack techniques and defenses that are possible with two-tier applications. An important thing to note in two-tier applications is that a thick-client application running on the user’s machine directly connects to the database. This means that local machine can directly connect to the database. In this article, we look at some of the common mistakes made in configuring and developing two-tier applications which can render the database vulnerable to attacks from users.

In previous articles, we have talked about some of the attack techniques and defenses that are possible with two-tier applications. An important thing to note in two-tier applications is that a thick-client application running on the user’s machine directly connects to the database. This means that local machine can directly connect to the database. In this article, we look at some of the common mistakes made in configuring and developing two-tier applications which can render the database vulnerable to attacks from users.

Application performs all validations at the client tier

Traditionally all two-tier applications have been developed in this way, with the business logic and input validations done on the client tier. This was to leverage the advantage of having most of the processing done on the client side and using the database tier to only store data and thus reduce the load on the server. However, with the presence to TCP packet editing tools this strategy poses serious security risk. In effect the packet intercepting tools can help an attacker to bypass all the validations built into the client tier.

For example, Some applications even verify the authentication credentials on the client tier. They retrieve hashed passwords from the database, hash the password provided by the user on the client tier and then compare the two passwords. This implies that the stored hashed password is sent to the client. An attacker using a packet intercepting tool can get hold of the hashed password of valid users.

Application lacks session management features

Many two-tier applications fail to identify each user uniquely by a session token i.e. they lack session management features. Some use usernames as session tokens to identify users across forms.

The way in which many two-tier applications function is that, once a user is successfully authenticated the application checks the username in the database to retrieve menus or forms accessible to the particular user. This means that an attacker can login using his loginID (say L) and get access to a higher privileged application user (say H) by modifying the username parameter (to H) that is used to retrieve menus or forms, using packet editing tools.

Application uses high privileges on the database

A database can have many applications connecting to it to access data. In such a scenario data belonging to one application should not be leaked or compromised by another application accessing the database. In many cases, the application connects to the database using a user that has high privileges in the database. If this database user is compromised due to vulnerabilities in the application an adversary can cause damage to all other applications accessing the database. Sometimes applications connect to the database using a user that has system level privileges (example DBA role in Oracle or “sa” in MSSQL). In such a case a remote adversary may to get system level access on the database by exploiting vulnerabilities within the application.

Application Hard-Codes database credentials

Hard-coding of credentials as strings into programs in the application is a commonly seen mistake across all applications. In case of two-tier applications since the Thick Client executable usually lies on the local machine anyone can decompile the executable or even open the executable file itself in a Text editor to view the hard coded credentials.

Default users available at the database

A default installation of a DBMS software comes with default user credentials to access sample databases. Some of these user credentials provide high privileged access to the database. In a two-tier architecture where the database can be accessed directly from the client this can be disastrous. As any user with knowledge of the default credentials can compromise the database. For Oracle DBMS the following default user accounts have high level privileges configured – MTSSYS, CTXSYS, ORDSYS etc. For MSSQL DBMS the “sa” is configured with no or default password.

Remedies

  1. Perform authentication and validate business logic at the database tier. This can be achieved using stored procedures at the database tier. Send all data from client as input parameters to respective stored procedures at the database which perform authentication and implement business logic.
  2. Use random and unique tokens to identify users after authentication. Pass these tokens as parameters to stored procedures that perform the business logic validation. Maintain a mapping of these tokens to usernames in the database, also provide Logout functionality to invalidate this mapping. Following basic actions can be performed by all stored procedures after authentication
  3. Check Login Status of user
  4. Validate Input data
  5. Check compliance to business rules
  6. In addition to the above, use low privilege database user to connect to the database. The database user should have access only to the data required by the application by way of execute privileges on the stored procedures. This will prevent the application from direct access to application tables and views.
  7. Store the database user credentials encrypted and create the connections string at runtime. Use standard cryptographic algorithms for encrypting the credentials.
  8. Change the passwords of the default users immediately on installation of database. Disable or remove access to sample databases.

Based on the remedies listed above we look at a possible secure architecture for two-tier applications:

Secure two-tier architecture
A secure architecture for two-tier applications

Tags: Technical

About

Paladion