Skip to main content

Authorization

Concepts​

Basic Architecture (Source: Py-ABAC)

Recommend Practice​

Enforce Least Privileges​

Grant users only the permissions necessary for their roles to minimize potential damage from compromised accounts.

Some steps to implement least privilege:

  1. Ensure trust boundaries are defined during the design phase, including users that will access the resource and what the actions will be.
  2. Validate that the permissions are correctly enforced.
  3. Periodically review and update permissions to ensure they still align with the trust boundaries.

It is easier to grant users additional permissions rather than to take away from them, and vigilantly implementing least privilege can help prevent the risk of revoking permissions.

Deny by Default​

Restrict access to all resources unless explicitly permitted, ensuring unauthorized actions are blocked.

Even though some third party frameworks provide default deny policies, it is still important to implement deny by default in the application layer.

Validate on every request​

Permission should be validated correctly on every request, regardless of how/where the request was initiated. The technology used to perform such checks should allow for global, application-wide configuration rather than needing to be applied individually to every method or class.

Thoroughly Review the Authorization Logic of Chosen Tools and Technologies, Implementing Custom Logic if Necessary¶​

Developers should not rely on the authorization logic provided byt the chosen tools and technologies. Important considerations include:

  1. Incorporate tools such as Dependency Check into the SDLC and consider subscribing to data feeds from vendors, the NVD, or other relevant sources. Implement defense in depth.
  2. Implement defense in depth.
  3. Clarify the authorization requirements then choose the tools that meet the requirements. Not the way around.
  4. Do not rely on default configurations.
  5. Test configuration to ensure it works as declared.

Prefer ABAC/ReBAC over RBAC¶​

RBAC is known to be a weak model for authorization. It is easier to manage and understand, but it is not flexible enough to support complex authorization scenarios, and has issues such as role explosion and performance issues on large role amounts.

ABAC/ReBAC offers more fine-grained control and flexibility, allowing for more complex authorization scenarios such as multi-tenant applications, cross-organizational requests.

Readings

Ensure Lookup IDs are Not Accessible Even When Guessed or Cannot Be Tampered With​

Resources lookup IDs could be exposed in the URL, query params, or other places. However, users should not be able to access a resource they do not have permissions simply because they are able to guess and manipulate that object's identifier in a query param or elsewhere. To mitigate the issue:

  • Avoid exposing the lookup ID whenever possible.
  • Perform access control check on every request for the specific object.

Enforce Authorization Checks on Static Resources​

Importance of securing static resources are often overlooked. Consider the following when securing static resources:

  • While some statci resources are fine to expose, ensure those that shouldn't are incorporated into access control policies.
  • Ensure configuration is correctly set up in the cloud provider.
  • When possible, protect static resources using the same access control logic and mechanisms that are used to secure other application resources and functionality.

Verify that Authorization Checks are Performed in the Right Location​

Authorization should be performed on the server side, not the client side (see OWASP ASVS 4.0.3, V1.4.1 and V4.1.1).

Exit Safely when Authorization Checks Fail​

Failed authorization checks are plausible and should be handled gracefully. Improper handling can lead to unpredictable state. Recommndations include:

  • Ensure all exception and failed access control checks are handled no matter how unlikely they seem. This does not mean that an application should always try to "correct" for a failed check; oftentimes a simple message or HTTP status code is all that is required.
  • Centralize the logic for handling failed access control checks.
  • Verify the handling of exception and authorization failures.
  • Ensure sensitive information, such as system logs or debugging output, is not exposed in error messages.

Implement Appropriate Logging​

insufficient logging and monitoring is recognized as among the most critical security risks in OWASP's Top Ten 2021. Appropriate logs can not only detect malicious activity, but are also invaluable resources in post-incident investigations, can be used to troubleshoot access control and other security related problems, and are useful in security auditing. Recommndations include:

  • Use consistent, well-defined formats that can be readily parsed for analysis.
  • Carefully determine the amount of information to log.
  • Ensure clocks and timezones are synchronized across systems.
  • Consider incorporating application logs into a centralized log server or SIEM.

Create Unit and Integration Test Cases for Authorization Logic¶​

Although not a substitution for a dedicated security test or penetration test, automated unit and integration testing of access control logic can help reduce the number of security flaws that make it into production. Some testing aspects include:

  • Is access being denied by default?
  • Does the application terminate safely when an access control check fails, even under abnormal conditions?
  • Are ABAC policies being properly enforced?
  • etc.
Readings

References​

Readings​