Skip to content
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

[TODO] Data leak by enumeration #820

Open
gpa opened this issue Aug 27, 2016 · 2 comments
Open

[TODO] Data leak by enumeration #820

gpa opened this issue Aug 27, 2016 · 2 comments

Comments

@gpa
Copy link

gpa commented Aug 27, 2016

Hello guys, very nice project! Here are two problems I noticed:

  1. You can easily get the list of all registered usernames and more importantly the total number of registered users by simply increasing the id in url profile/showProfile/1 then url profile/showProfile/2 and so on. Random ids are more appropriate.
  2. The Password Reset function leaks information about emails that are registered. You can simply request a password reset for any email and the site is going to alert you whether the owner of this email has account on your site or not. This can be simply fixed by always returning "password reset link was sent". Same goes with registration. We should never return FEEDBACK_USER_EMAIL_ALREADY_TAKEN. Instead, if the user tries to register an existing email just let him do it and send a password resetting link with adequate explanation instead.
@panique
Copy link
Owner

panique commented Aug 27, 2016

He, big thanks, this is indeed something that should be fixed...

I'm a little bit unsure if it's the better option to touch the project again or simply leave it, as the script has reached "end of life" some time ago...

@ALL What do the others think ?

@geozak
Copy link
Contributor

geozak commented Aug 28, 2016

About point 1
This is not a change that is necessary inside the framework. The show profile are not meant to part of a final site; they meant to be example of how your code can interact with data from your system.
case in point the framework has the profile/index which shows all the information anyway.

Also changing it so that the url doesn't have the ID number in it does not remove the threat of enumeration as one can just enumerate using post requests.
This is "security through obscurity" which is not security.

To fix this would require making IDs random (probably include alpha numberic).
A more reasonable fix might be to have public facing references use the usernames instead of IDs (even post requests)

About point 2
Yes this might not be ideal but telling new users that the email is already taken (@signup) or does not exist (@pwreset) is how things are done everywhere. The reason is not for security but for user experience.

Imagine you go to reset your password and mistype your email just slightly and the site says your email was sent then you goto your email and never receive an email.
Also think many people have multiple emails. and they know they have an account on this site so they try to reset their password word with one of their emails and receive the message saying an email was sent and then never receive an email because it was the wrong email.

@panique panique changed the title Data leak by enumeration [TODO] Data leak by enumeration Dec 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants