Web application access Control

Http://secappdev.org/handouts/2012/Jim%20Manico%20%26%20%20Eoin%20Keary/Final%20-%20Access%20Control%20Module%20v4.1.pdf

What is Access control/authorization?

Authorization is the process where a system determines if a specific user have access to a particular resource.

There are several keywords in the definition above: process, specific user, particular resource

The purpose of the authorization is ensure, user only, access system functionality to which and he is entitled. Which means that the user has the right to grant him access to resources

There are users of the site has access control requirements, traditionally based on RBAC (Role based access control) can achieve extensive access controls, but RBAC also has a very obvious problem: the control granularity is too large to dynamically control a resource to achieve, or can access, There is no access, and in many cases it is possible to read access to some of the resources and read and write the resources that you create, in which case RBAC is powerless. In general, RBAC does not solve the problem of horizontal access control (horizontal access controls)

Malicious attacks on access control

1. Vertical Access Control attacks

A low-privileged user accesses the high-privilege feature (a standard user accessing administration functionality)

2. Horizontal access Control attacks

Users of the same role go to access other users ' private data (same role, but accessing another user's private)

3. Business logic Access control attacks

Abuse of workflow

Issues of access control

1. Requires application only one "all or nother" approach is implemented: Once authenticated then all users have the same permissions

2. Authorization logic usually relies on the default environment to be secure and assumes that the user will not find unlinked functionality or hidden path/functionality, The user will not find and tamper with the hidden client parameters (e.g. hidden form filed, cookies, etc.)

3. Once there are multiple permission level/roles in the application, this will always increase the permissions conflict between the permission set, which may make the permission system work in disorder.

Typical implementation practice of poor authority control

1. hard-coded role Check in application code

void   Editprofile (User u, edituser eu) {   if (U.ismanager ()) {edituser (EU)     

Question: What needs to occur in order to change the access control policy of this feature?

A. Making it very difficult to prove that we have implemented an authorization strategy for the application

B. Any time the access control policy policies need to be changed, the code must be modified

C. Vulnerability and ease of making mistakes

D. Automation is not possible and needs to be done on every application feature hand-coded

2. Lack of centralized access control logic

Consider the following decentralized parameter control:

http://example.com/buy?action=chooseDataPackagehttp://example.com/buy?action=customizePackagehttp:// Example.com/buy?action=makepaymenthttp://example.com/buy?action=downloaddata An attacker can obtain an undue permission through concurrency

3. Non-trusted data drives access control decisions

A. Never trust data from the client to make access control decisions

B. Never make access control decisions in JavaScript

C. Never make access control decisions based solely on the following information:

C.1:hidden fields

C.2:cookie value

C.3:form parameters

C.4:url parameters

D. Never rely on the order in which the client sends over the parameter values to make the decision

4. Access control follows the "open by default" principle, which opens unnecessary permissions

Many administrative interfaces only need a password to authorize. Sharing accounts and lack of auditing and logging can make it very difficult to distinguish between good people and bad guys. Admin interface is often less secure than user-level interface because it's always assumed that administrators is a trusted user

5. Lack of standard methods to address horizontal access control

6. The Access contro logic must be manually added to each of the Endpoin

Attack access control system

1. Elevation of privileges

2. Disclosure of sensitive information: for example, Admin-level accounts often have access to a user's private information

3. Data tampering: Privilege levels tend to not differentiate between users who can view data and data that can be modified by users

Testing for broken access control

Try to access Admin components/functions as an anonymous user or as an ordinary user: Modify the HTML hidden form fields, test the Web accessible directory structure for Names, such as Admin,administrator,manager, and so on: direct access to restricted resources

Try to find out how administrator was authenticated. We need to ensure that sufficient authentication channels are used, even with a regular password plus a temporary password for the registered phone to verify

For each user role, you need to make sure that the appropriate pages or components can be accessed by that role

Access Control Best Practices:

1. Use role based access control to assign permissions to the user to implement vertical access control requirements;

2. Use Data-contextual access control to authorize specific users in the context of a specific data items to implement horizontal access control requirements

3. Avoid doing assign permissions actions directly on individual users

4. Implement a consistent authorization checking routings for all pages of the application;

5. If possible, apply apply DENY at the end, case-by-case to issue allow privilege

6. Implement a centralized access control mechanism

7. Code to the activity (permission), not the role

8. Centralize access control logic

9. Use Access control as a filter or middleware

Ten. Deny by default, fail securely

11. Apply the same core authorization logic to the presentation (view view) layer and server-side Access-control decisions

Server-side trusted data should be used as a source of data to drive Access-control

13. Can modify a user's role in real-time runtime

Build grouping capability for users and permissions

Code to the Activity/permission

// no longer like the following if ((User.ismanager () | | |     User.isadministrator () | |     User.iseditor () | |    User.isuser () &&     1132)) {     //execute action}//  and should look like this:  If (ac.hasaccess (Article_edit)) {   //execute activity}

Code it once, never needs to change again

Implies policy is persisted/centralized in some

Requires more design/work up front-get right

Define a centralized ACL controller: Define a centralized ACL controller

Aclservice.assertauthorized (action_constant)

All access control decision are implemented with these simple APIs.

Centralized authorization logic drives policy behavir and persistence

May contain Data-driven access control policy information

How to use a centralized access controller

1. In the View presntation layer:

if (isauthorized (View_log_panel)) {   

2. In the control layer controller:

Try (assertauthorized (Delete_user)) {   deleteuser ();}

Always validate policy on server side:

1. Place the user ID verification in the session;

2. Load entitlements from a trusted server-side data source

3. Mandatory authorization check for all requests: including JS file initiated Request,mage, Ajax, Flash request to force authorization check, It is best to implement this mandatory authentication function through a common middleware

Web application access Control