Looked over the code for about 5 min and found a nice little exploit.
While it doesn't compromise the system, it does cost the admin $$$, and could cause annoyed users.
--------------------------------------------------
A "forgot password" function without limitations... What's the worst that could happen :lol:
1) System confirms whether email address is associated with an account
- In short, I can find who's a user (Important in the next step)
2) No rate limiting
- I can check email dumps to see who's a user
- I could also check dumps for an old/current password, e.g. WHMCS dumps.
3) Connected directly to SendGrid API, without a 'cool down' period
4) No database check
- Mwahaha!!! x 100!
5) You have CSRF fields, but do not use them...
6) Putting all of the above together, I can email bomb your users with unlimited "forgot password" emails
I went easy and only sent you 500 or so emails B). But I could have run you up hundreds of dollars on SendGrid... Others might not be as nice.
Without further ado, it's time for me to be an ass and reveal a means to exploit :
Paste in CLI:
for ((n=0;n<500;n++)); do curl -d "
[email protected]" "https://feathur.bluevm.com/forgot.php?action=forgot" > /dev/null 2>&1 ; done
opcorn:
opcorn:
opcorn:
--------------------------------------------------
How to fix:
1) Disable your "forgot password" function before you or your users get email bombed!
2) Displaying whether email exists is trivial. Majority of developers still don't consider it an exploit (as it just shows said email account is a user), but when it's for a mission critical app such as a control panel, I feel that information shouldn't be displayed... Especially for admin accounts.
3) Create a new column in the users DB that marks whether "forgot password" is active. Rate limit this feature to once per 24 hours, per account.
4) Limit "forgot password" attempts to X attempts per IP, and further limit it to one successful "forgot password" attempt per IP.
