4.3.5 - Coverage by access control policies and deny by default otherwise

[EnigmaRosa]

Note: This is referenced as 4.3.7 in #2033 but has updated numbering

This requirement addresses two parts: there should not be any objects that don't have their access undefined, but if there is, deny by default. Because this cannot exactly be penetration tested, it is L2 and L3.

#	Description	L1	L2	L3	CWE
4.3.5	[ADDED] Verify that every object is addressed by at least one access control policy, and when an object does not have an access control policy all access to that object is rejected.		✓	✓	280

[elarlang]

Comment from Elar (#2033 (comment)):

4.3.7 - not sure about this one. From implementation perspective it maybe makes sense, from pen-testing perspective is just finding a technical reason for 4.1.3 or 4.2.1 requirement.

Comment from Josh (#2033 (comment)):

• I think this is a little too specific, I also think that practically speaking some data objects will be publicly accessible.
• I would rather see this requirement be a little less specific and lean more into the deny by default concept, which we discussed in 4.1.4 - how should we relate to "deny by default"? 4.1.4 - how should we relate to "deny by default"? #1085.

[jmanico]

I think this is an excellent "secure by default" requirement. Access control is very very hard to test comprehensively and I'd like to have some leeway here to steer developers in the right direction since it's essentially business logic.

[EnigmaRosa]

An object being publicly accessible doesn't mean that it lacks an access control policy - in fact, the access control policy should be "allow access independent of attribute" if we want to force deny by default.

[EnigmaRosa]

@tghosth @elarlang following up on this

[tghosth]

Thanks for the ping @EnigmaRosa,

I think it would be good to reword the proposed requirement around deny by default.

Do you think it could be made into a merge of 4.1.3 and the original 4.1.4 as it seems to be related.

[EnigmaRosa]

How about: "Verify that every object is addressed by at least one access control policy, and when an object lacks an access control policy, access to it is automatically denied by default."

Do you think it could be made into a merge of 4.1.3 and the original 4.1.4 as it seems related

I don't know if I would want to combine them - it is probably in best interest to have deny by default and principle of least privilege as unique verification requirements

[jmanico]

I tend to agree with @EnigmaRosa. Since access control is purely business logic, very different in every app, and is the top vulnerability category statistically (per the OWASP Top Ten stats call and more), I'd like to give more leeway to this category. It's really hard to come up with good requirements that actually help developers here.

[EnigmaRosa]

I'd probably also want to move the sub-section this is under

[tghosth]

Minor tweak but otherwise sounds good :)

"Verify that every object is addressed by at least one access control policy. When an object lacks an access control policy, access to it should be automatically denied by default."

Where do you want to put this requirement @EnigmaRosa ?

[elarlang]

From implementation perspective it maybe makes sense, from pen-testing perspective is just finding a technical reason for 4.1.3 or 4.2.1 requirement.

So how this proposed requirement is not duplicate of 4.1.3 and 4.2.1?

[tghosth]

So I think 4.1.3 is looking at how permissions are assigned to users and the proposed requirement is looking at how access controls are assigned to resources. I think these are both separate and valid concerns from an implementation perspective, even if from the testing perspective they seem the same.

I wonder whether 4.2.1 should be merged into 4.1.3 though?

@EnigmaRosa @jmanico what do you think?

[jmanico]

I wonder whether 4.2.1 should be merged into 4.1.3 though?

I prefer not, since IDOR is a really specific issue that I'd like to see directly addressed (4.2.1) and 4.1.3 is more of a general principle of overall access control design.

[tghosth]

I wonder whether 4.2.1 should be merged into 4.1.3 though?

I prefer not, since IDOR is a really specific issue that I'd like to see directly addressed (4.2.1) and 4.1.3 is more of a general principle of overall access control design.

Reproducing 4.1.3 here:

#	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

I am not raising a separate issue for this as I think it is very relevant to the originally proposed requirement.

So I get that 4.1.3 it is a principle, I just don't think that it is currently very implementable or testable. On the other hand, I think the requirement above is implementable and testable and so is the IDOR requirement 4.2.1.

@jmanico if you think that we need 4.1.3 on top of the new requirement and 4.2.1, can you think how to make it more actionable?

[jmanico]

The way that we test for function level access control (does a user have access to a certain feature) and the way we test for IDOR (does a user have access to certain pieces of data) is rather different and uses different tool types. I really want to keep these separate for both testers and developers.

So I suggest that 4.1.3 should go away and instead break it down into the right pieces.

[elarlang]

Probably worth a separate issue, but as the discussion is here at the moment...

edit: I made separate issue for that #2196

For me the 4.1.3 is source for confusions for so many reasons. I think the reason is, that the first part of the requirement is abstract principle and other really-really-widespread test-case that covers basically everything.

So first move should be maybe to split it up and move the 2nd part away to V4.2.

Then we can come back to the question - what those principles like "least privileges" and "deny by default" gives us - how is it possible to test them etc.

[jmanico]

I agree with you Elar on the POLP principle, it covers everything but it's not so actionable.

[tghosth]

If we want to keep it, do we have a proposal for alternative wording?