Access Control requirements reorg

elarlang commented 2 years ago

Master issue for Access Control related requirements - input for lead-meetings and for collection feedback from community.

Updated:

2022-09-16 - 1.4.1 is removed as duplicate of 4.1.1 (#1031)
2024-04-18 - 4.2.2 and 4.2.3 are moved away
2024-04-18 - 13.1.4 is removed as duplicate of 4.2.1
2024-05-26 - 4.1.2 modification
2024-09-11 - 1.4.6 moved to "V14.7 Web or Application Server Configuration"

Related requirements (2022-08-26):

V1.4 Access Control Architecture

#	Description	L2	L3	CWE
1.4.4	Verify the application uses a single and well-vetted access control mechanism for accessing protected data and resources. All requests must pass through this single mechanism to avoid copy and paste or insecure alternative paths. (C7)	✓	✓	284
1.4.5	Verify that attribute or feature-based access control is used whereby the code checks the user's authorization for a feature/data item rather than just their role. Permissions should still be allocated using roles. (C7)	✓	✓	275
1.4.6	[ADDED] Verify that communications between application components, including APIs, middleware and data layers, are performed with the least necessary privileges. (C3)	✓	✓	272

V4.1 General Access Control Design

#	Description	L1	L2	L3	CWE
4.1.1	[MODIFIED] Verify that the application enforces access control rules at a trusted service layer and doesn't rely on controls which an untrusted user could manipulate such as client-side JavaScript.	✓	✓	✓	602
4.1.2	[MODIFIED] Verify that specific controls exist to prevent end users from making changes to access control policy information, such as user roles, permissions, and feature access levels, unless they are explicitly authorized to do so.	✓	✓	✓	639
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.1.5	[GRAMMAR] Verify that access controls fail securely by denying access, including when an exception occurs.	✓	✓	✓	285

V4.2 Operation Level Access Control

#	Description	L1	L2	L3	CWE
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

To-do:

Q2 - 1.4.5
- related opened issues:
- 934
- 1183
- 1191
Q3 - we need attribute level permission check requirement in V4.1 (related to #1183)
Q7 - 4.3.1, 4.3.3 - are those actually authentication requirements? #1974
Q8 - what is actual difference between 4.1.3 and 4.2.1? #1934
Q10 - Is 4.1.3 practically actionable and should 4.1.4 be restored? See #1085

Master issue for V1 cleanup - https://github.com/OWASP/ASVS/issues/1063

Solved:

Q1 - 1.4.1 should be removed as duplicate of 4.1.1
Q5 - 1.4.6 - would be nice to move this requirement to somewhere "configuration hardening" category, to keep separately access control issues for users and for internal components
Q6 - Current 4.2.2 and 4.2.3 should be moved away, as those are not access control requirements (related issue #1230)
Q9 - mark current 13.1.4 as duplicate or move as separate unique requirement to V4.1 (related issue #1312)

Solved, but...:

Q4 - what is the actual and clear point for 4.1.2? Is it potentially duplicate for Q3? (see #1524)
- 4.1.2 got modified via https://github.com/OWASP/ASVS/issues/1524, although for me it's still duplicate of V4.1.3 with specified scope.

jmanico commented 1 year ago

I suggest a change for:

4.1.5 [GRAMMAR] Verify that access controls fail securely, including when an exception occurs. (C10)

to:

4.1.5 [GRAMMAR] Verify that access controls fail securely by denying access, including when an exception occurs. (C10)

jmanico commented 1 year ago

PS I think 4.2.2 is not access control per https://github.com/OWASP/ASVS/issues/1652

tghosth commented 1 year ago

I suggest a change for:

4.1.5 [GRAMMAR] Verify that access controls fail securely, including when an exception occurs. (C10)

to:

4.1.5 [GRAMMAR] Verify that access controls fail securely by denying access, including when an exception occurs. (C10)

I opened #1664 for this @jmanico

jmanico commented 1 year ago

This looks good to me!

EnigmaRosa commented 4 months ago

I strongly believe that 4.3.3 does not belong in access control. I understand why 4.3.1 is relevant to access control - as access to the admin interface can enable changes to user permissions. However, I think it is important to have language that clarifies what that actually means. Administrative interfaces for individual instances (in a multi-tenant SaaS app)? Probably no need to restrict access location.

elarlang commented 4 months ago

@EnigmaRosa - I think it is better to open a separate issue for that discussion, to keep the focus on this issue for V4 reorg and overview.

jmanico commented 3 months ago

I have a large list of requirements from the ABAC standard I'd like to include for consideration. Would it be ok if I added them here @elarlang or would you prefer I add a new issue?

tghosth commented 3 months ago

@jmanico please can you confer with @EnigmaRosa on this as she is currently working on this chapter.

As a reminder, we want to avoid to many in-depth requirements and would prefer to have slightly higher level requirements which refer to external more detailed documentation like cheatsheets or specific standards.

jmanico commented 3 months ago

I hear you Josh. I admittedly have been more detailed-oriented but will switch gears.

jmanico commented 3 months ago

Hey @EnigmaRosa can you kindly contact me at jim@manicode.com please?

OWASP / ASVS