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
I turned off the ability for guests to see user profiles in /admin/manage/privileges.
What you expected
I expected that a guest wouldn't be able to determine whether an user exists or not.
What happened instead
For example if a guest tries to get a profile of a non-existent user, they get a 404.
But if they try to get a profile of an exising user, they are redirected to the login page, so they know the users exists.
Anything else?
Since upgrading to the latest version, we have encountered a problem where an attacker is attempting to retrieve all registered usernames through a brute force attack on the /user/:userslug endpoint. We thought disabling the permission for guests to view user profiles would solve this problem.
Could you suggest an alternative approach for this issue?
The text was updated successfully, but these errors were encountered:
While #12447 directly addresses the possible slight information leakage, a more immediate solution for your problem might be just implementing rate limiting on reverse proxy level.
NodeBB version
v3.7.1
NodeBB git hash
No response
NodeJS version
v20
Installed NodeBB plugins
No response
Database type
No response
Database version
No response
Exact steps to cause this issue
I turned off the ability for guests to see user profiles in
/admin/manage/privileges
.What you expected
I expected that a guest wouldn't be able to determine whether an user exists or not.
What happened instead
For example if a guest tries to get a profile of a non-existent user, they get a 404.
But if they try to get a profile of an exising user, they are redirected to the login page, so they know the users exists.
Anything else?
Since upgrading to the latest version, we have encountered a problem where an attacker is attempting to retrieve all registered usernames through a brute force attack on the /user/:userslug endpoint. We thought disabling the permission for guests to view user profiles would solve this problem.
Could you suggest an alternative approach for this issue?
The text was updated successfully, but these errors were encountered: