Need help on API registration. Security concerns
-
I went ahead and read all about Nodebb authorization.
I believe the api registration of new user is /api/v3/users/. This requires master token but if we are using a master token for registration purposes on frontend, this can be easily abused right. I checked via Postman, and it keeps on creating users everytime the request is sent, appending some values at the end if the username already exists.
So my question is what might be a better way for users to register from the custom frontend using bb for backend? Is this even possible? I can only think about iframing the registration page from nodebb beside this.
Any ideas? Maybe there is another api or some methods I'm not aware of?
Thanks.
-
Thanks @julian .
If anyone comes to this thread in future. I solved this issue by using a rate limiter in the backed server. For now, it suffice the concerns I had.
But being able to access the rate/ip limit via the api itself would always be preferable. Cheers!
-
@hellowmellow the API is best used as a server to server API, and so using it as a frontend API is doable but yes, could be problematic in the way you suggest.
What I'd recommend is having a light server back-end to proxy those requests to NodeBB. The tokens should never be exposed to user facing components.
-
Hey thanks for response @julian!
So like having a proxy nodejs server on the backend, you mean? From frontend it will make a call like http://localhost:1234/reg and backend will take '/reg' and make a call to bb http://localhost:4567/<create-user-api> ?
Can't it still be abused? People can still make calls from the frontend api numerous time as the master token will be hard coded on the backend server for registration calls, or do you mean something else?
-
@julian shouldnt
api
be rate-limited? -
@julian said in Need help on API registration. Security concerns:
Although currently that is not the case.
why is that?
-
@julian , Where exactly we can make changes if we wanted to? I think it should be relatively easy to put a limit.
-
@hellowmellow For now, the easiest way would be to do it in nginx via
limit_req_zone
. You can configure the directive so that it only affects the/api/v3
path.I'm looking at adding it to core now.
-
@julian said in Need help on API registration. Security concerns:
configure the config
I think I know what you wanted to tell us, but the choice of words is quite funny here
-
@julian cool. Also, a quick question. Is there a way to add for the api to check if the user already exists and then prevent registration instead of appending digits and letters to the newer ones? Maybe something like this:
// Check existing const existingUser = await user.getUidByUsername(username); if (existingUser) { return helpers.formatResponse(400, res, { message: 'Username not available' }); }
-
@hellowmellow You can use the
HEAD /api/v3/users/{uid}
call to check before making the registration call.https://docs.nodebb.org/api/write/#tag/users/paths/~1users~1{uid}/head
-
but that's uid, not username ... Am I thinking different?
I guess I am confused on how uid can check if the username already exists. We wouldn't know the uid of the username guest is trying to register for.
-
@hellowmellow No, I was mistaken. Call
HEAD /api/v3/users/bySlug/{slug}
instead. It's the same route, but thebySlug
part allows you to pass in a user slug instead of a uid. -
oh ok. Let me try that. I will wait on if you figure something about rate limit in the core. I will share what I find as well. Cheers!
-
@julian , hey man another quick question I totally forgot to ask. Is there a way to not allow registration if the email is already used via this register api?
Thanks. -
@hellowmellow no, because email is not a part of registration. It is only added to the account once confirmed .
For more info see: https://community.nodebb.org/post/91260
-
Thanks @julian .
If anyone comes to this thread in future. I solved this issue by using a rate limiter in the backed server. For now, it suffice the concerns I had.
But being able to access the rate/ip limit via the api itself would always be preferable. Cheers!
-
-