Application User Mechansim Overview

The Trusted RUBIX Application User mechanism eliminates many vulnerabilities present in RDBMS applications, such as SQL injection, URL manipulation, and application hijacking. It accomplishes this by extending Mandatory Access Controls (MAC) to the RDBMS application’s users. With other RDBMSs’, security enforcement for this class of user, including authentication and access controls, are typically performed entirely within the RDBMS application. Because RDBMS applications tend to be ad-hoc, custom programs, they do not have the well structured, evaluated security mechanisms typical of RDBMSs’. Additionally, with other RDBMSs’, the existence of application users is unknown to the RDBMS.

The Mandatory Access Control (MAC) over the application users is accomplished by securely binding the application users’ authentication to the RDBMS application’s database session and then using Attribute Based Access Control (ABAC) security policies to restrict access of individual application users down to the row level. In a typical configuration, this would result in application users only being able to access rows which they created. Additionally, the RDBMS user executing the application program would not be able to access any row unless the application user that created the row is currently authenticated.

Using the Trusted RUBIX Application User mechanism, RDBMS application developers can focus on the functionality of the application while relying on the Trusted RUBIX RDBMS to encapsulate and secure the underlying data of the secure transaction based web applications, e.g., Internet Banking. For detailed information on the application user mechanism, please see the Application User Guide.

RDBMS User

A Trusted RUBIX RDBMS User represents a traditional user of the database. The RDBMS User is able to authenticate to the RDBMS, initiate a RDBMS session, and directly submit SQL operations. The Trusted RUBIX RDBMS User space is tightly integrated with the user space of the operating system that hosts the database server software (i.e., the database host platform). Additionally, the RDBMS User is authenticated using the Pluggable Authentication Module of the host platform.

Applications

A Trusted RUBIX Application represents a RDBMS middleware application. It is named and created by the Trusted RUBIX Database Administrator. It also has one or more associated Application Administrators and Application Users. Application Users, typically connecting from the Internet, represent users of the middleware application. Application Administrators are RDBMS Users who are permitted to execute the RDBMS middleware application, connect to the database , and submit SQL operations on behalf of Application Users.

Application Administrators

A Trusted RUBIX Application Administrator is a RDBMS authenticated user that is permitted to execute a particular RDBMS middleware application (e.g., ODBC program), that connects to the database, declares itself to be administering the Application (i.e., using the ALTER SESSION SET APPLICATION command), and submit SQL operations on behalf of Application Users. The Trusted RUBIX Security Administrator assigns RDBMS Users to be the Application Administrators for a particular Application.

Application Users

Application Users represent users of the RDBMS middleware application (i.e., a Trusted RUBIX Application). Typically, they connect to the Application using the Internet. Application Users may only interact with Trusted RUBIX through the single Application with which they are associated. They may not connect directly to the RDBMS. Application Users are associated with the Application when their account is created by the Application Administrator using the create application_user command. Application Users must authenticate to the Trusted RUBIX RDBMS.

Typical Web-Based Architecture

The following diagram shows a typical account-based web application architecture. It consists of several web applications which exist on the Internet. These applications may execute within a web browser (e.g., Internet Explorer) or as a stand-alone Java application. The web application allows application users to access their account (e.g., bank account) using a user name and a password. The web application submits operations (e.g., read bank balance) to the RDBMS middleware application as the user interacts with the web application. From a security perspective, the web application should not be trusted to act properly.

The RDBMS application accepts operations from the web application, converts them into SQL, and submits them to the RDBMS server. The RDBMS application is typically an application custom made for the particular web application being developed. Typically, the RDBMS  application is trusted to authenticate the application user, bind that authentication to the application user’s session, and to ensure that no data is released or modified outside of that allowed for the authenticated application user. The RDBMS application connects to the RDBMS  server as the RDBMS user and is trusted by the RDBMS server to perform any RDBMS operation that may be needed to satisfy any legitimate application user operation for any application user. Therefore, if the RDBMS application is compromised or bypassed, data from all application users is vulnerable.

The RDBMS server accepts operations from the RDBMS application in the form of SQL operations. The RDBMS server has no knowledge of application users. Therefore, a typical RDBMS server may not make any security decisions based upon the current application user.

Example: Use of Application Users in a Web-Based Environment

Next, an example is presented giving a typical, but simplified, use of the Application User mechanism. The example models a simple Internet banking application. The only functionality of the application is to allow a customer to read their current bank balance. The security objective is to utilize the Application User mechanism to permit access to a bank balance only when the corresponding, authenticated banking customer is requesting the balance through the middleware application. The following Figure shows the architecture of the Internet banking solution.

The top of the figure shows four Internet banking customers (i.e., Application Users) and their account numbers, Bob (#1, yellow), Nancy (#2, red), John (#3, green), and Jane (#4, purple). Each customer has a color which represents the Application User’s ABAC permissions in the database. The Application Users connect to the banking application through the Internet.

The banking middleware application (e.g., Apache/PHP/ODBC application) has an Application name of BigBank in the Trusted RUBIX RDBMS. The Application Administrator is the RDBMS User BigBankAdmin. The blue color of the Application represents the ABAC permissions of the RDBMS User (i.e., the Application Administrator, BigBankAdmin) that executes the Application. This RDBMS User will connect to the Trusted RUBIX RDBMS and submit SQL operations on behalf of the Application Users.

Within the Trusted RUBIX database, shown at the bottom of the figure, is the Accounts table, with Account#, Balance, and App User columns. The Accounts table has four rows, one for each customer’s bank account balance. Note that the color of each row corresponds to the color of the corresponding customer. Also note that the App User column is used to label each row with the creating Application User.

To the left of the Accounts table are the ABAC Requirements for each row. The colors shown represent the required permissions to access the row. Note that the color blue is required for each row, indicating that the authenticated RDBMS User BigBankAdmin must submit the SQL operations. Additionally, the permissions of the corresponding Application User is also required for each row. Thus, to access the first row, the permissions of the RDBMS User BigBankAdmin (blue) and the permissions of the Application User Bob (yellow) are required. For the second row, the permissions of the RDBMS User BigBankAdmin (blue) and the permissions of the Application User Nancy (red) are required, etc.

In the figure, Application User Bob has submitted a request to read the balance for account #1. Bob submits the request by submitting the following URL to the web server:

https://BigBank.com/index.php?acount=1

Note that the account=1 component of the URL specifies which bank account balance is being requested. Assume that Bob has previously authenticated to the application and is set as the current Application User in the RDBMS. Following the flow of the operation down from the Application User Bob, the application accepts the operation and translates it into the corresponding SQL operation:

select Balance from Accounts where Account#=1

Because the Application User Bob and RDBMS User BigBankAdmin are authenticated and set in the database session, the SQL operation executes with the permissions of both users. This is reflected by the yellow and blue striped arrows representing the submitted SQL operation. As this matches the permissions required to select the first row in the Accounts table, the SQL operation succeeds. The account balance of $100.54 will be returned to the Application User Bob.

Threats Mitigated by Application Users and ABAC

The Trusted RUBIX Application User mechanism in conjunction with the Attribute Based Access Control/SPM (ABAC) security enforcement mitigate several common security threats to data driven applications.

Threats fall into two broad categories: malicious user input to the RDBMS application and controlling the programming logic of the RDBMS  application (i.e., application hijacking). In the first case, the hacker submits user input to the application that will cause it to execute SQL operations that violate the security requirements. In the second case, the hacker attempts to directly control the programming logic of the application to cause it to execute SQL operations that violate the security requirements. Note that in both cases, the vulnerability exists in typical RDBMSs because the RDBMS middleware application must execute with privileges sufficient to access all database objects necessary to satisfy any potential operation.

The Trusted RUBIX Application User mechanism removes these vulnerabilities by restricting the RDBMS middleware application to permissions sufficient to access only database objects that satisfy the current operation.

Trusted RUBIX Solution

This sections demonstrates how the Trusted RUBIX mandatory security policy on the users of the middleware application prevents a URL modification attack.

The figure below shows the architecture of the Trusted RUBIX solution. It shows a simplified Internet banking application with four users. Each user is color coded to represent the permissions it should have with respect to the application. The middleware application itself is colored blue to show the permissions of the RDBMS User (BigBankAdmin) executing the application.

Below the middleware application is the Trusted RUBIX RDBMS. Note that all rows in the Accounts table are color coded according to its corresponding Application User. The color shows the permissions needed to access each row. In this architecture the RDBMS User of the application may only access a row in the Accounts table if the corresponding Application User is authenticated.

In this figure, a URL modification attack is shown. The Application User Nancy (account #2) has modified her URL to read the account balance for the account owned by Bob (account #1). This was accomplished by modifying Nancy’s URL from

https://BigBank.com/index.php?acount=2

to

https://BigBank.com/index.php?acount=1

When this operation arrives at the middleware application, the program mistakenly does not verify the requested account number (#1) with the Application User requesting it (Nancy). It constructs the SQL command

select Balance from Accounts where Account#=1

and submits it to the RDBMS. Because the ABAC security requirements to access the row for account #1 are for the RDBMS User BigBankAdmin (blue) and Bob (yellow) to be authenticated, the SQL operation fails and the hackers attempts are thwarted.