Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
2010 Fourth International Conference on Emerging Security Information, Systems and Technologies    RBAC + : Dynamic Access...
play an important role in database security, we have to pointout that the web application’s access to databases remainsunt...
•   AP perms : AP → 2P RM S , the mapping of an                                                                           ...
2) Path Control Function: Let qi be an SQL querysubmitted to the DBMS and qi−1 the SQL query submittedjust before qi . qi ...
< ?...1. if ($action == " " )2.    print(" <FORM ACTION=’manage_course.php’>Choose action<P><INPUT TYPE=RADIO NAME=’action...
From this application code, we can extract three applica-                      V. C ONCLUSION AND F UTURE W ORKtion profile...
Upcoming SlideShare
Loading in …5
×

Dynamic Access Control for RBAC-administered web-based Databases

1,147 views

Published on

  • Be the first to comment

Dynamic Access Control for RBAC-administered web-based Databases

  1. 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 should978-0-7695-4095-5/10 $26.00 © 2010 IEEE 135 124DOI 10.1109/SECURWARE.2010.44 10.1109/SECURWARE.2010.30
  2. 2. play an important role in database security, we have to pointout that the web application’s access to databases remainsuntraceable. Further, an IDS can not overcome the absenceof web database internal access control and the uselessnessof views as a means of access restriction. Moreover, with theassumption that the attack does not go unnoticed, IDSs focuson detecting attacks after the malicious user has accessed theDB with all the damage it could cause. However, it is notalways the case because IDSs, in practice, when profilingnormal activities for anomaly detection purposes, it is onlya subset of normal activities, which is profiled since the Figure 1. Core RBACtransactions learning depends on the utilization profile of thedatabase. In many cases, large database applications includefunctionalities that are only executed from time to time, forexample at the end of the week or end of the month. Thus, The central idea of RBAC + is extending RBAC bywe have a coverage problem since only frequently used including the concepts of application, application profilefunctionalities, which are profiled, which explains in part and sub-application session when controlling the access tothe high rate of false positives of anomaly-based intrusion web databases. The application profile is necessary to trackdetection. 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 applicationhave a way of working to accomplish its features following Such attacks compromise the business logic and can beordered actions. Besides, in a typical web environment, seen only at the session level. Databases cannot preventtransactions are programmed at the application level , which them because the existing database access control can grantmeans 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 logicdatabase application users can only perform the operations of an organization. Thus the database’s access control isavailable at the application interface (e.g., withdraw money, useless in such a case and business logic violations remainbalance check account, etc). No other operation is available unprevented. Consequently, the access control system mustfor the end-users (e.g., end-users cannot execute ad-hoc SQL learn the business logic of the web application, which iscommands). This way, it is possible to profile application represented by the application profiles and any user sessionfeatures 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 andcontinuously monitor users. It is dynamic because our model The complete set of application profiles gives all theadjusts 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 applicationthat connects on behalf of him. Our approach is similar, profile consists of a sequence of SQL statements that arein part, to usage control (UCON) [5] since it enables the related to each other in terms of the business applicationcontinuity of an access decision. As a result, the majority logic. Each statement represents a specific unit of work thatof 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 theaccess 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 themodel 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. TheA. 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 thesets USERS, ROLES, PRMS and SESSIONS that represent application code. In fact, a program in a web applicationrespectively the set of users, roles, permissions and sessions. normally interacts with database through statements, which 136 125
  3. 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. Moreexecute 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 thelength is equal to the number of permissions in the DBMS, application-to-user assignment relation. AP P S • U SER AssignedApps : U SERS → 2 , thewhere the ith bit is 1 if AP needs the permission pi to beexecuted, 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 ofC. 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 Sthat an application runs on behalf of all its users. A sub- • session applications : SESSION S → 2 , theapplication 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 anSub-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 mechanismwith application profiles. Applications are then associated 1) Authorization control function: An access request arwith 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. 4. 2) Path Control Function: Let qi be an SQL querysubmitted to the DBMS and qi−1 the SQL query submittedjust before qi . qi can be satisfied iff next(qi−1 ) = qi . Forany SQL statement submitted, access is granted only if bothauthorization control function and path control function aresatisfied. IV. C ASE STUDY Assuming that the DBMS has an RBAC model in place,the key idea of our approach is as follows. We createapplication profiles that represent all the possible execu-tion paths of the application by analyzing the applicationcode. To illustrate the application profile building phase,we describe a part of a simple application: Online CourseManagement System, a student project written in PHP.Figure 3 shows the simplified source code of one program inthe application: register course.php. The register course.phppage is displayed after the student logs into the system. Thepage displays a form in line 2, where the user can select anaction: “register a new course” or “delete an existing course.If the option Register a new course is selected, another formis displayed (line 8). The user can select a course and fillin the form his/her student ID. The page generates a stringcontaining an SQL insert query, based on user inputs andthen sends that query to the web server through the statementmysql query() in line 5, which inserts the student into thedatabase table for that course. There are three tables namelysoftware, database, and network, which store the list ofstudents attending Software Engineering, Database System,and Computer Networks course, respectively. It also formsand sends another query (line 6) to insert the student andthe registered course into the registrations table. This tablemaintains all the registration records. 138 127
  5. 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’’);... } else8. 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. 6. From this application code, we can extract three applica- V. C ONCLUSION AND F UTURE W ORKtion profiles depicted in Figure 4 where node 1 represents In this paper we have presented RBAC + , an extension ofthe permission (insert, software), node 2 represents the per- the RBAC model addressing access control requirements formission (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 thatthe 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 andcalculate for each pair (application, DBU) the subset of Techniques, pp. 267–296.roles to activate in a web user session, called sub-applicationsession. It is called so because, in the context of a web [3] A. Roichman, “Intrusion prevention and detection for webapplication, 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 classificationsession, can use only the permissions really needed to fulfill of sql-injection attacks and countermeasures,” in Proceedingsexactly the tasks it was created for, and so we take advantage of the IEEE International Symposium on Secure Softwareof 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 theproven 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 problemof fine-grained authorization at the database level. It willalso allow distinguishing between the requests of differentweb users that belong to the same database session, thussolving the problem of user-session’s traceability for webapplications. When the web user logs in to the application, the SQLqueries that he submits are associated with a databasesession, an application and the underlying database userthat issued them. All queries belonging to a sub-applicationsession must match an application execution path else theaccess is denied because the action to be executed is illegit-imate. Now, when an employee wants to attack enterpriseresources, he, for example, can submit an SQL injectionattack. But because his database privileges are limited onlyto legitimate actions, an SQL injection will be entirelymitigated or at least, its effect is strongly limited. The importance of our solution is that it enforces accesscontrol based on business application logic rather thanprimitive reads and writes. A user’s ability to access andmanipulate data is typically dependent of the applicationfunction the user executes thus reducing drastically attacksagainst databases and in particular, business logic violationattacks because an action may be legitimate on its own butillegitimate in the context of a whole session. Databasescannot prevent them because the existing database accesscontrol can grant or revoke access to resources onlyaccording to the accessor identity/role. It cannot rely on thebusiness logic of an organization. 140 129

×