Access control bugs in web application should be given importance in a web app pentest or a bug bounty hunt because they are very prevalent.In perspective of bug bounty these are easy to find do not require strong technical knowledge and are rewarding too.

WHAT IS ACCESS CONTROL

Access control enforces policy such that users cannot act outside of their intended permissions.

Access Control refers to the much more general way of controlling access to web resources, including restrictions based on things like the time of day, the IP address of the HTTP client browser, the domain of the HTTP client browser, the type of encryption the HTTP client can support, number of times the user has authenticated that day, the possession of any number of types of hardware/software tokens, or any other derived variables that can be extracted or calculated easily.

Access control is the application of constraints on who (or what) can perform attempted actions or access resources that they have requested. In the context of web applications, access control is dependent on authentication and session management.

There are three types of access controls

Discretionary Access Control

Mandatory Access Control

Role Based Access Control

Discretionary Access Control

Discretionary Access Control (DAC) is a means of restricting access to information based on the identity of users and/or membership in certain groups. Access decisions are typically based on the authorizations granted to a user based on the credentials he presented at the time of authentication (user name, password, hardware/software token, etc.). In most typical DAC models, the owner of information or any resource is able to change its permissions at his discretion (thus the name). DAC has the drawback of the administrators not being able to centrally manage these permissions on files/information stored on the web server. A DAC access control model often exhibits one or more of the following attributes.

• Data Owners can transfer ownership of information to other users
• Data Owners can determine the type of access given to other users (read, write, copy, etc.)
• Repetitive authorization failures to access the same resource or object generates an alarm and/or restricts the user’s access
• Special add-on or plug-in software required to apply to an HTTP client to prevent indiscriminant copying by users (“cutting and pasting” of information)
• Users who do not have access to information should not be able to determine its characteristics (file size, file name, directory path, etc.)
• Access to information is determined based on authorizations to access control lists based on user identifier and group membership.

Mandatory Access Control

Mandatory Access Control (MAC) ensures that the enforcement of organizational security policy does not rely on voluntary web application user compliance. MAC secures information by assigning sensitivity labels on information and comparing this to the level of sensitivity a user is operating at. In general, MAC access control mechanisms are more secure than DAC yet have trade offs in performance and convenience to users. MAC mechanisms assign a security level to all information, assign a security clearance to each user, and ensure that all users only have access to that data for which they have a clearance. MAC is usually appropriate for extremely secure systems including multilevel secure military applications or mission critical data applications. A MAC access control model often exhibits one or more of the following attributes.

• Only administrators, not data owners, make changes to a resource’s security label.
• All data is assigned security level that reflects its relative sensitivity, confidentiality, and protection value.
• All users can read from a lower classification than the one they are granted (A “secret” user can read an unclassified document).
• All users can write to a higher classification (A “secret” user can post information to a Top Secret resource).
• All users are given read/write access to objects only of the same classification (a “secret” user can only read/write to a secret document).
• Access is authorized or restricted to objects based on the time of day depending on the labeling on the resource and the user’s credentials (driven by policy).
• Access is authorized or restricted to objects based on the security characteristics of the HTTP client (e.g. SSL bit length, version information, originating IP address or domain, etc.)

mandatory access control

Role Based Access Control

In Role-Based Access Control (RBAC), access decisions are based on an individual’s roles and responsibilities within the organization or user base. The process of defining roles is usually based on analyzing the fundamental goals and structure of an organization and is usually linked to the security policy. For instance, in a medical organization, the different roles of users may include those such as doctor, nurse, attendant, nurse, patients, etc. Obviously, these members require different levels of access in order to perform their functions, but also the types of web transactions and their allowed context vary greatly depending on the security policy and any relevant regulations (HIPAA, Gramm-Leach-Bliley, etc.).

An RBAC access control framework should provide web application security administrators with the ability to determine who can perform what actions, when, from where, in what order, and in some cases under what relational circumstances. http://csrc.nist.gov/rbac/ provides some great resources for RBAC implementation. The following aspects exhibit RBAC attributes to an access control model.

• Roles are assigned based on organizational structure with emphasis on the organizational security policy
• Roles are assigned by the administrator based on relative relationships within the organization or user base. For instance, a manager would have certain authorized transactions over his employees. An administrator would have certain authorized transactions over his specific realm of duties (backup, account creation, etc.)
• Each role is designated a profile that includes all authorized commands, transactions, and allowable information access.
• Roles are granted permissions based on the principle of least privilege.
• Roles are determined with a separation of duties in mind so that a developer Role should not overlap a QA tester Role.
• Roles are activated statically and dynamically as appropriate to certain relational triggers (help desk queue, security alert, initiation of a new project, etc.)
• Roles can be only be transferred or delegated using strict sign-offs and procedures.
• Roles are managed centrally by a security administrator or project leader.

role based access control

These three types of access control in web apps above constitute the Acess control security model.

#cybersecurity #webapplicationpentest #penetration-testing #infosec #pentesting #testing