Thick Client Application Security - Defenses

By Paladion

May 15, 2006

In the first article in this series, we saw the various attacks on two-tier thick client applications. This part will discuss about the defense mechanisms available to tackle those attacks.

In the first article in this series, we saw the various attacks on two-tier thick client applications. This part will discuss about the defense mechanisms available to tackle those attacks. The defense should be built at the server side to ensure inability of the attacker to bypass the controls.

Several layers of security can be built on top of the database. This article primarily focuses on use of encryption and stored procedures at the database level. While the use of encryption techniques prevents eavesdropping and interception of the traffic at the network level, the use of stored procedures protects against attacks involving tampering of data sent to the server.

First Layer of Defense (Encryption)

When encryption is used, the traffic between the database driver and the database server is encrypted. This makes it difficult for the attackers to intercept the data in transit, thereby preventing successful execution of several attacks such as injection based attacks on two-tier thick client applications.

The two most used encryption techniques are Internet Protocol Security (IPSEC) and Secure Socket Layer (SSL). Many of the latest versions of the databases support both types of encryption techniques. While IPSEC encryption works on the network layer, SSL encryption works at the transport layer leading to an easier implementation. Currently, SSL encryption is the more popular one due to its ease of implementation. Let us see a few examples of using SSL encryption on popular databases.

The SSL Handshake

When a client (database driver) initiates a connection to the server over SSL, an SSL handshake occurs between the client and server. During this handshake, both the client and the server agree upon a specific cipher suite that specifies the encryption algorithm to be used. Then the server authenticates itself to the client by providing its certificate signed by a trusted CA. Later, both the client and server generate a session key and exchange it using a public key cryptography. Any further communication happens in an encrypted form.

SSL Encryption in MS SQL

Here, we consider SQL Server 2000 for the discussion. SQL Server uses Tabular Data Stream (TDS) packets for exchanging commands with its client counterparts. These TDS packets are handled by Net Library protocols, which enable communication between the SQL Server and its clients over a network. In SQL Server 2000, these Net Libraries can be configured using SQL Server Network Utility for Secure Socket Layer encryption that uses a SuperSocket Net Library, which aids other Net Libraries.

SSL encryption can be implemented between SQL Server 2000 and its clients by obtaining a certificate from an appropriate Certificate Authority and installing it on the server. Then all the clients need to be configured to trust the issuing CA. Finally, the protocol encryption has to be forced using the Server Network Utility. A detailed description of Net Libraries and implementing SSL over them is available here.

SSL Encryption in Oracle

Oracle database uses various features of the Oracle Advanced Security option to provide security to the enterprise networks. The SSL feature of the Oracle Advanced Security option enables a secure communication between Oracle Database server and client by encrypting the traffic. In addition, it also provides authentication of server or client or both. This SSL functionality can also be combined with other authentication methods supported by Oracle Advanced Security, thereby using the SSL encryption feature alone.

Securing Oracle Network Traffic

Oracle provides a platform independent networking infrastructure for accessing databases, which is called Net8. This Net8 product with the Oracle Advanced Security option has a feature to use Secure Shell (SSH) protocol to secure the traffic between the client and the server. Though this mechanism protects against eavesdropping, it does not protect against the attacks discussed in the previous article as the database server and database driver are separated from the SSH tunnel.

Second Layer of Defense (Stored Procedures)

A stored procedure is a precompiled sequence of Transact-SQL commands in the database that are executed by calling the procedure within another SQL command or from the database driver. It also significantly reduces the amount of data being transmitted between the database server and the web server.

User defined stored procedures can be used to perform several activities at the database such as authentication and authorization checks.A stored procedure can also be used to manage user sessions by using authentication tokens. The following diagram explains how a stored procedure can be used for authentication and authorization purposes.

In the above diagram, UDSP_Login is the stored procedure used to perform authentication checks and UDSP_Execute is the stored procedure used to perform authorization checks.

Authentication checks

When a user submits the login credentials, the application sends it to the database in an SQL query. The SQL query calls the stored procedure UDSP_Login, which verifies the credentials and if correct returns a randomly created token. The database server responds with AUTHENTICATION SUCCESS along with the token. This token is mapped with the username used for login in a database table and is used as a Session ID in a web application. Incase the authentication fails, the database returns only an AUTHENTICATION FAILURE message. This protects the application from various authentication attacks.

Authorization checks

After the user has logged in to the application, all transaction/execution requests contains the token created at the time of authentication. The SQL query request calls the UDSP_Execute stored procedure, which validates the request by using the token to identify the user mapped to the token and the rights assigned to that user. This protects the application against unauthorized access and privilege escalation attacks.

Other implications

Use of stored procedures also has several other security implications. By using stored procedures, a user can be restricted to access only specific rows and columns of a database table. This enables effective management of user permissions across all the database tables. This database journal article on SQL Stored Procedures discusses the implications of using them. A fundamental understanding of creation and execution of stored procedures can be obtained here.

Additional Layer of Defense (Database Security Patches)

Database vendors release periodic security patches to fix several software bugs in the database left open during development of the particular version. These patches should be installed on the database servers as and when they are available. This reduces the chances of the database being exploited through known vulnerabilities. Vendors have their own periodicity and distribution mechanism for security patches. Oracle uses its Security Technology Center to announce Security Alerts and Patches.

There is an article series published in the database journal that explains the importance and installation procedures for database patches. One of the articles, describes an SQL Injection error in the Oracle database and the patch released to fix the error. Similarly, several patches address certain specific errors that may lead to compromise of the database through different applications used to access the database. Hence, it is essential to establish several layers of security on the database to ensure it is safe and secure from attacks.

Tags: Best Practices