I have a lot of APIs that are to be dual-use, by both an end-user and administrative staff. I will use preferences and give two examples:
/user/preferences - This give the end-user their preferences
/users/{user}/preferences - This gives any person's preferences
Clearly this is leading to duplication. Of-course, I can use only '/users/{user}/preferences' for both end-users and administrators, but then I end up with other problems:
1) The person will need to put in their user ID into each call, which is clunky.
2) Security will now become a problem, as the backend needs to ensure that each request is being managed correctly, i.e. A malicious person cannot put in another person's ID and retrieve their preferences.
What's the best pattern to follow here?
One option is to make the /user/preferences take an optional ?userid= parameter for the admin calls. Then you can use the same endpoint and branch based on admin == true && args[userid].
The comment on proxy api endpoints is good too where a less specific call (/user/preferences) calls a more specific endpoint (/user/{userid}/preferences).
Either are good options. A lot of people put all the admin calls under /admin/... and add a handler to verify the caller is actually an admin before routing to the regular calls (/admin/users/preferences -> verify is_admin -> /users/preferences?userid=bob).
Related
So I have a platform that works like this: Users can create accounts by logging in with their Google (I USE AUTH0) and then they can create "Projects" which contain lots of other unimportant stuff regarding my current problem (like todo lists, ability to upload files etc; they can also Edit the project by changing some of it's attributes like name, description, theme and so on). There is a home page where everyone can see each other's projects and access them (but not upload files, change the tasks in the to do lists; this is possible only by the person that owns it).
By using a tool like Burp, people can see the request made from frontend to backend, for example when accessing one of the projects, and modify it on the fly.
This is what it looks like inside Burp when they access one of the projects:
As you can see there is a Get request to /projects/idOfTheProject; they can replace the GET with DELETE for example and they will successfully delete it; they can also see what is sent to the backend when a project is edited (name changed, description, thumbnail picture etc) and change anything they want about it.
How should I prevent this?
What I've looked at so far:
a. JWT - Probably the best fitting for my situation, but required the most work to be done (as I already have my platform almost finished with no such a security measure implemented yet, so I may need to rewrite a lot of things in both backend and frontend)
b. Sending the user's id that initiated the action as well to the backend and verify if it has the necessary privileges - the worst solution as users can access each other's profile and see the id, then just change another field in the request's JSON
c. Have a sort of token for each user and send that instead of the user's id - in this way somebody can't get your token by just looking at the communication between frontend and backend (only if it is using YOUR account). That token should be taken maybe somewhere from the auth0 when they create their account? If they provide something like that; or I can just create it myself and store it alongside the other user variables. You would still see the requests in plain text but even if you modified something you would still have to "guess" the owner's token, which will be impossible.
For frontend I use NextJS and for backend Flask.
Thank you in advance!
The TL;DR is that you don’t. A determined user will always be able to see what requests are being sent out by the code running on their computer and over their network. What you are describing when asking how to prevent people from “sniffing” these requests is security through obscurity, which isn’t actually secure at all.
What you should do instead is have an authorization system on your backend which will check if the current user can perform a given action on a given resource. For example, verifying that a user is an administrator before allowing them to delete a blog post, or making sure that the current user is on the same account as another user before allowing the current user to see details about the other user.
The problem to face lies in the design of a RESTful API that can manage requests from multiple roles in an RBAC-based solution.
Currently we have different resources that can be accessed from different users, which can have one or more roles grouped according to their privileges.
The API we're trying to define must be as clear as possible to the client but without the overhead of adding additional metadata to the URL that could damage and even conflict with the REST practices and definitions. Therefore, we must avoid at all costs include information about the roles inside the URL. The plan is to use JWT tokens that carry in their payloads the info needed to know which permissions has the user making the request.
Having raised our current situation, let's provide an example and state the problem to solve:
Suppose we have * financiers * and * providers * as users with some roles who both want to access ** attentions ** (our resource). Should we add before the resource ** attentions ** information about the * user * whose trying to access the resource?
The endpoints in that case should be defined (as an example) as:
https://example.com/api/v1/financiers/:id/attentions
https://example.com/api/v1/providers/:id/attentions
This way we're attempting to inform the respective controllers that we want the ** attentions ** for that specific role / user which are, in some way, a sub-resource of them.
On the other hand, we could simply implement a much simpler endpoint as follows:
https://example.com/api/v1/attentions
The logic about which attentions return from the database should be now implemented in an unique method that must handle this two roles (and potentially new ones that could come up in the following features). All the information needed must be obtained from the payload from the token, exposing a much more generic API and freeing the web client from the responsibility of which endpoint call depending on the role.
I want to highlight that the attentions are managed in a Microservices Architecture and, hence, the logic to retrieve them is gathered in a single service. The cost of the API Gateway to route the two (and potentially more) of the endpoints from the first solution is a variable not to discard in our specific situation.
Having exposed our current situation:
Which we'll be the best approach to handle this issue?
Is there another alternative not contemplated that could ease the role management and provide a clean API to expose to the client?
In the second solution, is correct to return only the attentions accessible to that specific user based on the roles that it has? Isn't it counterintuitive to access an endpoint and only get some of the resources from that collection (and not all) based on its role?
I hope that someone could clarify the approach we're taking as there are little and none literature that I've found regarding this issue.
There there are multiple solutions for such kind of filtration, and developer have to select one depending on given situation.
As per my experience I can list following.
Structure
When data can't be accessed directly and developer has to use a relation (i.e a table JOIN). In that case URL have to include both the main and sub entities. Before going with this approach a good check is to ask, if the same URL can be used with POST ?
Example
If we have to fetch list of roles assigned to a specific user or want to assign additional roles then we can use
GET users/:uid/roles
POST users/:uid/roles
Security
With Multi-tenant systems where each user can have his/her private resources, i.e other users are prohibited from accessing those resources. Developer should save tenancy information and to filter the resources according to current authentication, without bothering client or requiring any additional info in URL
Example
Phone album of the user
GET photos
POST photos
Search
If it is not security or structure related but client still want to filter the result set depending on his scenario. then developer should use query-string for the filtration.
Example
Client have to fetch messages from his/her inbox or outbox or want messages which are not yet read. or he/she want to search his/her inbox
GET messages?folder=inbox
GET messages?folder=inbox&status=unread
GET messages?search=nasir
We're starting to migrate our Website to a REST Service based system and are in the process of developing the core right now.
In our current setup a user has one or more "accounts" assigned which define what data he can see on the website. Only one account can be active for a given user at any time. Right now we store the selected account in the database and use it to filter all queries.
Now I'm not sure how to handle this properly in a REST environment. Possible solutions I found are:
Sending the requested account with every request
Storing the current account in the auth token. (We're using JWT for that)
Having the current account stored on the server and calling a specific resource to change it
Each of these has its pros and cons for our setup. Currently we're using the 3rd approach in our Website. But what would be the correct way to handle such a thing in a REST environment?
Yea the design you are dealing with is fairly bad, and what you really want to do is remove the state completely out of this system.
For that reason the first option is by far superior:
Sending the requested account with every request
If this is simply an id, there's a very simple way to do this, just prefix all your (relevant) routes / uris with this account id. For example:
http://api.example.org/accounts/{id}/...
This way the 'state' is maintained by virtue of which url you are accessing, and the server can be unaware of the state.
Consider following situation: We're currently in a migration phase where the majority of our users should still be forwarded to the existing application A. Other users that fulfil some certain criteria (let's call them beta-testers) should instead be forwarded to the new application B.
Users reach our AD FS with a POST request that contains the SAMLResponse and the RelayState. The RelayState-parameter tells our AD FS the desired target-application. Up to now it always contains "site A" since the users don't know about site B yet ;-)
I'm wondering if there's a way to dynamically change the process our ADFS determines the target application based on the value of the RelayState-parameter?
So what I'm looking for is a way to somehow modify the RelayState based on a certain claim the user provides. E.g. if the user has a "beta-tester" entry in her role-claim, then our ADFS should forward her to site B instead of site A.
Is there a way to hook into the AD FS procssing pipeline? The only thing I found so far is this article describing how to "inject" a custom authentication method. But that's obvisiously not what I'm looking for.
So could anybody tell me if there are any other extension points I could utilize to achieve what I described above?
Sorry, no - there is no way to dynamically change RelayState.
ADFS is locked down (as it is a security system) and doesn't have extension points.
Could you have two RP during the transition?
One approach is to setup a proxy site where you can apply custom logic as necessary for scenarios like this. My experience is there are numerous times when it's handy to have a point of entry into the federation process, i.e. a psuedo-extension point, where you can apply custom logic. So, everyone from the IdP may go to https://proxy.mysite.com and then that site would make determinations based on claims and maybe querystring, posted variables or header attributes, as to where to send (redirect) the user to next, https://a.mysite.com or https://b.mysite.com.
DNS can also be folded in, to do things like direct https://a.mysite.com to the proxy site and the proxy site can then look at the hostname of the request and know that the user intended to go to a.mysite.com, but you can determine if a beta tester and direct to b.mysite.com or the actual A site.
Before I decided to ask this question I have searched quite a long for the answer but I haven't found any satisfactory. (e.g. Examples of the best SOAP/REST/RPC web APIs? And why do you like them? And what's wrong with them?)
And the problem is actually quite simple. I have an object/resource named Account. My REST API supports all CRUDs with GET, POST, PUT and DELETE already with proper error handling, status codes etc.
Additionally however I want to expose an API ("command") to activate and deactivate selected Account resource.
Even if the "isActive" is a property of the Account I don't want to use just the Update from my CRUD of the whole Account.
I know it is easy to violate REST principles and make RPC style design with such design like this:
PUT /api/account/:accountId/activate
PUT /api/account/:accountId/deactivate
So what is the best solution for this use case?
My current idea is to use PUT and DELETE verbs like this (to treat it as a sub-resource) as proposed here http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#restful:
PUT /api/account/:accountId/isActive // for activate
DELETE /api/account/:accountId/isActive // for deactivate
What are your solutions?
How about coming up with a noun for the feature you want to modify - 'status' in this instance. This would then become a sub resource of the parent entity. So for your case I would model the URI as follows:
/api/accounts/{accountId}/status
If the 'update' semantics are idempotent then PUT would be most appropriate, else that would need to be a POST (e.g if nonces are involved and are invalidated by the service). The actual payload would include a descriptor for the new state.
Note, I pluralized 'accounts' since you can have multiple of those, but status is singular since your account can have only one state.
PATCH is the most appropriate method in this case. Please find more at RESTful URL for "Activate"
The POST method would create the resource 'account'. Active can be seen as one of the properties of the resource 'account'. Hence it should be a PUT request.
I would say even deactivate must be a PUT request as the account resource will still exist.
To activate an account you can set a property on the resource. That is:
/api/account/{accountId}?activate=true
To deactivate:
/api/account/{accountId}?activate=false
A GET request on the account would return a JSON with the activate value in it.
A DELETE request should completely delete the account resource.
First off, PUT is appropriate compared to POST, because you are creating a resource to an already-known location. And, I think, there's no dilemma about DELETE. So at first glance, your current approach seems to beat the alternatives.
I used to think the same way, until I implemented my own REST api, in which I wanted the admin to be able to set an account in a deactivated - yet not deleted, just "banned" - state. When I gave it a little more thought, I decided to do it vice versa.
Let me explain. I like to see the activation resource as "the option to activate the account". So if a url like /account/foo/activation exists, it could only mean that the account is not activated and the user has the right to activate it. If it doesn't exist, the account is either already activated or in a banned state.
Consequently, the only rational thing to do in order to activate the account is to try and DELETE the resource. And, in order to enable activation, an admin would have to PUT an activation resource.
Now, the question that comes to mind is how do you distinguish a banned account from an already activated one. But since a ban could be seen as a resource too, you could create a /account/foo/ban resource collection. In order to ban an account, probably for a fixed amount of time, you just POST a resource under that collection, containing all the details of the ban.