1

I have an app. Upon a successful login, users get a jwt authentication token that contains various data and expires in 30 min. A valid token is needed in order for the app to call various backend functions and access database resources. However, once the token is verified, the backend functions impose no further security constraints. I'm afraid that this could result in the following attack:

1) Hackers create a valid user account (with bs information), and log in. They now have a valid token.

2) Using that token, they then manipulate various requests to the backend: E.g. they provide some other parties' user-id in the body of the request, and are consequently able access backend resources as if they were that user.

Concrete Example

There is a backend function called deleteUser. It deletes the user associated with the userId passed in the body of the https request. Before being called, the function validates the token, but does not check to see if the token corresponds to the userId in the body of the request. By passing a token associated with a user_A and an id that corresponds to user_B, I'll be able to use user_A's token to delete user_B.

The simple solution

Check that the token's metadata matches the parameters getting passed in the body of the request. However, this is not always simple. Sometimes the information passed in the request body is several steps removed from the data contained within the user token. E.g. a function deleteProperty takes a property_id in the request body, but to verify that the property_id in question relates to the authentication token's metadata would require some expensive database operations - this slows down the app and increases computational load on servers.

Is there a name for this kind of attack? What is the recommended way to stop it? Are there better solutions than what I outlined above?

Improve this question
1
  • This is sometimes called "authorisation bypass" or "parameter tampering" and OWASP used to call it insecure direct object reference The normal fix is to verify incoming IDs, although that can be complex, and prone to a few checks being missed. I've found some great ones in my time, even in online banking. I blogged about defensive approaches too
    – paj28
    Nov 26, 2017 at 21:03

1 Answer 1

Reset to default
2

This would be what the latest OWASP list calls "Broken Access Control". You are requiring authentication, but not checking that the user has permission to access the resource.

You don't really have any other option but to check that the user has the appropriate permissions. This means after validating the token you will have to read the value of the user id and pass it into the functions that operate on the data.

Depending on your language or framework you also may have a convenient method of accessing the autheticated user id via some other mechanism.

If it slows down the application or increases the load then so be it. The alternative is to leak data by a simple manipulation of the request body or url parameters.

You should also make sure that you protect admin level functions with appropriate claims in the JWT.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .