Altering requests after authenticating

Question

In a web mvc application I have the user login and then he is navigated to a View which presents some data fetched from the database based on a unique Id of the user. He can continue to other views to get more details etc.

After authentication and that means that he has access to the API, is it possible to alter the request somehow like with Burp suite to send an other Id to the View in order to make the API malfunction and return another user's details?

In other words, if someone authenticates, thus a legal user, how do you protect the API from him forging the requests, Post or otherwise, to gain further access or retrieve results of another user by sending parameters that will be fed to SQL?

Answer 1

Yes, good web app design never trusts the input from the client; always assume that it could be malicious.

After authentication and that means that he has access to the API,is it possible to alter the request somehow like with Burp suite to send an other Id to the View in order to make the API malfunction and return another user's details?

Yup. Users could use Edit&Resend in their browsers, users could hit your web service directly with curl or postman, users could even modify the javascript page source.

Whether that will cause your app to malfunction and return data that it shouldn't will depend on whether the app is well built or not :)

In other words, if someone authenticates, thus a legal user, how do you protect the API from him forging the requests, Post or otherwise, to gain further access or retrieve results of another user by sending parameters that will be fed to SQL?

You need to have an authorization layer in the API server. For each request you need to retrieve the userID from the auth token and ask "Is this user allowed to perform this query?". To make it even more complicated, sometimes they are allowed to call that endpoint, but should only see part of the results; for example, maybe every user is allowed to call GET /api/users, and maybe a regular user only sees themself, a group admin sees all users in their group, and a super admin sees all users.

There's no magic or secret formula here, just good API design and coding practices, like using different DB queries / filters depending on the user's type.

Answer 2

Some common ideas are following:

1. Don't send user ID to the client. Instead, generate some token (session ID), e.g. UUID like aecf4b7b-5589-4fb0-bce3-b17194d5d432. In the database save this token and user ID. Return to client only this token, e.g. as a cookie. When client sends request, it will contain this cookie. You lookup in the database and find user ID. If user ID not found or if such cookie is missing in the request, you don't process API call and return HTTP 401 or redirect the request to the login page.

2. Use signature. You can sign user ID with a separate signing key on the server side, put this user ID together with signature to a cookie and return to the client. Each time client sends this cookie to the server, you check your signature. If it is valid, you trust it and execute the API call. If user modified user ID, then the signature will not match and you will not trust such request. Again, return HTTP 401 or redirect the request to the login page.

3. Use some standard library. Above I have described only ideas. After you implement them, there will be further questions like implementing session timeout, or locking/deactivation of user account, or preventing replay attacks, or preventing CSRF attacks. It can cost much efforts to implement it all. And an own implementation can contain bugs which will enable different attacks. When you use some of standard libraries, you will save much efforts and it will be more secure.