-
-
Notifications
You must be signed in to change notification settings - Fork 660
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify horizontal and vertical access control (4.2.1) #1934
Comments
This came from a discussion in #1312 |
issue for authorization reorg #1352 |
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. |
I add here my concern mentioned in V4 regorg issue (#1352 (comment)):
Current requirements:
CWE:
From @tghosth :
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)? |
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.
|
@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...?
@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:
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:
What do we think? |
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 |
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.
|
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
<#1934 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALLXUAHJPHJREM6Q622BG5DZFM3RZAVCNFSM6AAAAABGNGQHYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBTHEYDEMZQG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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 |
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....
The text was updated successfully, but these errors were encountered: