The key concept for this card is allowing access, even though authorization checks were undertaken and detected a failure. See Authentication 8 (AT8) for the similar authentication failure.

Scenario: Kelly's Exploitation of Non-Secure Default Authorization

Consider a situation where Kelly bypasses authorization controls due to their failure to default to a secure state. This issue arises because:

1. Non-Secure Default Settings: In case of a failure in the authorization process, the system defaults to allowing access, rather than denying it.

Example

Kelly targets an online service platform that has an authorization mechanism with a non-secure fallback. During a system error or when the authorization service fails, the system is configured to grant access by default as a means to avoid disruption of service. Kelly deliberately triggers errors in the authorization process, and each time, the system defaults to allowing her access to restricted areas that she would normally not have permission to view.

Threat Modeling

STRIDE

This scenario maps primarily to STRIDE: Elevation of Privilege.

Elevation of Privilege (EoP) occurs when an attacker gains access to resources or functionality beyond what they are authorized for. Kelly exploits a non-secure fallback in the authorization mechanism. When the system encounters an error, it defaults to granting access, allowing her to access areas she normally shouldn’t. The attack is not about impersonating someone else (Spoofing), but about accessing resources without proper authorization, which is classic Elevation of Privilege.

What can go wrong?

This vulnerability can lead to unauthorized access to sensitive data or functionalities, potentially compromising the entire system’s security. This can manifest in various forms, including but not limited to:

• Unauthorized access to restricted areas or data during system errors
• Exploitation of system downtime or failures to gain access to protected resources

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?

Once an authorization failure is detected, access needs to be blocked. It is also useful to log (associated with the user's identity if possible) and flag these as possibly malicious activity for further analysis, or as input for application intrusion detection systems.

1. Configure all authorization mechanisms to default to a 'deny access' state in the event of any failure or error.
2. Regularly test and validate the authorization process to ensure it behaves securely during system errors or downtimes.
3. Implement robust monitoring and alerting mechanisms to quickly detect and respond to failures in the authorization system.

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