You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 newcollection_id), to see whether there's proper authorization checks on this.
The text was updated successfully, but these errors were encountered:
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
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:
We want to execute:
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 becauseB
creates aphoto_id
that is subsequently used inC
.Finally, the first
C
request is re-executed (with the newcollection_id
), to see whether there's proper authorization checks on this.The text was updated successfully, but these errors were encountered: