- Status Closed
-
Assigned To
cbay - Private
Opened by mudhaxk - 12.07.2024
Last edited by cbay - 15.07.2024
FS#57 - Lack of Password Confirmation on Delete Account and GET-Based CSRF
Summary:
A vulnerability was discovered where the delete account functionality lacks password confirmation and is vulnerable to GET-based CSRF, potentially allowing attackers to delete accounts without authorization.
Impact:
- Unauthorized account deletion
- Potential data loss
- Increased risk of account takeover
Expected Result:
- Password confirmation should be required to delete an account
- CSRF protection should prevent unauthorized requests
Actual Result:
- No password confirmation is required to delete an account
- GET-based CSRF vulnerability allows unauthorized account deletion
Steps to Reproduce:
1. Login to the application
2. Trick the user into clicking a malicious link to delete their account: https://admin.alwaysdata.com/admin/details/1/delete 3. User click submit
4. Observe the account being deleted without password confirmation
Recommended Fix:
1. Implement password confirmation requirement for delete account functionality
2. Implement CSRF protection for delete account functionality
3. Validate requests to prevent unauthorized account deletion
Conclusion:
This vulnerability poses a critical risk to user accounts and data. Implementing password confirmation and CSRF protection for delete account functionality will prevent unauthorized account deletion and ensure the security and integrity of user accounts.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Hello,
Deleting an account requires a POST request, not a GET.
Regarding the lack of password confirmation, it's already been reported before.
Kind regards,
Cyril
I know that the delete account final request is a POST request which made after the GET request to https://admin.alwaysdata.com/admin/details/{userId}/delete. There is no proper userId check which could lead to an attacker just sending the following link to any user and when the user click on submit their account will be deleted.
https://admin.alwaysdata.com/admin/details/1/delete
There is a CSRF protection on the delete page. To send a delete link to a victim, first you'd have to find their account ID somehow, but even then, the victim would still have to validate the deletion. That's not a security issue in my opinion.
There is no account ID check when deleting account. An attacker can simply set the account ID as 1. Kindly look into it, you can also use the link below.
https://admin.alwaysdata.com/admin/details/1/delete
The ID from the URL is actually unused. Even if you set the profile ID to 1, it would still delete your own profile.
We'll remove the ID from the URL as it's cleaner, but there's no vulnerability here as there's a validation step with a full list of what's going to be deleted, with a warning.
Yes, but since there was no ID check isn't that classified as server side misconfiguration.
Regards & Thanks.
There is a check, but from the session, not from the URL.
The session check does not validate the ID right? So this is an issue that needs to be fixed because an attacker can leverage it to exploit any user.
Regards & Thanks.
Let me rephrase: the only profile you can delete is your own, bar none.
If you still think there's a vulnerability, please open a new report with a proof of concept.