A pytest-inspired, DAST framework, capable of identifying vulnerabilities in a distributed, micro-service ecosystem through chaos engineering testing and stateful, Swagger fuzzing.
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.
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
200instead, 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
Atwice 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,
Bis not re-executed becauseBcreates aphoto_idthat is subsequently used inC.Finally, the first
Crequest is re-executed (with the newcollection_id), to see whether there's proper authorization checks on this.