|
14 | Potential SSRF Vulnerability via Self-XSS | Closed | 18.01.2024 |
Task Description
Description:
During a penetration testing process, I discovered a Self-XSS vulnerability on the page https://https://admin.alwaysdata.com/site/resolver/. This vulnerability has the potential to escalate into a Server-Side Request Forgery (SSRF) attack, allowing attackers to make unauthorized requests from the server. This poses risks such as data breaches and potential compromise of internal systems.
While the initial exploitation may require self-XSS, the underlying issue of unvalidated user input leading to SSRF is a critical vulnerability that must be addressed.
Steps To Reproduce:
Step 1 : Open BurpSuite.
Step 2 : Navigate to the following link in a web browser https://admin.alwaysdata.com/site/resolver/ Capture the traffic.Paste the payloads into the intercepted Request Body.
Payload 1:
{"addresses":["<script>alert(document.domain);</script>"]}
(This payload triggers an alert displaying the value of document.domain.)
Payload 2:
{"addresses":["<img src=http://ox7dn3y4fsbqfkyzmmb5alv7i.odiss.eu/>"]}
(This payload makes unauthorized requests from the server.)
The second payload initiates unauthorized requests from the server. In the above payloads, I utilized OAST to examine the responses.
Impact:
Attackers could steal sensitive information stored on the server. By crafting malicious URLs, attackers could gain access to internal network resources that are not publicly accessible.
|
|
98 | Poor Error Handling | Closed | 12.11.2024 |
Task Description
It was observed that the application exhibits poor data handling practices, which could lead to potential security vulnerabilities. Specifically:
Reflected Input in 404 Error Page: When a user navigates to a non-existent URL ====(https://www.alwaysdata.com/%69%6e%73%63%72%69%70%74%69%6f%6e%2f%79%6f%75%5f%61%72%65%5f%68%61%63%6b%65%64%5f%62%79%5f%7a%61%69%6e),==== the application returns a 404 error page. However, any additional text or encoded characters appended to the URL (e.g., malicious payloads) are directly reflected in the error message without proper sanitization or encoding.
Example: Accessing the crafted URL 1: https://www.alwaysdata.com/%69%6e%73%63%72%69%70%74%69%6f%6e%2f%79%6f%75%5f%61%72%65%5f%68%61%63%6b%65%64%5f%62%79%5f%7a%61%69%6e
2: https://www.alwaysdata.com/yOu_Are_hAckEd_by_zaIN_Ul_AbideeN
Result:
====404 - Page not found The page /yOu_Are_hAckEd_by_zaIN_Ul_AbideeN could not be found. If you believe this is an error on our part, please let us know.
Back
====
====Risk:==== This issue indicates a lack of proper input validation and output encoding, making the application vulnerable to Reflected Cross-Site Scripting (XSS) attacks. An attacker could craft malicious URLs containing scripts (e.g., <script>alert('XSS')</script>), which, if clicked by another user, could execute arbitrary JavaScript in their browser.
**Recommendation:**
Validate and sanitize all user-supplied inputs before processing them. Reject or encode unexpected characters in URLs.
==Output Encoding: == Ensure that any data rendered on error pages is properly encoded to prevent the execution of scripts.
==Customized 404 Page:==
Use a generic 404 error page that does not reflect user input back in the response.
==Security Testing: == Perform a thorough security assessment to identify and mitigate XSS or other injection vulnerabilities.
|
|
39 | PII Disclosure | Closed | 28.03.2024 |
Task Description
Go to the below link and you can see the billing information of a user which includes his email and other critical information
https://web.archive.org/web/20220713065916/https://admin.alwaysdata.com/billing/337102/pdf/?user_id=150041&token=1657692793-a13e927142b2d5d7f427
|
|
97 | Password Reset Email Flooding (No Rate Limiting) | Closed | 12.11.2024 |
Task Description
__**Observation:**__
During testing of the web application, I found that the "Forgot Password" functionality lacks proper rate-limiting. After entering my email address to reset my password multiple times in quick succession (more than 61 times with intervals of 30-40 Seconds), the system sent all the reset emails without any restriction. The application does not implement a time-based threshold (e.g., 10 or 20 minutes) between password reset requests, which makes it vulnerable to abuse
====Risk:==== Medium / (Sometimes or in some scenario/cases it will be High
====Impact:====
• mail Flooding: An attacker could repeatedly request password reset emails for any user account, causing their inbox to be flooded with reset emails. This can lead to denial of service for the victim by cluttering their inbox or, in some cases, may trigger email provider throttling, preventing legitimate emails from reaching the user. • Account Lockout Exploit: Although this vulnerability does not directly lead to unauthorized access, it could be combined with social engineering attacks, where victims are confused by multiple reset emails, potentially tricking them into taking malicious actions.
__**Recommendation:**__
•Implement Rate Limiting: Add a limit on how many passwords reset requests can be sent within a specific time frame (e.g., 3 attempts per hour).
•Time-based Delay: Enforce a minimum time interval (e.g., 10-20 minutes) between consecutive password reset requests for the same email address.
•CAPTCHA Implementation: Add CAPTCHA to the password reset functionality to prevent automated abuse by bots.
•Alert Mechanism: Notify users if multiple password reset requests are made in a short period to alert them to potential malicious activity.
•Logging & Monitoring: Implement logging to monitor multiple reset attempts and detect any abuse patterns, which can trigger additional security measures.
|
|
46 | Open Redirection Vulnerability | Closed | 13.04.2024 |
Task Description
Hi Team,
I hope this email finds you well. I am Ali Haider, a security researcher and a penetration tester. I have been a bug bounty hunter for almost 2 years now. I always enjoyed the challenge of finding vulnerabilities, as it always felt like a great achievement to find them. I wanted to bring to your attention a Open Redirection Vulnerability I encountered while using your website.
|
|
105 | open redirect | Closed | 25.11.2024 |
Task Description
https://example.com
|
|
60 | On-click Delete any invitation in [admin.alwaysdata.com ... | Closed | 30.07.2024 |
Task Description
On-click Delete any invitation in [admin.alwaysdata.com]
*Summary:* The [Create My Own Site] web application system is vulnerable to a click grabbing attack that allows an attacker to trick the user into deleting invitations that they have sent or received without their knowledge.
*Reproduction steps:* 1. Send an invitation to another user. 2. Receive an invitation and try it on the other account. 3. Get the direct link to the invitation and add the /cancel/ command to the URL. 4. Create an HTML proof-of-concept file with the following content:
Programming Language
<a href="https://admin.alwaysdata.com/transfer/Invitation_Number/cancel/----">Click</a>
5. Host this HTML page or send it via link to the victim. 6. Once the victim clicks on the masked link, the invitation is deleted without their explicit consent or knowledge.
An attacker could use their location and attach an HTML file instead of sending a file that the user clicks.
I have sent a proof of concept: https://admin.alwaysdata.com/support/77431/374245-bandicam%202024-07-14%2007-00-17-624.mp4
*Impact:* The exploit allows the deletion of any invitation that the user has sent or reached another user without his consent.
|
|
12 | No rate limit on Submit tickets | Closed | 15.01.2024 |
Task Description
Hi team, iam an ethical hacker, web application penetration tester and bug bounty hunter. I found a new Vulnerability So iam reporting it to you now.
Vulnerability: No rate limit on Submit tickets
Description: I have identified a vulnerability in the organization's Submit tickets system, where the request to Submit tickets has no rate limit.
To reproduce this issue, follow the steps below: Step 1: Go to the organization's website: https://admin.alwaysdata.com/support/add/ Step 2: fill the form by typing "1" in the "subject" section and type "2" in the Message" section and intercept the request using Burp Suite. Step 3: Send this request to Intruder and make the payload on "1" that belongs to "subject" section then go to payloads and add numbers from 2 to 20. Step 4: then start the attack. Step 5: Observe that the 20 tickets send to support. Please see my attached screenshots too.
This demonstrates that the vulnerability allows for mass tickets or tickets bombing to the organization, which is detrimental to business operations.
Impact: 1- Increased Load on Servers: Without a rate limit, there could be a significant increase in the number of requests to the server, which could lead to excessive load. 2- Vulnerability to Attacks: It could make the organization more vulnerable to attacks such as Denial of Service (DoS). In a DoS attack, an attacker could flood the system with requests, consuming too much network capacity, storage, and memory. 3- Compromised User Experience: If the server is overwhelmed with requests, it could slow down the system for legitimate users.
I used an email address "haneenibra5566@gmail.com".com", You can check the tickets that have sent from it. I made the above scenario with this email address.
Solution: To mitigate this vulnerability, it is recommended to implement additional security measures such as adding a CAPTCHA or implementing rate limiting on the invitation endpoint. By adding these measures, the organization can prevent malicious users from exploiting the system and protect the business and its users from the negative consequences of mass mailing attacks.
I hope my report will keep you in safe
|
|
40 | No Rate Limit On Reset Password in admin.alwaysdata.co ... | Closed | 27.03.2024 |
Task Description
No Rate Limit On Reset Password in admin.alwaysdata.com
welcome all : i found that no rate limit in reset password in ::: https://admin.alwaysdata.com/password/lost/ Summary: No rate limit check on forgot password which can lead to mass mailing and spamming of users and possible employees A little bit about Rate Limit: A rate limiting algorithm is used to check if the user session (or IP-address) has to be limited based on the information in the session cache. Steps To Reproduce The Issue 1- create account and go to reset password 2- intercept burp and send request to intruder 3- make payload and start attack
Impact 1- Attacker could use this vulnerability to bomb out the email inbox of the victim. 2- Attacker could send Spear-Phishing to the selected mail address. 3-Causing financial losses to the company
|
|
91 | No Rate Limit on account deletion request | Closed | 31.10.2024 |
Task Description
No Rate Limit on account deletion request(Leads to Password Guessing)
Hello Team, I hope you are doing well.
I found this vulnerability in your website Business Logic Errors
Referrer: https://admin.alwaysdata.com/admin/details/357258/delete/
*Description : No Rate Limit is a type of computer security vulnerability typically found in web applications. No Rate Limit enables attackers to perform actions on the web application where the attacker can do signup creation, password reset or 2FA of other users. No Rate Limit vulnerability may be used by attackers to bypass access controls such & bruteforce tokens and passwords without any limiting of any requests. There should be protection on the web application for sensitive actions. Attackers send a high number of requests to perform desirable actions to get access to the application or accounts. NO RL effects vary in range from petty nuisance to significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner network.
*Steps to Reproduce:
1. Go to https://admin.alwaysdata.com/admin/details/357258/delete/
2. Intercept This Request In Burp And Forward Till You Found Your Number In
3 Now Send This Request To Intruder And Repeat It 250 Time By Fixing Any Arbitrary Payload Which Doesn't No Effect Request I Choose Accept-Language: en-US,en;q=0.$5$ and payload set null 250 and start attack.
Note:- Ofcourse, generating account deletion emails is possible if an attacker gets control over user's account (or) it may be possible if any other vulnerabilities are discovered in future.
Thanks,
Waleed Anwar
|
|
119 | Non-functional 2FA recovery codes | Closed | 30.12.2024 |
Task Description
Non-functional 2FA recovery codes
Hello Team,
I hope you are doing well. While researching in your domain https://admin.alwaysdata.com/ I found that their is Non-Functional 2FA recovery code option in your domain.
The users that had enabled 2FA were not able to recover their accounts in case of a missing phone or authentication device. The issue was caused by improper error handling on the client during account recovery.
You should add a back-up recovery option so user or customer should back-up their account easily.
Thank You,
Waleed Anwar
|
|
79 | Nginx version leaking Information Disclosure | Closed | 23.09.2024 |
Task Description
Dear Security Team,
Introduction: I hope this message finds you well. I am reaching out to bring to your attention a Critical severity issue that has been identified during my recent assessment: Information Disclosure Vulnerability Report. The details of the vulnerability can be found in the comprehensive report provided below.
Vulnerability Name: NGINX Version 1.14.2 Leaking
Vulnerability Description: The NGINX Server Version Information Leakage Vulnerability exposes sensitive server version details, potentially aiding malicious actors in crafting targeted attacks against vulnerable systems. By exploiting this vulnerability, attackers can ascertain specific NGINX server versions running on target hosts, facilitating the identification of potential security weaknesses or outdated software versions susceptible to known exploits. This information disclosure could lead to unauthorized access, data breaches, or system compromise, posing significant risks to affected organizations' security posture and integrity of their web infrastructure.
Steps To Reproduce:
1. http://overlord2.alwaysdata.com go to this url and intercept this request (In my case: Burp-Suite). 2. Send this request to repeater & Observe Response.
http://overlord2.alwaysdata.com: Server: nginx/1.14.2
Reference :- https://www.cybersecurity-help.cz/vdb/SB2021052543 www.securityspace.com/smysecure/catid.html?id=1.3.6.1.4.1.25623.1.0.143920
Impact: Malicious actors could craft targeted attacks against vulnerable systems.
The NGINX server version leaking vulnerability exposes organizations to significant risks: Security Breaches: Attackers can exploit version leakage to identify known vulnerabilities in specific NGINX versions, facilitating targeted attacks.
Information Disclosure: Exposing server versions enables attackers to gather intelligence about the server environment, potentially leading to further exploitation or unauthorized access.
System Compromise: Malicious actors can exploit this vulnerability to launch attacks tailored to specific NGINX versions, potentially leading to system compromise, data theft, or disruption of services.
Mitigation:
1. Update NGINX: Regularly update NGINX to the latest stable version to patch known vulnerabilities and reduce the risk of exploitation.
2. Remove Server Tokens: Configure NGINX to hide version information from HTTP response headers using the server_tokens directive.
3. Security Hardening: Implement security measures like Web Application Firewalls (WAFs) and Intrusion Detection Systems (IDS) to monitor and filter malicious traffic targeting NGINX servers.
4. Error Page Customization: Customize error pages to provide minimal information to potential attackers, avoiding disclosure of server version information.
5. Limit Information Exposure: Minimize information exposure by configuring NGINX to reveal only necessary details in error messages and server responses.
I am committed to assisting you in addressing this issue promptly. Please feel free to contact me for any clarification or assistance in implementing the recommended mitigation measures.
Thank you for your attention to this matter, and I look forward to your prompt action in securing your website.
Best regards,
Sanjith Roshan U
Security Researcher
|
|
51 | Multiple Free Public Cloud accounts obtained by a singl ... | Closed | 25.04.2024 |
Task Description
Description
Alwaysdata allows users to create a Free Public Cloud (100MB) account. Each user is limited to having only one Free Public Cloud (100MB account. However, I discovered that a user can bypass this restriction and obtain multiple Free Public Cloud (100MB) accounts by asking other users to create a new free account and then transfer ownership of that account to them.
Reproduction Steps
1. User A creates a new Free Public Cloud (100MB) storage account 2. User B creates a new Free Public Cloud (100MB)storage account 3. User B transfers ownership of their account to User A through: https://admin.alwaysdata.com/admin/account/ 4. User A now has two Free Public Cloud (100MB)storage accounts (their original account and the one transferred from User B) 5. This process can be repeated with same user B for unlimited times to accumulate unlimited no of free accounts.
Impact
By exploiting account ownership transfers, a user can essentially obtain unlimited free storage, potentially leading to loss for alwaysdata
Recommendation
Implement additional checks and restrictions to prevent users from obtaining multiple free accounts through ownership transfers. Possible mitigations could include:
1. Limiting the number of free accounts a user can own, regardless of the acquisition method (creation or transfer). 2. Disallowing ownership transfers for free accounts or requiring explicit approval from the service provider. 3. Automatically consolidating multiple free accounts under the same user into a single account, preserving the total storage limit.
Proof of Concept:
|
|
111 | Missing rate limit for current password field (Password ... | Closed | 27.11.2024 |
Task Description
Missing rate limit for current password field (Password Change) Account Takeover:
Vulnerability: Missing Rate Limit for Current Password field (Password Change) Account Takeover Steps to reproduce the bug: 1)Go to Profile > Password. Enter any (wrong password) In old password filed. 2)Now enter the new password and Turn the Intercept ON. 3)Capture the request & Send the request to Intruder and add a Payload Marker on the current password value. 4)Add the payload for the password field having a list of more than 100 password or more for test and start attack. BOOM! Screen shot is attached as a proof of concept. Impact There is no rate limit enabled for "Current Password" field on changing password on your website. A malicious minded user can continually tries to brute force an account password. If user forget to logout account in some public computer then attacker is able to know the correct password, and also able to change the password to new one by inputting large number of payloads.
Thank You,
Waleed Anwar
|
|
58 | Missing Invitation Link for Existing Users | Closed | 12.07.2024 |
Task Description
Summary:
A vulnerability was discovered where a user with an existing account is not sent an invitation link when added to an organization, potentially leading to confusion and unauthorized access.
Impact:
- User unable to access organization resources - Potential unauthorized access to sensitive information - Increased risk of account takeover
Expected Result:
- User with an existing account should receive an invitation link to join the organization - User should be prompted to accept the invitation and join the organization
Actual Result:
- No invitation link is sent to the user - User is not prompted to accept the invitation and join the organization
Severity according to CVSS 3:
- Attack Vector (AV): Network (N) - Attack Complexity (AC): Low (L) - Privileges Required (PR): None (N) - User Interaction (UI): None (N) - Sensitivity (S): Medium (M) - Confidentiality (C): Medium (M) - Integrity (I): Medium (M) - Availability (A): Medium (M)
CVSS 3 Score: 6.5 (Medium)
Steps to Reproduce:
1. Add a user with an existing account to an organization 2. Observe no invitation link being sent to the user 3. Verify the user's inability to access organization resources
Recommended Fix:
1. Implement automatic invitation link sending for existing users 2. Ensure users receive a prompt to accept the invitation and join the organization 3. Validate user accounts and organization membership to prevent unauthorized access
Conclusion:
This vulnerability poses a medium risk to user access and organization security. Implementing automatic invitation link sending for existing users will ensure proper access and prevent unauthorized access attempts.
|
|
93 | Logout CSRF | Closed | 06.11.2024 |
Task Description
Logout CSRF
Hi Team, This is a low risk but want you to know that logout on this domain admin.alwaysdata.com did not protect the logout form with csrf token, therefor i can logout any user by sending this url https://admin.alwaysdata.com/logout/. Logout should have post method with a valid csrf token. Let me know if you need more info.
Regards Waleed Anwar
|
|
13 | Lack of Verification Email | Closed | 16.01.2024 |
Task Description
Description:
The website lacks proper email verification.During the user registration process,it only sending a greeting email upon registration. The absence of email verification could lead to create unverified accounts and host content with any email address, potentially poses a serious security risk.
Impact :
The absence of email verification poses a significant security risk, allowing the potential use of any email address for registration on a hosting site without proper authentication. This could lead to the creation of accounts under false identities, enabling malicious actors to host illegal content anonymously.
The free hosting service, which doesn't require valid details, may be exploited for unauthorized activities, emphasizing the need for robust email verification procedures to ensure account legitimacy and prevent abuse like.
Spam distribution
Phishing campaigns
Distribution of illegal or harmful content
Reputational damage to the platform
So, I am Reporting this issue to the platform's security team for addressing the vulnerability and enhancing overall security.
|
|
54 | Lack of Verification Email | Closed | 06.06.2024 |
Task Description
### Summary The website does not verify email addresses during the account creation process, which can lead to various security issues such as spam, abuse, and account recovery problems.
### Steps to Reproduce 1. Go to the account creation page.https://www.alwaysdata.com/en/register/ 2. Enter any email address and complete the registration process. 3. Notice that no email verification step is required.
### Impact - Spam and Abuse: Unverified accounts can be used to flood the system with spam or perform malicious activities. - User Impersonation: An attacker can use someone else's email address, leading to possible impersonation issues. - Account Recovery Problems: Users might face difficulties in recovering their accounts if email addresses are not verified.
### Recommendation Implement email verification as a mandatory step in the account creation process to ensure that the email addresses are valid and belong to the users registering them.
|
|
57 | Lack of Password Confirmation on Delete Account and GET ... | Closed | 15.07.2024 |
Task Description
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.
|
|
86 | Lack of Password Confirmation on Delete Account | Closed | 24.10.2024 |
Task Description
Overview of the Vulnerability User accounts are more susceptible to account takeover when there is no password confirmation on certain actions. For example, change of email address, change of password, management of Multi-Factor Authentication details, and account deletion. The application lacks password confirmation on the delete account function which could be abused by an attacker who has access to the user’s account (eg. a public computer the user has not logged out of). From here the attacker could delete a user’s account. ## Business Impact This vulnerability can lead to reputational damage and indirect financial loss to the company as customers may view the application as insecure. ## Steps to Reproduce 1. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP1. Use a browser to navigate to: admin.alwaysdata.com 2. Use delete account functionality1. Intercept the request in a Web Proxy 3. Adjust and forward the following request to the endpoint: 4. Observe that no password confirmation is required
|
|
17 | Lack of password confirmation on account deletion | Closed | 19.01.2024 |
Task Description
Hello support teams, I hope this email finds you well. I am Devansh . I am a security researcher and I found a vulnerability in your website.
bug name : Lack of password confirmation on account deletion
Description: the user account can be deleted without confirming user password or re authentication. The removal of an account is one of the sensitive parts of any application that needs to be protected, therefore removing an account should validate the authenticity of the legitimate user.
steps to reproduce:
1. Go to account settings and click on delete account.
2. There will be a next page where I click on delete my account now option.
3. You will see the message of account has been deleted and get logged out
Remediation: System must confirm authentic user before performing such task. A link can be sent to the user email id that can be used for delete operation. Otherwise user password should be provided to the application to confirm the entity identity.
It seems to be of very low impact,but consider a situation when a user forgets to logout from his account or someone gets access to his phone and deletes the account. This situation is more severe than account takeover as there is no way to get an account again. All the save information and data including previous record, card information etc can be deleted.
video poc is attached
Thanks and regards Devansh
https://
|
|
53 | Lack of Email Confirmation During Account Creation | Closed | 05.06.2024 |
Task Description
Severity: High
Vulnerability Description: The website allows users to create accounts without verifying their email addresses. This practice poses significant security and usability risks.
Impact:
Spam and Fake Accounts:
Malicious users can create multiple fake accounts, leading to spam and abuse of the platform. Automated scripts (bots) can exploit this vulnerability to flood the system with fake accounts, overwhelming resources and degrading performance. Account Security:
Unauthorized users can create accounts using someone else's email address, potentially leading to privacy breaches and unauthorized access to personal information. Genuine users might be unable to access their accounts if their email addresses are misused by others.
Communication Failures:
Users may not receive important notifications, updates, or password reset instructions, leading to poor user experience and support issues.
Reputation and Trust:
The lack of basic security measures can lead to loss of trust among users and damage the website's reputation. Users might perceive the platform as insecure and unreliable, leading to reduced user retention and engagement. Steps to Reproduce: Navigate to the account creation page. Enter any email address (including ones that do not belong to the user) and complete the registration process. Observe that the account is created and accessible without any email verification step.
Recommended Mitigation:
Implement Email Verification:
During registration, send a confirmation email to the provided email address containing a unique verification link. Require users to click on the verification link to activate their accounts. Use CAPTCHA:
Incorporate CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) during the registration process to prevent automated bots from creating accounts.
Rate Limiting:
Implement rate limiting on the account creation endpoint to prevent mass account creation from the same IP address within a short period.
Audit Existing Accounts:
Review existing accounts for potential fake or unauthorized accounts and take appropriate actions, such as sending verification requests or disabling suspect accounts.
References: OWASP Authentication Cheat Sheet: OWASP Authentication Cheat Sheet NIST Digital Identity Guidelines: NIST SP 800-63B
|
|
109 | Issue with password change | Closed | 26.11.2024 |
Task Description
Issue with password change
Hello Team, i hope you are doing well. While, researching in your domain, i found issue with password change bug.
When a password is changed in user's profile, then a notification about password change is sent to the user (email). However, user not always gets a notification about password change - when a password is changed via password reset link, then such a notification is not send to the user. In your domain notification not sent to user, when he/she change the password in profile setting and with reset password.
Thank You,
Waleed Anwar
|
|
114 | Issue with password change | Closed | 04.12.2024 |
Task Description
Issue with password change
Hello Team, i hope you are doing well. While, researching in your domain, i found issue with password change bug.
When a password is changed in user's profile, then a notification about password change is sent to the user (email). However, user not always gets a notification about password change - when a password is changed via password reset link, then such a notification is not send to the user. In your domain notification not sent to user, when he/she change the password in profile setting and with reset password.
Note:
Second time i am reporting this issue to you, please make a test account and do that thing in your end so you clearly understand about it.
Thank You,
Waleed Anwar
|
|
83 | Issue: Application Allowing Old Password to be Set as N ... | Closed | 26.10.2024 |
Task Description
Summary: The application at https://admin.alwaysdata.com allows users to set their old password as the new password when resetting their password via the "Forgot Password" link. This weakens the security of the platform by not enforcing password uniqueness, which is crucial for maintaining account security, especially after a password reset.
Description: When a user resets their password via the "Forgot Password" link, the application allows them to reuse their old password as the new password. This behavior reduces the effectiveness of the password reset process, which is meant to provide users with fresh, secure credentials. If the old password was compromised, allowing the user to reset it back to the same password negates the entire purpose of the password reset feature.
Steps to Reproduce: 1.Go to the login page of https://admin.alwaysdata.com and click on Forgot Password. 2.Enter your registered email address and request a password reset link. 3.Use the received password reset link to reset your password. 4.Enter your current/old password as the "New Password" in the password reset form. 5.Confirm the password reset. 6.Notice that the application allows the old password to be reused without any restrictions.
Impact: Weakens Account Security: Reusing the old password negates the purpose of a password reset, especially if the old password was compromised. This significantly increases the risk of account compromise. Non-Compliance with Best Practices: Regulatory and security guidelines, such as OWASP and NIST password standards, require that new passwords must differ from previous ones to enhance security.
Recommendation: Enforce Password History: Track the user’s password history (e.g., the last 5 passwords) and ensure that the newly set password during a reset is not one of the previously used passwords.
|
|
64 | Insecure Account Deletion | Closed | 22.07.2024 | |
|
43 | Information Disclosure PHPpgAdmin | Closed | 03.04.2024 | |
|
30 | Information Disclosure on cAdvisor software via Origin ... | Closed | 16.02.2024 | |
|
47 | information disclosure | Closed | 13.04.2024 | |
|
118 | Hidden Matomo Tracking Opt-Out Endpoint | Closed | 23.12.2024 | |
|
35 | Git Folder Forbidden Bypass | Closed | 22.02.2024 | |
|
122 | .git folder exposed at https://security.alwaysdata.com/ ... | Closed | 08.01.2025 | |
|
18 | .git file exposed | Closed | 18.01.2024 | |
|
42 | Git Configuration Exposure | Closed | 27.03.2024 | |
|
100 | Full Privilege Access to phpMyAdmin on alwaysdata.com | Closed | 15.11.2024 | |
|
124 | Failure to invalidate session after password change | Assigned | | |
|
69 | EXIF metadata not stripped | Closed | 17.08.2024 | |
|
81 | Encoded XSS and SQL Injection in Registration Page | Closed | 25.10.2024 | |
|
108 | Email Enumeration | Closed | 26.11.2024 | |
|
41 | Directory Listing of Unauthorized Xapian Files | Closed | 27.03.2024 | |
|
107 | Directory Listing Enabled | Closed | 25.11.2024 | |
|
52 | Direct IP Access of the Domain on HTTP | Closed | 05.06.2024 | |
|
123 | Direct accessing Api on another Browser | Closed | 10.01.2025 | |
|
115 | Credit Card Validation not occurring while signup throu ... | Closed | 04.12.2024 | |
|
48 | Clickjacking (On-click) Vulnerability in Support Ticket ... | Closed | 24.04.2024 | |
|
70 | ClickJacking Leads to deletion of user profile | Closed | 17.08.2024 | |
|
121 | Bypass the Session Expiration in admin.alwaysdata.com | Closed | 08.01.2025 | |
|
112 | Bypass rate limiting on reset password (possibly site-w ... | Closed | 27.11.2024 | |
|
74 | Bypassing Two-Factor Authentication via Account Deactiv ... | Closed | 02.09.2024 | |
|
103 | bxss | Closed | 25.11.2024 | |