CAPEC

Common Attack Pattern Enumeration and Classification
Common Attack Pattern Enumeration and Classification

A Community Knowledge Resource for Building Secure Software

Home > CAPEC List > Individual CAPEC Dictionary Definition (Release 1.1)   View the CAPEC List

Individual CAPEC Dictionary Definition (Release 1.1)
Individual CAPEC Dictionary Definition (Release 1.1)

Accessing Functionality Not Properly Constrained by ACLs
Attack Pattern ID
Pattern Abstraction: Standard

1

Typical Severity

High

Description

Summary

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 application deployer 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 Execution Flow

Explore

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

    Attack Step Techniques
    DescriptionEnvironments
    Spidering web sites for all available linksenv-Web
    Brute force guessing of resource namesenv-All
    Brute force guessing of user names / credentialsenv-All
    Brute force guessing of function names / actionsenv-All
    Indicators of Susceptibility
    IDTypeDescriptionEnvironments
    c1s1i1PositiveACLs or other access control mechanisms are present in the softwareenv-Web env-ClientServer
    c1s1i2PositiveUser IDs or other credentials are present in the softwareenv-Web env-ClientServer
    c1s1i3PositiveOperating modes with different privileges are present in the softwareenv-ClientServer env-Local env-Embedded

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

    Attack Step Techniques
    DescriptionEnvironments
    Use the web inventory of all forms and inputs and apply attack data to those inputs.env-Web
    Use a packet sniffer to capture and record network trafficenv-CommProtocol
    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.env-Local env-Embedded
    Outcome
    IDTypeDescription
    c1s2o1SuccessThe attacker produces a list of functionality or data that can be accessed through the system.
Experiment

  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.

    Attack Step Technique
    DescriptionEnvironments
    Fuzzing of API parameters (URL parameters, OS API parameters, protocol parameters)env-Web env-Local env-Embedded env-ClientServer
    Indicator of Susceptibility
    IDTypeDescriptionEnvironments
    c1s3i1NegativeAttempts to create a catalog of access mechanisms and data have failed.env-All
    Outcome
    IDTypeDescription
    c1s3o1SuccessFunctionality is accessible to unauthorized users.
Attack Prerequisites

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 deployer must have forgotten to associate an ACL or has associated an inappropriately permissive ACL with a particular navigable resource.

Typical Likelihood of Exploit

Very High

Methods of Attack
  • Analysis
  • Brute Force
Examples-Instances

Description


Implementing the Model-View-Controller (MVC) within Java EE's Servlet paradigm using a "Single front controller" pattern that demands that brokered HTTP requests be authenticated before hand-offs to other Action Servlets.
If no security-constraint is placed on those Action Servlets, such that positively no one can access them, the front controller can be subverted.

Attacker Skill or Knowledge Required

Low: 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.

Resources Required

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

Probing Techniques

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.

Solutions and Mitigations

In a J2EE setting, deployers 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 deployer 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.

Attack Motivation-Consequences
  • Privilege Escalation
Context Description

The context of this pattern's applicability is most likely a web-based application, subject to an authorization framework.

Related Weaknesses
CWE-IDWeakness NameWeakness Relationship Type
285Missing or Inconsistent Access ControlTargeted
276Insecure Default PermissionsTargeted
Relevant Security Requirements

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.

Related Security Principles
  • Failing Securely
  • Least Privilege
  • Reluctance To Trust
  • Complete Mediation
Related Guidelines
  • Use Authorization Mechanisms Correctly
  • Design Configuration Subsystems Correctly and Distribute Safe Default Configurations
Purpose

Penetration

CIA Impact
Confidentiality ImpactIntegrity ImpactAvailability Impact
HighMediumLow
Technical Context
Architectural ParadigmFrameworkPlatformLanguage
AllAllAllAll
Source
Submission(s)
SubmitterOrganizationDateComment
John StevenCigital, Inc2007-02-10Initial core pattern content
Modification(s)
ModifierOrganizationDateComment
Chiradeep B. ChhayaCigital, Inc2007-02-23Fleshed out pattern with extra content
Richard StruseVOXEM, Inc2007-03-26Review and feedback leading to changes in Attack Execution Flow, Attack Prerequisites, Examples and Solutions
Sean BarnumCigital, Inc2007-04-13Modified pattern content according to review and feedback
Paco HopeCigital, Inc.2007-10-20Added extended Attack Execution Flow
Back to top
 

CAPEC is sponsored by the National Cyber Security Division of the U.S. Department of Homeland Security.

Vision and Technical Leadership provided by Cigital, Inc.

This Web site is hosted by The MITRE Corporation.
Copyright 2008, The MITRE Corporation.

Contact capec@mitre.org for more information.
Page Last Updated: April 18, 2008
Privacy policy
Terms of use
Contact us