Clarify horizontal and vertical access control (4.2.1)

[tghosth]

4.2.1 alludes to horizontal access control but we should decide whether we want to be more specific about access control types, e.g.

Making sure that the user has permission to perform a particular operation, on a particular data value of a particular entity of a particular type.

I have a slide about this somewhere....

[tghosth]

This came from a discussion in #1312

[elarlang]

issue for authorization reorg https://github.com/OWASP/ASVS/issues/1352

[EnigmaRosa]

I also feel that 4.2.1 is 1. a bit of a mouthful and 2. a roundabout way of calling for horizontal access controls. What if we replace it with

Verify that a users is authorized to perform a given operation on a given item by checking the user's permissions to both the function and the item.

[elarlang]

I add here my concern mentioned in V4 regorg issue (https://github.com/OWASP/ASVS/issues/1352#issue-1352215924):

Q8 - what is actual difference between 4.1.3 and 4.2.1?

Current requirements:	#	Description	L1	L2	L3	CWE
4.1.3	Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.	✓	✓	✓	285
4.2.1	Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.	✓	✓	✓	639

CWE:

• CWE-285: Improper Authorization
  • It's a category / class and should not used for mapping
• CWE-639: Authorization Bypass Through User-Controlled Key

From @tghosth :

Making sure that the user has permission to perform a particular operation, on a particular data value of a particular entity of a particular type.

The main question here is the level of abstraction - do we want to have a separate requirement for each check (checklist style) or one requirement to list them all (principle style)?

[jmanico]

The principle of least privledge is a very general principle. Addressing IDOR is a very specific risk to be addressed.

IDOR and horizontal access control is such a specific top risk in software that I would like make sure we are directly addressing it in a requirement by itself.

[tghosth]

Q8 - what is actual difference between 4.1.3 and 4.2.1?

@elarlang So I think 4.1.3 as currently written is too abstract. I think it should be more actionable, such as saying that new users receive no/low privileges by default and have to have permissions added as they require them. Although maybe that is covered by 4.1.4...?

The main question here is the level of abstraction - do we want to have a separate requirement for each check (checklist style) or one requirement to list them all (principle style)?

@elarlang I think that horizontal access control should be a single requirement. Maybe we want a separate requirement for vertical but I would not want to split to more requirements than that.

@EnigmaRosa suggested:

Verify that a users is authorized to perform a given operation on a given item by checking the user's permissions to both the function and the item.

I think that is in the right direction although it feels a little internally repetitive. Do we want to make the context of the item a little clearer with something like:

Verify that "horizontal" permission enforcement exists which ensures that a user is authorized to perform a given operation for a given item, to prevent IDOR/BOLA style attacks.

What do we think?

[elarlang]

Making sure that the user has permission to perform a particular operation, on a particular data value of a particular entity of a particular type.

Probably it makes sense to split the different vectors to requirements first and then finetune the wording for each of them. At the moment is not easy to follow, what idea or vectors is meant to cover in which requirement.

[tghosth]

Making sure that the user has permission to perform a particular operation, on a particular data value of a particular entity of a particular type.

Probably it makes sense to split the different vectors to requirements first and then finetune the wording for each of them. At the moment is not easy to follow, what idea or vectors is meant to cover in which requirement.

That is what I am saying, I don't think that statement should be multiple requirements, I think it should be a single requirement

[jmanico]

Dealing with horizontal vs. vertical access control is so different in the work developers need to do, I’d rather see IDOR addressed as a separate requirement.

And in general, the more access control requirements split up the better.

According to the data from the latest OWASP Top Ten, access control is the number one risk for web application and API’s and most apps (90+%) have issues in this category. A1.

Because of this I think access control needs a lot more granular work and requirements. IDOR especially is so common and such a severe problem I’d like to see it have a separate and clear requirements.

If you allow me to, I would review the NIST ABAC standard for guidance to beef up the access control section significantly. As it stands now it’s way to light.

I would prefer to get approval from the other leads first before I do this work. My time is limited but I will gladly go for it if I get the go-ahead to do so.

[EnigmaRosa]

I’m currently on vacation with limited internet access - enough to see/respond to emails but not to view a whole issue thread in a browser. That being said, I’d be happy to review the NIST ABAC standard, or work alongside Jim, upon my return mid-June.

On Sun, Jun 2, 2024 at 17:34 Jim Manico @.***> wrote:

Dealing with horizontal vs. vertical access control is so different in the work developers need to do, I’d rather see IDOR addressed as a separate requirement.

And in general, the more access control requirements split up the better.

According to the data from the latest OWASP Top Ten, access control is the number one risk for web application and API’s and most apps (90+%) have issues in this category. A1.

Because of this I think access control needs a lot more granular work and requirements. IDOR especially is so common and such a severe problem I’d like to see it have a separate and clear requirements.

If you allow me to, I would review the NIST ABAC standard for guidance to beef up the access control section significantly. As it stands now it’s way to light.

I would prefer to get approval from the other leads first before I do this work. My time is limited but I will gladly go for it if I get the go-ahead to do so.

— Reply to this email directly, view it on GitHub https://github.com/OWASP/ASVS/issues/1934#issuecomment-2143902307, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALLXUAHJPHJREM6Q622BG5DZFM3RZAVCNFSM6AAAAABGNGQHYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBTHEYDEMZQG4 . You are receiving this because you were mentioned.Message ID: @.***>

[tghosth]

Enjoy your holiday @EnigmaRosa :)

I can get on board with splitting horizontal and vertical but I think we need to be careful about splitting further than that. As we see elsewhere in our work for 5.0, I would rather we had shorter requirements but then referenced more detailed guidance.

@jmanico suggest you hold off until @EnigmaRosa is back and then coordinate with her if that is ok

[jmanico]

i like Josh's suggestion here to include both the concept of horizontal access control and IDOR in the same requirement. A little wordsmithing:

Verify that horizontal permission enforcement exists to ensure users are authorized to perform operations on specific items, preventing IDOR/BOLA attacks.

[tghosth]

@EnigmaRosa have we now covered this elsewhere?

[EnigmaRosa]

We address IDOR in 4.2.1, so I'm okay with it

[tghosth]

I am going to close this but looks like we might modify 4.2.1 in #2196.