Hi,
URL:https://forums.kaomaris.com/
Description:
I noticed a small information leak which allows an attacker to check whether an email address is associated with an account.
Proof of concept:
If we enter any registered email on the forgot password area we got response like this. See the screenshot below.
image.png
And If we enter any unregistered email on forgot password area we got response like this. See the screenshot below.
image.png
Means for both cases we are having different responses. So an attacker can test large number of email addresses that are registered on your website and which are not registered .
Impact:
Attackers will be able to identify which accounts are registered on your website.
Suggested fix:
You should always return a status message like: "If your email exists in our database, you'll receive a reset link". That way an attacker cannot distinguish between the two cases.
Looking forward to your response.
Thanks
Sincerely,
Hassam
Vulnerability Report : Information Disclosure via Forget Password
-
- Recruit
- Posts: 1
- Joined: Thu May 27, 2021 7:47 pm
Vulnerability Report : Information Disclosure via Forget Password
You do not have the required permissions to view the files attached to this post.
- korexus
- Moderator
- Posts: 2832
- Joined: Tue Nov 12, 2002 8:00 am
- Location: Reading
- Contact:
Re: Vulnerability Report : Information Disclosure via Forget Password
Hi there, Hassam.
Thanks for the proactive bug report. Unfortunately, I think you've made a slight mistake.
If you look at your two screenshots, they both have the same creation time form_token. I suspect this is because you've taken the first request and modified it in Burp Suite, rather than creating a fresh request through the browser. This has resulted in your second request being invalid, and rejected before we even check to see if the email address in the system.
You can verify this by trying to reset the email address of the second address through the website, you will be presented with the same "If your account exists..." message as you saw in your first attempt.
You may be interested in reading about Cross Site Request Forgery and replay attacks. Standard defenses against both of these are likely to throw up false positives with your current method of testing.
Thanks.
Chris / korexus.
Thanks for the proactive bug report. Unfortunately, I think you've made a slight mistake.
If you look at your two screenshots, they both have the same creation time form_token. I suspect this is because you've taken the first request and modified it in Burp Suite, rather than creating a fresh request through the browser. This has resulted in your second request being invalid, and rejected before we even check to see if the email address in the system.
You can verify this by trying to reset the email address of the second address through the website, you will be presented with the same "If your account exists..." message as you saw in your first attempt.
You may be interested in reading about Cross Site Request Forgery and replay attacks. Standard defenses against both of these are likely to throw up false positives with your current method of testing.
Thanks.
Chris / korexus.
With Great Power comes Great Irritability