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

Setup the Skeleton of the Authorization Cheat Sheet #394

Closed EbonyAdder closed 4 years ago

EbonyAdder commented 4 years ago

What is missing or needs to be updated?

How should this be resolved?

Thanks!

ThunderSon commented 4 years ago

IDOR is indeed part of the sheets that require an update. The above remarks are solid and on point (all of them). Would you like to handle this? The access control sheet needs some work. Part of this comment, IDOR is something we're looking to merge into Authorization. IDOR shouldn't be a full CS of its own. It's too much. It's mainly an issue of bad Authorization mechanisms in place.

EbonyAdder commented 4 years ago

I would be glad to assist in the update if possible. Looking over the comment linked to above, it appears you are looking to archive the existing Access Control cheatsheet and replace/merge it and IDOR with a new Authorization cheat sheet? If this is correct, what content (if any) from the current IDOR and Access Control cheatsheets should be included?

Thanks.

ThunderSon commented 4 years ago

For the Access Control, no developer discusses controls in RBAC, DAC, MAC, or any other variation of them. Those are networking and file system concepts, and not applications-based concepts (yes they can be applied, but no developer comes forward and say "I am going to build this in an RBAC model!". RBAC AFAIK is the most used model in applications, they use it implicitly as well. If people want to learn about the Access Controls, I don't think this deserve a CS because it doesn't actually help them implement anything. They can read what is in the CS anywhere on the internet.

About IDOR, you saw what was needed to be done :) What needs to be discussed properly is what is authorization on the object level and function level. So a user trying to access an object out of their permissions shouldn't be allowed. Or using a function in that same thought. IDOR is one of the threads of not properly implementing authorization.

We are not looking to just spit text into it, we are looking to make this something readable by a developer that needs to ensure that authorization is happening on a good level.

Does that answer you?

jmanico commented 4 years ago

RBAC, DAC, MAC, or any other variation of them

Agreed for DAC and MAC.

But RBAC or at least hard coded roles - are very common in software, unfortunately.

IDOR is solved with a wide variety of horizontal access control designs.

But YES this entire cheetsheet needs to be "wiped out and rebuilt" - would be glad to help. I spear headed the initial write of this and support it getting fully re-written.

Access Control design a very difficult topic. Can we work on an outline before we re-write this? I have ideas as well that are more developer relevant.

Aloha, Jim Manico

On 5/25/20 12:58 PM, ThunderSon wrote:

For the Access Control, no developer discusses controls in RBAC, DAC, MAC, or any other variation of them. Those are networking and file system concepts, and not applications-based concepts (yes they can be applied, but no developer comes forward and say "I am going to build this in an RBAC model!". RBAC AFAIK is the most used model in applications, they use it implicitly as well. If people want to learn about the Access Controls, I don't think this deserve a CS because it doesn't actually help them implement anything. They can read what is in the CS anywhere on the internet.

About IDOR, you saw what was needed to be done :) What needs to be discussed properly is what is authorization on the object level and function level. So a user trying to access an object out of their permissions shouldn't be allowed. Or using a function in that same thought. IDOR is one of the threads of not properly implementing authorization.

We are not looking to just spit text into it, we are looking to make this something readable by a developer that needs to ensure that authorization is happening on a good level.

Does that answer you?

— 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/394#issuecomment-633652464, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEBYCK5PFKBTDBP6WS63ATRTKPRXANCNFSM4NIR3B5Q.

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

EbonyAdder commented 4 years ago

I would still be glad to work on this, but not sure if you want me to try and create an outline for review or if jmanico, ThunderSon, or one of the other core contributors is wanting to handle this? Sorry for all the questions, but as a new contributor to this project (and GitHub in general), I want to make sure my efforts and ideas are well-aligned with those who are much more invested in the project than I. I can always contribute to this project in other ways if you believe this cheatsheet is best left to jmanico or other more experienced contributor. Thanks.

ThunderSon commented 4 years ago

@KellyMarchewa Sorry if the conversation gave you a wrong feeling on what are the next steps. What Jim asked is for an outline before you dig deep into the re-write of the cheat sheet in order to see if you're going the right way. I'd love to help you build that outline as well. Don't worry about asking too many questions :blush: If you'd like to chat on this matter or any other security matters, please join us on Slack! You can ping me anytime you need.

EbonyAdder commented 4 years ago

Thanks for the feedback. Below is my proposed outline. The paragraphs below the headers are certainly not meant for the final cheat sheet, just brief remarks providing justification or elaboration for particular headings/recommendations. Obviously authorization is a very big topic, and I was not sure how much background would be ideal to include. For starters, I just focused on the topics that I felt had the most practical relevance to developers, but could certainly be expanded as needed.

Authorization Cheat Sheet

Introduction

Focus on definition and distinguishing it from authentication. Perhaps explore types of privilege escalation (horizontal and vertical). Not sure if we should briefly explore the different access control models (RBAC, MAC, DAC, etc) or just leave it out?

Prevalence and Impact

Try and answer the question of why the reader (developer) should care about the topic.

Attack Scenarios

Would include vulnerable code examples here.

Recommendations

Enforce Least Privileges

Deny by Default

Perform Authorization Checks Server-side and on Every Request

Since anything stored client-side can be readily tampered with. Unfortunately, not familiar enough with serverless development to offer advice on when/how to perform auth checks in that model.

Use Established Frameworks, APIs, and Libraries when Possible

In addition to saving time, these tools have been (when chose carefully of course) have withstood scrutiny. Akin (though certainly not identical) to the argument of why one should not try and create their own cryptographic algorithms/implementations.

Prefer Feature and Attribute Based Access Control over Hard Coded Roles

For the reasons promoted here, under point five.

Ensure Permissions are Sufficiently Granular

Since, depending on context, the user probably should not be able to access all resources of type X, but only those are own or are otherwise privileged to perform operations on. That is, a simple role check may not be sufficient for all use cases; i.e. a user with role "customer" should not be able to access all "account" objects based on their role as a customer, but only their own account. Could perhaps be merged with recommendation on Feature/Attribute Based Access Control above?

Ensure Lookup IDs are Not Readily Guessable or Cannot Be Tampered With

This would essentially relate to IDOR.

Implement Appropriate Logging

Create Unit and Integration Test Cases for Authorization Logic

References

Would definitely like to include references to other OWASP resources, CWE, perhaps some NIST SPs, links relevant to particular languages or frameworks (Spring Security has an excellent section on the topic), etc.

jmanico commented 4 years ago

This is just absolutely fantastic. Sincerely.

May I suggest we change this... Ensure Lookup IDs are Not Readily Guessable or Cannot Be Tampered With

To This..... Ensure Lookup IDs are Not Accessible even when Guessed or Cannot Be Tampered With

The point is, a big random GUID to access data is NOT enough for access control by itself. Hard to guess values are not access control. :)

Aloha,

Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805

On May 30, 2020, at 1:44 PM, Kelly Marchewa notifications@github.com wrote:

 Thanks for the feedback. Below is my proposed outline. The paragraphs below the headers are certainly not meant for the final cheat sheet, just brief remarks providing justification or elaboration for particular headings/recommendations. Obviously authorization is a very big topic, and I was not sure how much background would be ideal to include. For starters, I just focused on the topics that I felt had the most practical relevance to developers, but could certainly be expanded as needed.

Authorization Cheat Sheet

Introduction

Focus on definition and distinguishing it from authentication. Perhaps explore types of privilege escalation (horizontal and vertical)

Prevalence and Impact

Try and answer the question of why the reader (developer) should care about the topic.

Attack Scenarios

Would include vulnerable code examples here.

Recommendations

Enforce Least Privileges

Deny by Default

Perform Authorization Checks Server-side and on Every Request

Since anything stored client-side can be readily tampered with. Unfortunately, not familiar enough with serverless development to offer advice on when/how to perform auth checks in that model.

Use Established Frameworks, APIs, and Libraries when Possible

In addition to saving time, these tools have been (when chose carefully of course) have withstood scrutiny. Akin (though certainly not identical) to the argument of why one should not try and create their own cryptographic algorithms/implementations.

Prefer Feature and Attribute Based Access Control over Hard Coded Roles

For the reasons promoted here, under point five.

Ensure Permissions are Sufficiently Granular

Since, depending on context, the user probably should not be able to access all resources of type X, but only those are own or are otherwise privileged to perform operations on. That is, a simple role check may not be sufficient for all use cases; i.e. a user with role "customer" should not be able to access all "account" objects based on their role as a customer, but only their own account. Could perhaps be merged with recommendation on Feature/Attribute Based Access Control above?

Ensure Lookup IDs are Not Readily Guessable or Cannot Be Tampered With

This would essentially relate to IDOR.

Implement Appropriate Logging

Create Unit and Integration Test Cases for Authorization Logic

References

Would definitely like to include references to other OWASP resources, CWE, perhaps some NIST SPs, links relevant to particular languages or frameworks (Spring Security has an excellent section on the topic), etc.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

ThunderSon commented 4 years ago

@KellyMarchewa That is one big outline :) Would you be able to open the above in a Pull Request? This can be created in the cheatsheets_draft folder. We can have comments there and we'll answer the questions you have.

Thank you!

ThunderSon commented 4 years ago

closed in #401 @KellyMarchewa you may go ahead and open an issue to tackle it :) If you want, you can open a draft PR so things are tracked, and it would allow you to ask us things prior to a full review. Whatever feels best for you.