search

OWASP / CheatSheetSeries

The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.
https://cheatsheetseries.owasp.org
Creative Commons Attribution Share Alike 4.0 International
28.11k stars 3.94k forks source link

Update: Authorization CS (Draft) #474

Closed EbonyAdder closed 3 years ago

EbonyAdder commented 4 years ago

What is missing or needs to be updated?

Cheat sheet is in a draft state.

For background and prior discussion, see #394 and #401.

Apologies for the delay on getting any work done on this. I was not sure how to best approach reworking this CS (issue or PR, requesting feedback on partial or waiting until it is complete, etc), so I hope this is appropriate.

Below is the current version of the CS. I have added the least privileges and deny-by-default sections.

Any feedback is very much welcome.

Authorization Cheat Sheet

Introduction

Authorization may be defined as "[t]he process of verifying that a requested action or service is approved for a specific entity" NIST. Authorization is distinct from authentication which is the process of verifying an entity's identity. When designing and developing a software solution, it is important to keep these distinctions in mind. A user who has been authenticated (perhaps by providing a username and password) is often not authorized to access every resource and perform every action that is technically possible through a system. For example, a web app may have both regular users and admins, with the admins being able to perform actions the average user is not privileged to do so, even though have been authenticated. Additionally, authentication is not always required for accessing resources; an unauthenticated user may be authorized to access certain public resources, such as an image or login page, or even an entire web app.

Flaws related to authorization logic are a notable concern for web apps. Broken Access Control was ranked as the fifth most concerning web security vulnerability in OWASP's 2017 Top 10 and asserted to have a "High" likelihood of exploit by MITRE's CWE program. Furthermore, according to Veracode's State of Software Vol. 10, Access Control was among the more common of OWASP's Top 10 to be involved in exploits and security incidents despite being among the least prevalent of those examined.

The potential impact resulting from exploitation of authorization flaws is highly variable, both in form and severity. Attackers may be able read, create, modify, or delete resources that were meant to be protected (thus jeopardizing their confidentiality, integrity, and/or availability); however, the actual impact of such actions is necessarily linked to the criticality and sensitivity of the compromised resources. Thus, the business cost of a successfully exploited authorization flaw can range from very low to extremely high.

The objective of this cheat sheet is to assist developers in implementing authorization logic that is robust, appropriate to the app's business context, maintainable, and scalable. The guidance provided in this cheat sheet should be applicable to all phases of the development lifecycle and flexible enough to meet the needs of diverse development environments.

Threat Model

Recommendations

Enforce Least Privileges

As a security concept, Least Privileges refers to the principle of assigning users only the minimum privileges necessary to complete their job. Although perhaps most commonly applied in system administration, this principle has relevance to the software developer as well. Least Privileges must be applied both horizontally and vertically. For example, even though both an accountant and sales representative may occupy the same level in an organization's hierarchy, both require access to different resources to perform their jobs. The accountant should likely not be granted access to a customer database and the sales representative should not be able to access payroll data. Similarly, the head of the sales department is likely to need more privileged access than his or her subordinates.

Failure to enforce least privileges in an application can jeopardize the confidentially of sensitive resources. Mitigation strategies are applied primarily during the Architecture and Design phase (see CWE-272); however, the principle must be addressed throughout the SDLC.

Consider the following points and best practices:

Deny by Default

Even when no access control rules are explicitly matched, an the application cannot remain neutral when an entity is requesting access to a particular resource. The application must always make a decision, whether implicitly or explicitly, to either deny or permit the requested access. Logic errors and other mistakes relating to access control may happen, especially when access requirements are complex; consequently, one should not rely entirely on explicitly defined rules for matching all possible requests. For security purposes. an application should be configured to deny access by default.

Consider the following points and best practices:

Validate the Permissions on Every Request

Use Established Frameworks, APIs, and Libraries

Prefer Feature and Attribute Based Access Control over RBAC

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

Enforce Authorization Checks on Static Resources

Verify that Authorization Checks are Performed in the Right Location

Exit Safely when Authorization Checks Fail

Implement Appropriate Logging

Create Unit and Integration Test Cases for Authorization Logic

References

ABAC

Least Privilege

jmanico commented 4 years ago

Kelly,

I really like where this is going.

1) I'd love to see Policy Enforcement Points NOT being roles and being feature names or similar be spelled out in great detail! :)

2) Established Libraries, Frameworks and Libraries RARELY do good access control when complex rules are needed, please be careful here.

But I REALLY like where this is going! Thank you! I am eager to wipe out what was there and replace it all with your work.

On 8/24/20 1:55 PM, Kelly Marchewa wrote:

What is missing or needs to be updated?

Cheat sheet is in a draft state.

For background and prior discussion, see #394 https://github.com/OWASP/CheatSheetSeries/issues/394 and #401 https://github.com/OWASP/CheatSheetSeries/pull/401.

Apologies for the delay on getting any work done on this. I was not sure how to best approach reworking this CS (issue or PR, requesting feedback on partial or waiting until it is complete, etc), so I hope this is appropriate.

Below is the current version of the CS. I have added the least privileges and deny-by-default sections.

Any feedback is very much welcome.

Authorization Cheat Sheet

Introduction

Authorization may be defined as "[t]he process of verifying that a requested action or service is approved for a specific entity" NIST https://csrc.nist.gov/glossary/term/authorization. Authorization is distinct from authentication which is the process of verifying an entity's identity. When designing and developing a software solution, it is important to keep these distinctions in mind. A user who has been authenticated (perhaps by providing a username and password) is often not authorized to access every resource and perform every action that is technically possible through a system. For example, a web app may have both regular users and admins, with the admins being able to perform actions the average user is not privileged to do so, even though have been authenticated. Additionally, authentication is not always required for accessing resources; an unauthenticated user may be authorized to access certain public resources, such as an image or login page, or even an entire web app.

Flaws related to authorization logic are a notable concern for web apps. Broken Access Control was ranked as the fifth most concerning web security vulnerability in OWASP's 2017 Top 10 https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A5-Broken_Access_Control and asserted to have a "High" likelihood of exploit by MITRE's CWE program https://cwe.mitre.org/data/definitions/285.html. Furthermore, according to Veracode's State of Software Vol. 10 https://www.veracode.com/sites/default/files/pdf/resources/sossreports/state-of-software-security-volume-10-veracode-report.pdf, Access Control was among the more common of OWASP's Top 10 to be involved in exploits and security incidents despite being among the least prevalent of those examined.

The potential impact resulting from exploitation of authorization flaws is highly variable, both in form and severity. Attackers may be able read, create, modify, or delete resources that were meant to be protected (thus jeopardizing their confidentiality, integrity, and/or availability); however, the actual impact of such actions is necessarily linked to the criticality and sensitivity of the compromised resources. Thus, the business cost of a successfully exploited authorization flaw can range from very low to extremely high.

The objective of this cheat sheet is to assist developers in implementing authorization logic that is robust, appropriate to the app's business context, maintainable, and scalable. The guidance provided in this cheat sheet should be applicable to all phases of the development lifecycle and flexible enough to meet the needs of diverse development environments.

Threat Model

Recommendations

  Enforce Least Privileges

As a security concept, Least Privileges refers to the principle of assigning users only the minimum privileges necessary to complete their job. Although perhaps most commonly applied in system administration, this principle has relevance to the software developer as well. Least Privileges must be applied both horizontally and vertically. For example, even though both an accountant and sales representative may occupy the same level in an organization's hierarchy, both require access to different resources to perform their jobs. The accountant should likely not be granted access to a customer database and the sales representative should not be able to access payroll data. Similarly, the head of the sales department is likely to need more privileged access than his or her subordinates.

Failure to enforce least privileges in an application can jeopardize the confidentially of sensitive resources. Mitigation strategies are applied primarily during the Architecture and Design phase (see CWE-272 https://cwe.mitre.org/data/definitions/272.html); however, the principle must be addressed throughout the SDLC.

Consider the following points and best practices:

  • During the design phase, ensure trust boundaries are defined. Enumerate the types of users that will be accessing the system, the resources exposed and the operations (such as read, write, update, etc) that might be performed on those resources. For every combination of user type and resource, determine what operations, if any, the user (based on role and/or other attributes) must be able to perform on that resource. For an ABAC system ensure all categories of attributes are considered. For example, a Sales Representative may need to access a customer database from the internal network during working hours, but not from home at midnight.
  • Create tests that validate that the permissions mapped out in the design phase are being correctly enforced.
  • After the app has been deployed, periodically review permissions in the system for "privilege creep"; that is, ensure the privileges of users in the current environment do not exceed those defined during the design phase (plus or minus any formally approved changes).

  • Remember, it is easier to grant users additional permissions rather than to take away some they previously enjoyed. Careful planning and implementation of Least Privileges early in the SDLC can help reduce the risk of needing to revoke permissions that are later deemed overly broad.

    Deny by Default

Even when no access control rules are explicitly matched, an the application cannot remain neutral when an entity is requesting access to a particular resource. The application must always make a decision, whether implicitly or explicitly, to either deny or permit the requested access. Logic errors and other mistakes relating to access control may happen, especially when access requirements are complex; consequently, one should not rely entirely on explicitly defined rules for matching all possible requests. For security purposes. an application should be configured to deny access by default.

Consider the following points and best practices:

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OWASP/CheatSheetSeries/issues/474, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEBYCMCZ4K44ZFWXB5VDADSCL4WBANCNFSM4QKBCQBA.

-- Jim Manico Manicode Security https://www.manicode.com

mackowski commented 4 years ago

@KellyMarchewa can you please create a PR from it? It will be much easier to review and discuss.

mackowski commented 3 years ago

This was addressed in #495