Authorization (AZ9)

AUTHORIZATION
9

Michael can bypass the application to gain access to data because administrative tools or administrative interfaces are not secured adequately

How to play?

The key concept for this card is protection of administrative web interfaces such as Content Management System (CMS), database and server web control panels.

Scenario: Michael's Access Through Unsecured Administrative Tools

Consider a situation where Michael bypasses standard application protocols to gain access to data by exploiting inadequately secured administrative tools or interfaces. This vulnerability arises due to:

  1. Lack of Robust Security in Administrative Tools: The tools designed for system management and maintenance do not have sufficient protective measures.
  2. Inadequate Access Controls for Administrative Interfaces: The interfaces used for administrative purposes are easily accessible and lack stringent access restrictions.

Example

Michael discovers that a web application’s administrative interface is accessible through a common URL and is only protected by a weak password. Leveraging this, he gains access to the administrative panel where he can view, modify, and delete sensitive data. This unauthorized access is facilitated by the lack of multi-factor authentication, inadequate password policies, and the absence of monitoring mechanisms on the administrative interface.

Threat Modeling

STRIDE

The STRIDE category applicable here is Elevation of Privilege (EoP).

Michael is gaining access to administrative functions and sensitive data that he should not be able to access with his current privileges. The core impact is that he is escalating his access from a normal user (or unauthenticated user) to an administrative level. Even though he can view and modify data, the underlying issue is that privilege boundaries are bypassed, which aligns with Elevation of Privilege rather than Information Disclosure (which focuses only on unauthorized reading) or Tampering (which focuses on modifying data within authorized access).

What can go wrong?

Unsecured administrative tools and interfaces can lead to major data breaches, unauthorized access to sensitive information, and potential system-wide compromises. This can manifest in various forms, including but not limited to:

  • Weak authentication mechanisms for administrative tools
  • Lack of monitoring and logging for administrative access
  • Access to administrative interfaces by non-privileged users
  • Exploitation of vulnerabilities in administrative tools to gain unauthorized access
  • Inadequate access controls on administrative interfaces, allowing unauthorized users to perform administrative actions

For more things that can go wrong, see the Common Attack Patterns related to this card in the table below.

What are we going to do about it?

  1. Implement strong authentication measures, such as multi-factor authentication, for all administrative interfaces and tools.
  2. Enforce robust password policies and regular credential updates for system administrators.
  3. Restrict access to administrative interfaces to a limited set of authorized IP addresses or networks.
  4. Regularly audit and monitor activities performed through administrative tools to detect and respond to unauthorized access.
  5. Ensure that administrative tools are not accessible through common URLs and are protected by additional layers of security, such as VPNs or secure tunnels.
  6. Implement role-based access control (RBAC) to ensure that only users with the necessary privileges can access administrative functions.
  7. Regularly update and patch administrative tools to address any known vulnerabilities.
  8. Ensure access to administrative interfaces incorporates multiple layers of security, including continuous consumer identity verification, device security posture assessment, and contextual risk analysis.
  9. Ensure communications between backend application components that don't support the application's standard user session mechanism, including APIs, middleware, and data layers, are authenticated and authorized based on the originating user's permissions, not the intermediary component's permissions.
  10. Ensure communications between backend application components, including local or operating system services, APIs, middleware, and data layers, are performed with accounts assigned the least necessary privileges.

For detailed advice on how to mitigate threats related to the card, see the ASVS and OWASP Developer Guide requirements in the table below.

Mappings

OWASP ASVS (v5.0): 6.1.1,6.2.2,6.2.4,6.2.11,6.3.1,6.3.2,6.3.8,6.4.2,7.5.3,8.4.2,13.2.1,13.2.2,13.2.3,13.3.2,13.4.2,13.4.3,13.4.4,13.4.5,16.3.1,16.3.2,16.3.3,16.3.4,17.1.1

OWASP DevGuide: A1,A3,A9,A10,AC2,AC12,ACM4,ACM5,ACM6,ACM7,ACM8

STRIDE: Elevation of Privilege

CAPEC™: 1,36,49,87,121,127,169

SAFECode™: -

CAPEC Map

CodeTitleASVS
1Accessing Functionality Not Properly Constrained by ACLs
36Using Unpublished Interfaces or Functionality
49Password Brute Forcing
70Try Common or Default Usernames and Passwords
87Forceful Browsing
121Exploit Non-Production Interfaces
127Directory Indexing
169Footprinting

ASVS (5.0) Cheat Sheet Series Index

DOS attack

OWASP Cornucopia

OWASP Cornucopia is a mechanism in the form of a card game to assist software development teams identify security requirements in Agile, conventional and formal development processes. It is language, platform and technology-agnostic, and is free to use. OWASP Cornucopia is licensed under the Creative Commons Attribution-ShareAlike 4.0 license, so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar licence to this one.

© 2012-2025 OWASP Foundation. The Open Worldwide Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software.