4.2.4 - Originating component permissions

[EnigmaRosa]

Proposing a requirement that cannot be pen-tested but is important for sensitive applications, and thus is L3. This is specific to application infrastructures where a component may be the subject trying to access an object, but it is doing so on behalf of some other subject (like a user) which has its own permissions. An example is where an application makes an API call to execute some function. When access is checked for whatever function, it is not the user's permissions that are checked, but rather those of the service.

#	Description	L1	L2	L3	CWE
4.2.4	[ADDED] Verify that access to an object is based on the originating subject's (e.g. user's) permissions, not on the permissions of any intermediary or service acting on their behalf.			✓	441

[elarlang]

Comment from Elar (#2033 (comment)):

Aat the end, if user can see the data or access functionality he/she has no permission, it is authorization problem on the application side. The description is just for verifying a potential cause for the problem.

For me it seems testing-guide or cheat sheet material. From pen-testing perspective it does not give anything extra for 4.1.3+4.2.1.

Comment from Josh (#2033 (comment)):

I agree that this is not really pentestable and I think that it therefore makes sense as an L3 control.
Anecdotally, this is certainly an issue in real apps and ignoring this consideration in design makes it very hard to correctly enforce authorization.

[tghosth]

#	Description	L1	L2	L3	CWE
4.2.4	[ADDED] Verify that access to an object is based on the originating subject's (e.g. user's) permissions, not on the permissions of any intermediary or service acting on their behalf.			✓	441

I agree with this. Any final comments @elarlang @jmanico ?

[jmanico]

Maybe a little language cleanup: Verify that access to an object is based on the original user's permissions, not on the permissions of any intermediary or service acting for them.

[elarlang]

I still think it is more cheat sheet topic to provide such details.

From pen-testing perspective - it is just one edge-case for the problem 4.1.3 / 4.2.1, it means, for me it is a clear duplicate and I recommend to not add this requirement.

The question "how it is different from 4.1.3+4.2.1" is not answered.

[jmanico]

This is a special use case like when a customer service agent is taking over a users account to do something on the users behalf. These can be tricky to code.

[EnigmaRosa]

Genuine question: would the case of differently-permissioned components acting as intermediaries when completing a function not be a specific use case for this?

[tghosth]

@elarlang let's discuss later in the week

@jmanico I think we are talking about a slightly different case here.

Look at the following example, (you might need to view in GitHub)

sequenceDiagram
    actor U as Fred
    participant W as Web Front End (Browser)
    participant WB as Web Back End
    participant UP as User Profile Service
    U->>W: Working in App
    W->>WB: Get My Profile (Fred's session token)
    WB->>UP: Pull User Profile for Fred
    Note over WB,UP: Is Fred's token used for this interaction?
    UP-->>WB: Return profile for fred
    WB-->>W: Render profile on page
    W-->>U: Sees profile

Loading

We can see a multi-layer application here and the big question is what permissions does the "Web Back End" (the intermediary) use to access the "User Profile Service".

In a less well designed app, a "service to service" token which is not user specific and is assigned to "Web Back End" (the intermediary) will be used which is less secure and increases the risk of inappropriate data being pulled from the "User Profile Service". If Fred's token (the original subject) is passed on to "User Profile Service" and "User Profile Service" checks that Fred is allowed to access the data then this makes it less likely that inappropriate data will be pulled in.

This is based on real world examples I have seen.

[jmanico]

This is very helpful Josh. I see this all the time too. I get it now. This is requirement is basically asked developers to "pass the JWT" and instead of relying on service accounts downstream, to continue to use the active users session and identity for permissions, and no some other component or service.

This is a super critical requirement, even more so now that I at least somewhat get it.

[EnigmaRosa]

Thank you Josh, this was exactly the type of scenario I was trying to elicit.