This document proposes an extension to the Role-Based Access Control (RBAC) model called RBAC+ to provide dynamic access control for web-based databases. RBAC+ adds the concepts of application, application profile, and sub-application session to RBAC in order to track users throughout an entire session. This allows RBAC+ to detect and prevent malicious transactions by monitoring the SQL statements within a user's session based on the expected application profile. RBAC+ aims to enhance database security by cancelling malicious transactions before they can succeed.

1. 2010 Fourth International Conference on Emerging Security Information, Systems and Technologies
RBAC + : Dynamic Access Control for RBAC-administered web-based Databases
Ahlem BOUCHAHDA Nhan LE THANH Adel BOUHOULA Faten LABBENE
I3S Laboratory I3S Laboratory Digital security research unit Digital security research unit
Nice-Sophia Antipolis Nice-Sophia Antipolis Sup’Com of Tunis Sup’Com of Tunis
University University Tunis, Tunisia Tunis, Tunisia
Nice, France Nice, France adel.bouhoula@supcom.rnu.tn faten.labbene@supcom.rnu.tn
bouchahd@i3s.unice.fr n-lethanh@i3s.unice.fr
Abstract—In a clear contrast with the phenomenal growth of and prevention of malicious transactions by continuously
Web database applications, access control issues related to data monitoring the sequence of SQL (Structured Query Lan-
stored in the back-end databases have largely been neglected. guage) statements submitted by users. Malicious transactions
Current approaches to access control on databases do not fit
web databases because they are mostly based on individual are transactions that access database without authorization,
user identities. In this paper, we propose (RBAC + ), a dynamic or transactions that are submitted by users who are au-
access control model to enforce fine-grained access control thorized but abuse their privileges. The RBAC + monitors
to web databases. It extends the Role-Based Access Control transactions issued by users and malicious transactions are
model standard with the notions of application, application viewed as intrusion behaviors. If a malicious transaction
profile and sub-application session. The proposed dynamic
access control model enhances the ability of detecting malicious is identified, the RBAC + cancels the transaction before
transactions, the dominant cause that demolishes database it succeeds, thus minimize damage caused by malicious
system, by tracking application users throughout a whole transactions.
session. Hence, attacks caused by malicious transactions can We track users at the session level, so we are able to
be detected and canceled timely before they succeed. prevent attacks such as the business logic violation, which
Keywords-security, database, RBAC, application profile. cannot be seen at the statement/transaction level, as their
effect accumulates during an entire session.
I. I NTRODUCTION The rest of the paper is organized as follows. We present
Traditional identity-based mechanisms for performing ac- the related work in Section 2. In Section 3, we define
cess control are useless for web databases (DBs). Further, formally and detail our model. The operation of the model
a DataBase Management System (DBMS) can not handle is illustrated using a sample application scenario in Section
users who access it indirectly via the application server, 4. We conclude our work and present future work in Section
no user-based access control can be applied since the only 5.
recognized user is the user of the application server and for
most of the web applications it is the user with very high II. R ELATED W ORK
privileges. Databases can no longer differentiate between The problem of access control to databases accessible over
transactions of different application users. The principle of the web is very important one. This problem is well known
minimal privilege is violated. It is impossible to authorize to the web application developers and security consultants,
the web application user with appropriate privileges at the but little existing work has addressed it. Gertz et al. in
database level: all application users have access to the same [2] pose this problem and presented some fundamental
data. Restrictions on what authenticated users are allowed concepts and techniques that help administrators and security
to do are not properly enforced. Attackers can exploit these personnel to gradually evaluate and improve the security of a
flaws to view sensitive data, or use unauthorized functions. database. Also, Roichman in [3] proposed a method that uses
So, no more fine-grained access control to the database exists the databases’ built-in access control mechanisms enhanced
and authorization can be provided only at the application with Parameterized Views and adapts them to work with
level. web applications in order to prevent intrusions. Beyond these
Hence, an access control model with application aware- two approaches, to protect web databases from attacks of
ness is needed since application is the missing piece in the malicious users, two main approaches exist. The first consist
access control process. In this paper, we suggest an access on using ad hoc tools specifically oriented to the detection of
control model that we call RBAC + . This model extends specific kinds of attacks like SQL injection [4]. The second
the RBAC model (Role-Based Access Control Model) [1] consists on using Intrusion Detection Systems (IDSs).
with the concepts of application, application profile and Although we believe that database IDSs can perform very
sub-application session. Our approach focuses on detection well in detecting anomalous behaviors and that IDS should
978-0-7695-4095-5/10 $26.00 © 2010 IEEE 135
124
DOI 10.1109/SECURWARE.2010.44
10.1109/SECURWARE.2010.30

2. play an important role in database security, we have to point
out that the web application’s access to databases remains
untraceable. Further, an IDS can not overcome the absence
of web database internal access control and the uselessness
of views as a means of access restriction. Moreover, with the
assumption that the attack does not go unnoticed, IDSs focus
on detecting attacks after the malicious user has accessed the
DB with all the damage it could cause. However, it is not
always the case because IDSs, in practice, when profiling
normal activities for anomaly detection purposes, it is only
a subset of normal activities, which is profiled since the
Figure 1. Core RBAC
transactions learning depends on the utilization profile of the
database. In many cases, large database applications include
functionalities that are only executed from time to time, for
example at the end of the week or end of the month. Thus, The central idea of RBAC + is extending RBAC by
we have a coverage problem since only frequently used including the concepts of application, application profile
functionalities, which are profiled, which explains in part and sub-application session when controlling the access to
the high rate of false positives of anomaly-based intrusion web databases. The application profile is necessary to track
detection. the user behavior throughout a whole session and mainly
to prevent business logic violation attacks from the access
Our solution to this problem is to profile user behavior
control phase.
based on the application logic. In fact, each application
have a way of working to accomplish its features following Such attacks compromise the business logic and can be
ordered actions. Besides, in a typical web environment, seen only at the session level. Databases cannot prevent
transactions are programmed at the application level , which them because the existing database access control can grant
means that the set of transactions remains stable, as long as or revoke access to resources only according to the ac-
the application is not changed. For example, in a banking cessor identity/role. It cannot rely on the business logic
database application users can only perform the operations of an organization. Thus the database’s access control is
available at the application interface (e.g., withdraw money, useless in such a case and business logic violations remain
balance check account, etc). No other operation is available unprevented. Consequently, the access control system must
for the end-users (e.g., end-users cannot execute ad-hoc SQL learn the business logic of the web application, which is
commands). This way, it is possible to profile application represented by the application profiles and any user session
features and thus reduced risk of false alarms. must correspond to one application profile, else it can be
considered as intrusive.
What we propose is strengthening access control and
continuously monitor users. It is dynamic because our model The complete set of application profiles gives all the
adjusts dynamically Role Assignments to end user based on possible execution paths (sequences of selects, inserts, up-
the application he executes and the DataBase User (DBU) dates, and deletes) of database interactions. Each application
that connects on behalf of him. Our approach is similar, profile consists of a sequence of SQL statements that are
in part, to usage control (UCON) [5] since it enables the related to each other in terms of the business application
continuity of an access decision. As a result, the majority logic. Each statement represents a specific unit of work that
of attacks can be stopped from the access control stage and the application needs to do in order to execute its function.
the IDS will be used to detect attacks that have escaped the We, now, introduce a rigorous definition of the model.
access control stage. Intrusion detection without enforcing The purpose is to provide a comprehensive definition of the
access control is not as efficient and effective. IDS is a components, thus including all the aspects of the model.
complement but can not, alone, protect DB from attacks.
B. Application Profile
+
III. T HE RBAC C ORE M ODEL An application profile is a sequence of nodes such that
We begin this section by a brief review of the RBAC from each of its nodes there is an edge to the next node in the
model before presenting in more detail our RBAC + model. sequence. It has one start node and one end node where the
application execution starts and finishes, respectively. The
A. Role-Based Access Control Model Overview other nodes in the path are called internal nodes. Each node
represents an SQL statement.
Core RBAC, as shown in Figure 1, consists of the Application profiles are built beforehand by analyzing the
sets USERS, ROLES, PRMS and SESSIONS that represent application code. In fact, a program in a web application
respectively the set of users, roles, permissions and sessions. normally interacts with database through statements, which
136
125

3. • AP perms : AP → 2P RM S , the mapping of an
application profile onto a set of permissions. Formally,
AP perms(ap) = {p ∈ P RM S|(p, ap) ∈ P AA}.
• RAA ⊆ ROLES × AP P , a many-to-many mapping
Role-to-Application Assignment relation.
• AP P roles : AP P → ROLES, the map-
ping of an application to a set of roles. Formally,
AP P roles(app) = {r ∈ ROLES|(r, app) ∈ RAA}.
• avail session perms(s : SESSION S) → 2P RM S ,
the permissions available to a user in a session =
r∈session roles(s) assigned permissions(r)
• session(si ) = {asij |j = 1, 2, ...n} as stands for
Application Session. A session is composed of many
Figure 2. Core RBAC + application sessions.
E. Users
Each DBU is associated with a set of applications. More
execute the SQL data manipulation language (DML) opera-
formally, we define:
tions such as select, insert, update or delete.
• AA ⊆ AP P S × U SERS, a many-to-many mapping
The application profile (AP) is a binary vector with the
length is equal to the number of permissions in the DBMS, application-to-user assignment relation.
AP P S
• U SER AssignedApps : U SERS → 2 , the
where the ith bit is 1 if AP needs the permission pi to be
executed, else bit i is 0. pi ∈ P RM S. We also define : mapping of a user to a set of applications. Formally,
U SER AssignedApps(u) =
• AAP : AP P → AP , the mapping of an application
{u ∈ U SERS|(app, u) ∈ AA}.
onto its corresponding application profiles. Formally,
AP P prof iles(app) = F. Sessions
{ap ∈ AP |(ap, app) ∈ AAP }. When a user logs in, a new session is activated and a
• RAP ⊆ ROLES × AP , a many-to-many mapping number of roles are selected to be included in the session
Role-to-Application profile Assignment relation. role set. Formally, we define:
• AP roles : AP → ROLES, the mapping of an • session user: SESSION S → U SERS, the mapping
application profile to a set of roles. Formally, from a session s to the user of s.
AP roles(ap) = {r ∈ ROLES|(r, ap) ∈ RAP }. • session roles : SESSION S → 2ROLES ,
the mapping of session s onto a set of
C. Sub-application session roles. Formally: session roles(s) ⊆ {r ∈
An application session is composed of all the transactions ROLES|(session U ser(s), r) ∈ U A}.
AP P S
that an application runs on behalf of all its users. A sub- • session applications : SESSION S → 2 , the
application session (SASES) is the subset of transactions mapping of session s onto a set of applications.
related to one user. Hence, an application session is com- • avail app roles : (SESSION S, AP P S) →
posed of one or more sub-application sessions. Formally, a 2ROLES , the mapping of a session and an
Sub-application session is defined as: application onto a set of roles. Formally,
• app sas : AP P → 2
SASES
. The mapping of an avail app roles(s, app) ⊆ {r ∈ ROLES|r =
application onto a set of sub-application sessions. session roles(s) ∩ app roles(app)}
• session sas : SESSION S → 2
SASES
. The mapping • avail app prms : (SESSION S, AP P S) →
of a session onto a set of sub-application sessions. 2P RM S , the permissions available to an application in
a session. Formally, avail app prms(s, app) =
D. Permissions r∈avail app roles(s,app) assigned permissions(r).
In our model, permissions are associated with roles and G. Access control mechanism
with application profiles. Applications are then associated 1) Authorization control function: An access request ar
with the appropriate roles based on the set of permissions is a tuple ar = U, is, app, p, o ∈ U SERS × SASES ×
assigned to application profiles. The set of permissions AP P S × OP S × OBJ. ar can be satisfied if (p, o) ∈
PRMS is defined as P RM S = 2(OP S×OBJ) . We also avail app prms(s, a) and is ∈ session sas(s).
define: An sql query is a set of permissions. the above function
• P AA ⊆ P RM S × AP , a many-to-many mapping is repeated as many permissions as the sql query requires
Permission-to-Application profile Assignment relation. permissions to be executed.
137
126

4. 2) Path Control Function: Let qi be an SQL query
submitted to the DBMS and qi−1 the SQL query submitted
just before qi . qi can be satisfied iff next(qi−1 ) = qi . For
any SQL statement submitted, access is granted only if both
authorization control function and path control function are
satisfied.
IV. C ASE STUDY
Assuming that the DBMS has an RBAC model in place,
the key idea of our approach is as follows. We create
application profiles that represent all the possible execu-
tion paths of the application by analyzing the application
code. To illustrate the application profile building phase,
we describe a part of a simple application: Online Course
Management System, a student project written in PHP.
Figure 3 shows the simplified source code of one program in
the application: register course.php. The register course.php
page is displayed after the student logs into the system. The
page displays a form in line 2, where the user can select an
action: “register a new course” or “delete an existing course.
If the option Register a new course is selected, another form
is displayed (line 8). The user can select a course and fill
in the form his/her student ID. The page generates a string
containing an SQL insert query, based on user inputs and
then sends that query to the web server through the statement
mysql query() in line 5, which inserts the student into the
database table for that course. There are three tables namely
software, database, and network, which store the list of
students attending Software Engineering, Database System,
and Computer Networks course, respectively. It also forms
and sends another query (line 6) to insert the student and
the registered course into the registrations table. This table
maintains all the registration records.
138
127

5. < ?
...
1. if ($action == " " )
2. print(" <FORM ACTION=’manage_course.php’>Choose action<P>
<INPUT TYPE=RADIO NAME=’action’VALUE=’Insert’>Register a new course<BR>
<INPUT TYPE=RADIO NAME=’action’VALUE=’Delete’>Delete course<BR>
<INPUT TYPE=SUBMIT VALUE=’submit’></FORM>);
3. if ($action == ’Insert’){
4. if ($course != ‘‘’’ && $studentid != ‘‘’’){
5. mysql_query(‘‘INSERT INTO $course VALUE ’ ’, ’$studentid’’’) ;
6. mysql_query(‘‘INSERT INTO registration VALUES ’$course’,’$studentid’’’);
7. print_html(‘‘Course registered’’);...
}
else
8. print(‘‘<FORM ACTION=’register_course.php’ METHOD=’POST’ ...> <P>
Choose course
<INPUT TYPE=RADIO NAME=’course’VALUE=’software’> Software Engineering<BR>
<INPUT TYPE=RADIO NAME=’course’VALUE=database> Database Systems<BR>
<INPUT TYPE=RADIO NAME=’course’VALUE=’network’> Computer Network<P>
Student ID: <INPUT TYPE=TEXT NAME=’studentid’><BR>
<INPUT TYPE=SUBMIT VALUE=’submit’>
</FORM>’’);
}...
?>
Figure 3. register course.php
139
128

6. From this application code, we can extract three applica- V. C ONCLUSION AND F UTURE W ORK
tion profiles depicted in Figure 4 where node 1 represents In this paper we have presented RBAC + , an extension of
the permission (insert, software), node 2 represents the per- the RBAC model addressing access control requirements for
mission (insert, database), node 3 represents the permission RBAC-administered web databases. We do not only monitor
(insert, network), and node 4 represents the permission DB users to detect potential attacks, but timely stop the
(insert, registration). Given the permissions necessary to attacks when they are detected to minimize losses caused
by the attacks. As future work, we plan to perform proof of
concept and analysis on the model before implementing it.
R EFERENCES
Figure 4. Application profiles [1] “American national standard for information technology, role
based access control. ansi incits 359-2004,” February 2004.
the execution of an application and the set of roles that
the underlying database user (DBU) is authorized for, we [2] M. Gertz and M. Gandhi, Handbook of Database Security,
2007, ch. Security Re-engineering for Databases: Concepts and
calculate for each pair (application, DBU) the subset of Techniques, pp. 267–296.
roles to activate in a web user session, called sub-application
session. It is called so because, in the context of a web [3] A. Roichman, “Intrusion prevention and detection for web
application, a web user session is included in a database databases,” 2008.
session. Hence, an end user associated to a sub-application
[4] W. G. Halfond, J. Viegas, and A. Orso, “A classification
session, can use only the permissions really needed to fulfill of sql-injection attacks and countermeasures,” in Proceedings
exactly the tasks it was created for, and so we take advantage of the IEEE International Symposium on Secure Software
of all RBAC assets such as least privilege and separation Engineering, Arlington, VA, USA, 2006.
of duty that make of it the most widely accepted as the
proven technology for access control. A sub-application [5] J. Park and R. Sandhu, “The U CONABC usage control
model,” ACM Transactions on Information and System Secu-
session allows to the DBMS distinguishing between web rity, vol. 7, no. 1, pp. 128–174, 2004.
users working with the database, thus solving the problem
of fine-grained authorization at the database level. It will
also allow distinguishing between the requests of different
web users that belong to the same database session, thus
solving the problem of user-session’s traceability for web
applications.
When the web user logs in to the application, the SQL
queries that he submits are associated with a database
session, an application and the underlying database user
that issued them. All queries belonging to a sub-application
session must match an application execution path else the
access is denied because the action to be executed is illegit-
imate. Now, when an employee wants to attack enterprise
resources, he, for example, can submit an SQL injection
attack. But because his database privileges are limited only
to legitimate actions, an SQL injection will be entirely
mitigated or at least, its effect is strongly limited.
The importance of our solution is that it enforces access
control based on business application logic rather than
primitive reads and writes. A user’s ability to access and
manipulate data is typically dependent of the application
function the user executes thus reducing drastically attacks
against databases and in particular, business logic violation
attacks because an action may be legitimate on its own but
illegitimate in the context of a whole session. Databases
cannot prevent them because the existing database access
control can grant or revoke access to resources only
according to the accessor identity/role. It cannot rely on the
business logic of an organization.
140
129