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
Upon further analysis, the (flawed) assumption with the current approach is that API calls do not have additional side effects. In other words, we assume that if developers perform authorization checks on a resource, they do it right. Given this, the counter example is straight forward:
@ns.route('/create')
class CreateResource(Resource):
def post(self):
current_user.has_created_resource = True
return Fidget.create()
@ns.route('/get/<id>')
class GetResource(Resource):
def get(self, id):
if not current_user.has_created_resource:
abort(401)
return Fidget.get(id=id)
In this mock example, our current approach will fail to identify a flawed authorization check. However, if we get the attacker's session to try all requests first, this will be properly identified.
The text was updated successfully, but these errors were encountered:
Issue
Currently, to determine whether an endpoint is susceptible to IDOR, we execute the last request with the attacker's session. This differs from Microsoft's original paper, which suggests that all requests in the sequence must be executed by the attacker, before testing for IDOR.
Reproduction Steps
Upon further analysis, the (flawed) assumption with the current approach is that API calls do not have additional side effects. In other words, we assume that if developers perform authorization checks on a resource, they do it right. Given this, the counter example is straight forward:
In this mock example, our current approach will fail to identify a flawed authorization check. However, if we get the attacker's session to try all requests first, this will be properly identified.
The text was updated successfully, but these errors were encountered: