CAPEC-1 - Accessing Functionality Not Properly Constrained by ACLs

In applications, particularly web applications, access to functionality is mitigated by the authorization framework, whose job it is to map ACLs to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application or can run queries for data that he is otherwise not supposed to.






  • Attack Methods 2
  • Analysis
  • Brute Force
  • Purposes 1
  • Penetration
  • Sec Principles 4
  • Failing Securely
  • Least Privilege
  • Reluctance To Trust
  • Complete Mediation
  • Scopes 1
  • Gain privileges / assume identity
  • Authorization
  • Access_Control
  • Confidentiality

Low level: In order to discover unrestricted resources, the attacker does not need special tools or skills. He only has to observe the resources or access mechanisms invoked as each action is performed and then try and access those access mechanisms directly.

The application must be navigable in a manner that associates elements (subsections) of the application with ACLs.

The various resources, or individual URLs, must be somehow discoverable by the attacker

The administrator must have forgotten to associate an ACL or has associated an inappropriately permissive ACL with a particular navigable resource.

No special resources are required for the exploit of this pattern.

In the case of web applications, use of a spider or other crawling software can allow an attacker to search for accessible pages not beholden to a security constraint.

More generally, noting the target resource accessed upon performing specific actions drives an understanding of the resources accessible from the current context.

Use Authorization Mechanisms Correctly

Design Configuration Subsystems Correctly and Distribute Safe Default Configurations

Step 1 - Survey

The attacker surveys the target application, possibly as a valid and authenticated user.

Tecnique ID: 1 - Environment(s) env-Web

Spidering web sites for all available links

Tecnique ID: 2 - Environment(s) env-All

Brute force guessing of resource names

Tecnique ID: 3 - Environment(s) env-All

Brute force guessing of user names / credentials

Tecnique ID: 4 - Environment(s) env-All

Brute force guessing of function names / actions

Indicator ID: 1 - Environment(s) env-Web env-ClientServer

Type: Positive

ACLs or other access control mechanisms are present in the software

Indicator ID: 2 - Environment(s) env-Web env-ClientServer

Type: Positive

User IDs or other credentials are present in the software

Indicator ID: 3 - Environment(s) env-ClientServer env-Local env-Embedded

Type: Positive

Operating modes with different privileges are present in the software

Step 2 - Identify Functionality

At each step, the attacker notes the resource or functionality access mechanism invoked upon performing specific actions.

Tecnique ID: 1 - Environment(s) env-Web

Use the web inventory of all forms and inputs and apply attack data to those inputs.

Tecnique ID: 2 - Environment(s) env-CommProtocol

Use a packet sniffer to capture and record network traffic

Tecnique ID: 3 - Environment(s) env-Local env-Embedded

Execute the software in a debugger and record API calls into the operating system or important libraries. This might occur in an environment other than a production environment, in order to find weaknesses that can be exploited in a production environment.

Outcome ID: 1

Type: Success

The attacker produces a list of functionality or data that can be accessed through the system.

Step 1 - Iterate over access capabilities

Possibly as a valid user, the attacker then tries to access each of the noted access mechanisms directly in order to perform functions not constrained by the ACLs..

Tecnique ID: 1 - Environment(s) env-Web env-Local env-Embedded env-ClientServer

Fuzzing of API parameters (URL parameters, OS API parameters, protocol parameters)

Indicator ID: 1 - Environment(s) env-All

Type: Negative

Attempts to create a catalog of access mechanisms and data have failed.

Outcome ID: 1

Type: Success

Functionality is accessible to unauthorized users.

All resources must be constrained to be inaccessible by default followed by selectively allowing access to resources as dictated by application and business logic

In addition to a central controller, every resource must also restrict, wherever possible, incoming accesses as dictated by the relevant ACL.

In a J2EE setting, administrators can associate a role that is impossible for the authenticator to grant users, such as "NoAccess", with all Servlets to which access is guarded by a limited number of servlets visible to, and accessible by, the user.
Having done so, any direct access to those protected Servlets will be prohibited by the web container.
In a more general setting, the administrator must mark every resource besides the ones supposed to be exposed to the user as accessible by a role impossible for the user to assume. The default security setting must be to deny access and then grant access only to those resources intended by business logic.