-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Guest users still can determine whether a userslug exists or not #12432
Labels
Comments
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. Assuming you're using Nginx, they have a pretty good blog post on this (or you can just read the docs directly), but a simple drop-in config could look something like this: # outside of the server block
limit_req_zone $binary_remote_addr zone=users:10m rate=5r/s;
server {
# [existing nodebb config]
location ~* ^(/api)?/user {
limit_req zone=users burst=10;
}
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: