RBAC + : PROTECTING WEB DATABASES WITH ACCESS CONTROL MECHANISM

With the wide adoption of Internet, security of web database is a key issue. In web-based applications, due to the use of n-tier architecture, the database server has no knowledge of the web application user and hence all authorization decisions are based upon execution of specific web application. Application server has full access privileges to delegate to the end user based upon the user requirement. The identity of the end user is hidden , subsequently database server fails to assign proper authorizations to the end user. Hence, current approaches to access control on databases do not fit for web databases because they are mostly based on individual user identities. To fill this security gap, the definition of application aware access control system is needed. In this paper, RBAC+ Model, an extension of NIST RBAC provides a application aware access control system to prevent attacks with the notion of application, application profile and sub-application session.


INTRODUCTION
Web applications are extremely popular today, due to the simplicity of web brower and convenience of using web brower as a end user. The web applications have direct access to back end, called web databases, which contain sensitive and personal information of the end user. This information, if compromised can have a very serious impact on the organizations that deploy them and on the users who access them Thus, protecting data stored in web databases has become a strong need. Access control and views are primary means of attack prevention for databases. In case of web databases it is useless, because of the three or n-tier architecture, where real user's identity is hidden. So proper authorization cannot take place. In three tiers, all the requests are send by application server to the database server, so to fulfill the request, application server has given full privileges and the principle of minimal privilege is violated. It is impossible to authorized web application users with proper privileges at database level. Attackers can exploit these flaws to view sensitive data. Proper access control policies can not be implemented for databases. Therefore, web applications are exposed to many illegal access and attacks that are very hard to prevent and detect. Besides the famous SQL injection attacks there is one more kind of attack ,the Business Logic Violation attack for which satisfactory solutions are still lacking.
The central idea of RBAC + is including the concepts of application, application profile and sub-application session when controlling the access to web databases. The application profile is necessary to track the user behavior throughout a whole session and mainly to prevent business logic violation attacks by enforcing access control.RBAC + focuses on detection and prevention of malicious transactions by continuously monitoring the sequence of SQL statements issued by users. It monitors the malicious transactions and if identified cancels the transactions before it succeeds thus minimize the damage [1].

RELATED WORK
The problem of access control to database accessible over the web is very important. This problem is known to web developers and security specialist. But little work has addressed it. Web databases are vulnerable to attacks like SQL injection, business logic violation and insider attack.Roichman and E.Gudes in [2] proposed a parameterized view with built-in access control mechanism to work with web applications to prevent intrusions. In this method, parameter is used to transfer the identity of user working with databases. So the requirement for this is the parameter should be difficulty to fake. One way to protect web databases from attack like SQL injection is to use ad-hoc tools which are used to detect the attack [3]. Another way is to use Intrusion Detection System (IDS) [4], [5].IDS is a good solution for detecting anomalous behaviors and thus play an important role in database security. IDS can not be used with proper internal access control and views to restrict the data access of web database.IDS focus on detecting attacks after the intruder has accessed the database. Another problem with IDS is that the detection phase of IDS contains the normal activities for anomaly detection purpose, which is only a subset of normal activities since the transaction learning depends on the utilization profile of the database. In many applications some transactions are performed only fort-night or at the end of the month. There is a coverage problem since it contains only frequently executed transactions. This gives false positives of anomaly detection based IDS.
One solution to this problem is to profile user behavior based on application logic. In web system, application interfaces are provided according to the business logic. This way it is possible to profile application features and reduced the risk of false alarm. By strengthening access control and continuously monitoring users, we can stopped many attacks from the access control stage.IDS can

RBAC MODEL
Role-Based Access Control (RBAC) is used for controlling access to computer resources. In RBAC, roles are created based on job functions of users. Permissions are assigned to roles based on the requirements of job functions. Users are made members of roles based on the job responsibilities and thereby gaining permissions assigned to the roles. This way in RBAC, users are granted permissions based on their roles, not on individual basis. This abstraction provided by role simplifies the management of permissions and thus helps to implement the principle of least privilege.

Fig 1 Core RBAC [1]
Core RBAC model is shown in figure 1 with following components.
The sets of USERS, ROLES, PRMS and SESSIONS represent the set of users, roles, permissions, sessions respectively. UA ⊆ Users x ROLES .The user-assignment relation that assign users to roles.

OVERVIEW OF THE APPROACH
In web system, access to data occurs through several layers, starting with end users, web server, application server and then databases. It is difficult to grant permissions to the user since end users identity is hidden. All the requests of end users are submit ted by application server. Another problem is single user's transactions can not be trace to seek signs of anomalous behavior. The solution to these problems is RBAC + , an extension of NIST RBAC, able to detect malicious transaction and stop the attack before it succeeds.
Assuming that the database management system (DBMS) has an RBAC model in place, the concept of the approach is as follows. Here application profile represents, an execution path, a sequence of SQL queries for the execution of a task.
Necessary permissions are given to the application for execution and set of roles are authorized to database users(DBU),for each pair of(application,DBU) the subset of roles are activated in a user's session, called sub-application session. A sub-application session contains only permissions needed to execute a created task and take advantage of RBAC asset such as least privilege and separation of duty. A sub-application session allows DBMS to distinguish between web users working with database, thus solving the first major problem of fine grained authorization at the database level. It will also allow distinguish the requests of different web users having same database session, thus solving second problem of user's session traceability for web applications.
When user logs in, the SQL queries that he submits are associated with database session, an application and the database user that issued them. All the queries of a sub-application session must match an application execution path else access is denied because the transaction is considered as malicious and rolled back. Privileges are limited only to legitimate actions. The important of this solution is that it enforces access control based on business application logic rather than primitive reads and writes. A users can access and manipulate data depends on the application function they execute. This drastically reducing attack like business logic violation attack. Take example of online shopping application. The process involves following stages: 1) Browse the product list and add it ems to the basket.2) Finalize the order.3) Submit credit card details.4) Enter delivery information.
When an employee wants to attack enterprise resources, and if he submits SQL injection attack.SQL injection is entirely fail or at least its effect is very limited because the user's database privileges are limited to legal actions only.

Users
Each user is aassociated with a set of applications .Given set of users, the following relations are defined: AA ⊆ APPS x USERS, a many to many mapping of application to user assignment relation.

BUILDING APPLICATION PROFILE
In database environment, transactions are fixed till the application is not change. For example, in an online banking application, users can only perform the operation like withdraw money and check balance. No other operations are allowed to the end users. An application profile is nothing but a sequence of DML operations related to each other in terms of business logic. Build the application profiles and use it for access control. The application profiles can be build by using following three ways: Manual profiling can be used to build application profile if the transaction is not large.
Running application test. By using testing tools can generate all application functionalities.
By analyzing code of application program can generate application profile. Because application interacts with databases using DML commands. Example: Consider a web application of brokerage firm having following roles: Guest users can go through security details and can read market news.
Customers can submit trade request on her account.
Brokers can submit trades to the market on behalf of customers.
Newsman can update news of the market.
Markets a group of users can actually submit the transaction and updates the status of the transaction.
Each role has different permissions at database levels: Newsman has insert permission on News

ACCESS CONTROL
The session roles are the roles that are assign to the user of the session. So the application has set of roles that the database user is authorized for. A user session contains many sessions belonging to the same or different applications. If it is of same application then the roles assigned to user is same as that of application and if it belongs to different application then needs to activate subset of roles.
To enable the roles, PAA function accepts as a input the set of roles assigned to users and permissions covering the application profiles of an application and tries to find out optimal set of roles covering application profiles permission and all role constraints within the system. To activate set of roles in a session covering requested permissions, satisfying role constraints that prevent activation of conflicting roles in a session and following principal of least privileges a Role Mapping algorithm is given which is inspired by [6].In order to improve the performance, roles with extra permissions than requested permissions are removed in the beginning of the search.

Access Control Policies
Application profiles are used to detect the unauthorized SQL statements. which are considered as invalid based on the application logic. The authorization control function is defined as follows: An access request ar is a tuple ar = < U.is, app, p, o> Є USERS x SASES x APPS x OPS x OBJ [1].ar can be satisfied if (p, o) Є avail_app_prms(s, a) and is Є session_sas(s).The above function is repeated as many permissions as the SQL query requires permissions to be executed. To protect the information stored in databases which are accessed by web users, the access control policies must be flexible enough. Two access control policies can be used.

Policy 1
This policy monitors all transactions of a user. If a transaction is a new transaction, tool searches all the application profiles starting with first requested command of the newly entered transaction. If the application profile starting with requested command is found, it will be considered as candidate application profile. The next command is matched with the command in candidate profile. This process is repeated till the end of the transaction. If no candidate profile is found for the transaction, it is considered as malici ous transaction and rolled back.

Policy 2
Under this policy, all the SQL statements submitted by the user are stored as user context. Access is granted to the user unti l she submits critical point. Here critical point is SQL statements which change the state of the database i.e. (insert, delete, update)

CONCLUSION
RBAC + , an extension of RBAC model, suggests access control mechanisms for RBAC implemented web databases. This model not only detects the attacks but also stop the attacks when they are detected and thus minimized the losses caused by the attacks. Access control policies can be implemented by using PL/SQL language. The primary requirement for this approach is the source code of web application to build application profile. The defense-in-depth technique means the multilayer system, can be implemented. In this, first layer and second layer are used to prevent and detect the attacks respectively.