Skip to content
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

add parent-child authorization plugin #12

Open
domanchi opened this issue Sep 13, 2019 · 0 comments
Open

add parent-child authorization plugin #12

domanchi opened this issue Sep 13, 2019 · 0 comments
Labels
enhancement New feature or request

Comments

@domanchi
Copy link
Contributor

Issue

We currently use different sessions to check for IDOR vulnerabilities. However, there's another type of authorization vulnerability that we can check for, as the original Microsoft paper suggests.

The "resource-hierarchy" rule differs from the "user-namespace" rule, in that the latter depends on changing the user's session, while the former keeps the same session, but changes the resource IDs.

Example

POST /collections/create
{"collection_id": 1}
POST /collections/1/photo/create
{"photo_id": 1}

POST /collections/create
{"collection_id": 2}
POST /collections/2/photo/create
{"photo_id": 2}

GET /collections/1/photo/1
code: 200
GET /collections/1/photo/2
code: 401

If this last request returns a 200 instead, that's a vulnerability, and we want to alert on this.

Detailed Description

Given this request sequence:

A. POST /collections/create
B. POST /collections/<collection_id>/photo/create
C. GET /collections/<collection_id>/photo/<photo_id>

We want to execute:

A_1 -> B_1 -> C_1
    -> A_2
    -> C_1

where the letters represent the steps in the request sequence, and the numbers represent the unique requests of that particular step (e.g. we'll be executing A twice in this test).

The first line in this execution diagram represents the normal request sequence execution, that the engine currently does.

The second line re-executes the prefixed subset of the request sequence that does not create parameters that is consumed by the last request in the sequence. In this example, B is not re-executed because B creates a photo_id that is subsequently used in C.

Finally, the first C request is re-executed (with the new collection_id), to see whether there's proper authorization checks on this.

@domanchi domanchi added the enhancement New feature or request label Sep 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant