All Projects

Hello Team, I hope you are doing well, while researching in your domain i found Blind SSRF and Open Redirection in Comment Section.

Steps:

1.https://blog.alwaysdata.com/2018/09/20/teaching-program-for-better-it-courses/comment-page-1/ 2. Fill the form and add evil.com or your burp Collab in Website Field.
3.Then Click on Post Comment to post your comment in website.

You can see your comment is posted in the website, when you click on the username in the post it will redirect you in the attacker website or in burp collab you get dns and http responses.

Attacker can host your malicious website in comment section to redirect a user in their website for stealing stuffs etc.

#Note:

It can also vulnerable for clickjacking.

Thank You,

Waleed Anwar

Hello Team, I hope you are doing well. I found Credit Card Validation error in your domain.

Steps:

1: Go to https://www.alwaysdata.com/en/register/ and signup for account.

2: Fill the form and Check in Credit Card Validation and Privacy policy.

3:Click on Create my Profile

Note: The Credit Card form not occurred for inputting credit card numbers etc.

Thank you,

Waleed Anwar

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

Hello Team,

I hope you are doing well. While Researching in your domain, I found Subscription not transferred error in your domain.

#Steps to Reproduce:

1: Create profile in "https://www.alwaysdata.com" of owner.
2: Go to "https://admin.alwaysdata.com/Subscription" and open a new account and submit your subscription whatever you want.

3: Then go to "https://admin.alwaysdata.com/permission" and add a user then submit your permission your permission to the user.

4:Again go to "https://admin.alwaysdata.com/Subscription" and click on transfer to another user button to transfer the subscription to the user and then click submit button.

5: Then go to "https://admin.alwaysdata.com/details" and click on Delete this profile button to delete the profile of owner and click on submit button.

Owner assume that he/she transferred the subscription to the user but unfortunately it was not transferred to the user. User only received the notification in their profile and email only of transferred subscription.

Impact:

There is a error of Subscription is not transferred before deleting the profile which may impact to the owner account subscription.

Thank You,

Waleed Anwar

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

Unveiling an IDOR Vulnerability in Email Verification Workflows:

Hello Team, I hope you are doing well. Well, i found a idor vuln in email verification workflow in your doamin.

The Vulnerability
1. Step 1: Create an Account with a Fake Email (Email 1)
Like many web services, the platform I was testing does not required users to verify their email addresses upon registration. I created an account using a random, unverified email address, let’s call it email1@example.com.

2. Step 2: Change the Email Address to a New One (Email 2)
Next, I went to the account settings and attempted to change the email address to a new one, email2@example.com, without verifying email1@example.com. The system allowed me to enter a new email.

3. Step 3: IDOR Exploitation
Here’s where things got interesting. I can use email2@example.com without any verification or any notification which was not sent to that email2@example.com for verification. But due to an IDOR vulnerability, the system skipped this step entirely and automatically considered email2@example.com as verified

This meant that I, as an attacker, could verify someone else’s email (Email 2) that I had no control over, effectively gaining control of that account’s new email without ever needing access to it.

The Impact
This IDOR vulnerability presents significant risks, including:

Account Takeover: By exploiting this flaw, an attacker can hijack accounts by swapping the victim’s email with one of their own.
Phishing and Fraud: Attackers could use the new email to perform phishing attacks, tricking users into divulging sensitive information.
Loss of Control: Users might lose control over their accounts since the new email is verified without their knowledge or consent.
Root Cause
The root cause of this vulnerability lies in the system’s failure to validate the ownership of the new email address before considering it verified. Once the first email is verified, the system should force a re-verification of any newly entered email addresses to prevent this kind of exploitation.

How to Prevent It
Here are a few recommendations to mitigate this type of IDOR vulnerability:

Re-verify New Emails: Ensure that when users attempt to change their email addresses, the new email must be verified before it becomes active.
Strict Access Control: Always implement strong access controls to ensure that a user cannot modify objects (in this case, email IDs) they do not own.
Thorough Input Validation: Validate user inputs and ensure proper checks for email ownership before performing any sensitive actions.
Security Audits: Regularly conduct security audits and penetration testing to identify potential IDOR vulnerabilities and other security flaws.

Thank You,

Waleed Anwar

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

Target:alwaysdata.com

Vulnerability Type:Sensitive Credential Exposure

Severity:CRITICAL

Overview:During an OSINT investigation using a custom tool designed to collect data from dark web forums, I identified exposed credentials of users from alwaysdata.com were leaked This poses a significant security risk to the organization. Attached is the txt file with the credentials I found.

Remediation:
Reset all compromised user passwords immediately
Enforce multi-factor authentication
Monitor for signs of account compromise and unauthorized access
Notify impacted users to update credentials

Impact:
Mass account takeovers by attackers
Breach of personal data and intellectual property
Financial fraud and illegal activities using compromised accounts
Potential lateral network compromiseBrand damage, legal liabilities, regulatory violations

Poc :

https://drive.google.com/drive/folders/1Ox0JvlCLy--RDErIj7y9GzGLwoAY7PQL?usp=sharing

Overview:
While conducting research on alwaysdata.com, I discovered sensitive credentials publicly exposed on a Telegram channel. These credentials provided direct access to alwaysdata’s phpMyAdmin instance, exposing database management functionalities that could lead to unauthorized data access, modification, or deletion. This issue represents a serious security risk, as it could enable malicious actors to compromise databases hosted on alwaysdata.

Steps to Reproduce:
1. Navigate to [https://phpmyadmin.alwaysdata.com/](https://phpmyadmin.alwaysdata.com/).
2. Use the following credentials found on the Telegram channel:

1. Username: projets_baltic
2. Password: LouisCelestin004@#

3. Successfully logging in grants full access to phpMyAdmin.

Proof of Concept (PoC):


Impact:
- Unrestricted access to phpMyAdmin allows any user to view, edit, or delete data within the accessible databases.
- Potential exposure of sensitive customer or internal data, which could result in data breaches.
- Elevates the risk of unauthorized database modifications, compromising data integrity and system security.

Remediation Suggestions:
- Immediately change the credentials for the affected phpMyAdmin user accounts and review logs for any unauthorized access.
- Implement IP or role-based access restrictions to phpMyAdmin to prevent unauthorized external access.
- Monitor and periodically audit for publicly shared or leaked credentials, especially on social media and messaging platforms.

Motivation for Reporting:
This report highlights the potential for data compromise on alwaysdata’s phpMyAdmin, as exposed credentials grant full access to manage sensitive databases. Addressing this issue will help alwaysdata protect its customers’ data and maintain the integrity of its hosted environments.

References:
- [OWASP Secure Credential Storage](https://owasp.org/www-project-proactive-controls/v3/en/c8-protect-data-everywhere)
- [NIST Guidelines on Access Control](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)

Please feel free to reach out if additional details or verification are required.

Stored Xss in mesaage parameter:

Hello Team, I hope you are doing well. While Researching on your domain i Found Stored Xss in message Parameter via Post Method.

Steps:

1. Go to https://admin.alwaysdata.com/message/toggle/.
2. Capture this request on BurpSuite.
3. While in Post Request, there is message_id parameter, you can input xss payload <script>alert(document.cookie)</script> and copy the request and paste it in browser you see it will reflecting in browser.

Poc:

POST /message/toggle/ HTTP/2
Host: admin.alwaysdata.com
Cookie: csrftoken=xxxxxxxxxxxxxx; django_language=en; sessionid=xxxxxxxxxxxxxxx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://admin.alwaysdata.com/message/ Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Csrftoken: nxxtYwkQfIRMWcftaEokwghO10GoV6yv
X-Requested-With: XMLHttpRequest
Content-Length: 50
Origin: https://admin.alwaysdata.com Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=0
Te: trailers

message_id=<script>alert(document.cookie)</script>

Impact
Can steal Cookie, Can run javascript code, etc

Thank You,

Waleed Anwar

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:**

Input Validation:

__**Observation:**__

__**Recommendation:**__

##Title: Improper Access Control in [admin.alwaysdata.com]

Summary:

A privilege escalation vulnerability was identified in the platform’s access control mechanism for managing specific paths related to site and SSL configurations. When a user is restricted from accessing a specific path within a site (sites path permission denied) but granted access to SSL management, they can still access a URL path intended for restricted site management at /site/xx/ssl. This bypasses intended access restrictions.

Description:

[Note that the path I mentioned to you does not appear to you when you are not given permissions to access the path (site)]

The platform enables administrators to set granular permissions, controlling what paths invited users can access or manage within a site. Two relevant permissions in this context are:

Path Management (sites): Grants access to manage certain paths related to a site.

SSL Management (ssl certificates): Grants access to manage SSL certificates.

There is a permissions inconsistency that allows users with SSL Management permissions, but without specific sites path permissions, to access the /site/xx/ssl path. This path resides within a restricted site-related path, yet contains SSL management functionalities. As a result, users can bypass restrictions on specific paths and potentially access or manipulate SSL settings.

##Link: [https://admin.alwaysdata.com/site/configuration/ssl/]
Steps to Reproduce:

1. Create a user account and assign SSL Management (ssl certificates) permissions, while explicitly denying access to the sites path.

2. Attempt to access the URL path: /site/xx/ssl.

3. Observe that access is granted to the SSL management path within the restricted sites path, despite restrictions on other paths under sites.

Expected Result:

The system should prevent access to paths under /site—including /site/xx/ssl—when specific path permissions are denied.

Actual Result:

The user can access /site/xx/ssl even though access to paths under /site is restricted, allowing them unintended access to certain SSL configurations tied to the site path.

##Proof of Concept: https://admin.alwaysdata.com/support/82440/384175-bandicam%202024-11-12%2004-13-20-975.mp4

Impact:

This vulnerability allows unauthorized users to bypass restrictions on certain paths and access SSL configurations. If exploited, this could lead to unauthorized manipulation of SSL settings, compromising the security integrity of site-related resources.

SSRF WITH FILE UPLOAD FUNCTIONALITY:

Hello Team, I hope you are doing well. I found a ssrf through pdf upload in https://admin.alwaysdata.com/support.

Steps to Reproduce:

1. Go to https://admin.alwaysdata.com/support and upload a pdf file which have ssrf through ( "Burp Collab" or malicious url redirection "attacker.com")

2. Send this file to any user when he/she open that file and click the link in that it will redirect to attacker website or http and dns response will be shown in Burpsuite.

Impact
The vulnerability could be used to conduct further attacks, such as accessing internal systems or exfiltrating sensitive data.

Attacker will redirect any user to their website to steal data of user and can do whatever he/she wants.

Thank You,

Waleed Anwar

Summary: A race condition vulnerability was found, allowing users to bypass the product limit restriction and create multiple instances of a product that should be limited to only one per user.

Steps to Reproduce:

1-Open a New Account:
Go to "Open a New Account" and enter the required information.

2-Send Concurrent Requests:
Use a tool like Burp Suite or a script to send multiple requests at the same time.
Slightly change the product name in each request (e.g., "Product1," "Product2") to avoid immediate duplicates.

3-Verify:
Check the account to confirm multiple instances of the product were created.

Impact:

1-Resource Abuse: Users can consume excessive resources (e.g., storage or server space), impacting performance and increasing operational costs.

2-Account Abuse: Malicious users may create multiple products for spam, fraud, or denial-of-service (DoS) attacks.

3-System Integrity: This flaw undermines the system’s integrity by allowing unauthorized duplication of resources.

Recommended Fixes: Atomic Operations: Ensure product creation checks and actions happen as one atomic operation.
Database Constraints: Enforce unique limits in the database to block duplicate entries.
Synchronization: Use locking mechanisms to prevent concurrent request handling.

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

A password reset page does not properly validate the authenticity token at the server side.

1. Go to https://admin.alwaysdata.com/password/lost/ and request a new password.
2. Go to email, and click on the link.
3. Put the new password, submit and intercept the request; remove the authenticity token from the request and now forward it to the server.
you will see request still got completed, its shows token invalid in the browser but you can refresh the page and you see that user is logged in with new password.

Thanks,

Waleed Anwar

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

Improper access control on adding (admin@alwaysdata.com) email in profile setting to take this email.

Hello Sir,

I hope your are doing well. I found a flow in https://admin.alwaysdata.com/ to add banned email to their profile setting to takeover the email.

Steps:

1. Go to https://www.alwaysdata.com/en/register/ 2. Input admin@alwaysdata.com in email and then input password whatever you want.
3. Click Create Profile then its show's (Email address : This email has been banned).
4. Create a Profile with your own email something@mail.com. 5. Then go to https://admin.alwaysdata.com/admin/details/ and then input email which is admin@alwaysdata.com. 6. Then input your old password and click submit you can takeover this email which is banned for making profile.

Impact
An attacker can add this email to their account make some stuff for your business loss.

Thank You,

Waleed Anwar

Hello Alwaysdata Security Team,

I hope this message finds you well.

I am reaching out as part of your Vulnerability Disclosure Program to report a potential security issue I found, titled "Lack of Rate Limiting on Password Reset Page".
===
Vulnerability Details:===

The password reset page (https://admin.alwaysdata.com/password/lost/) currently does not have rate limiting enabled, which allows repeated attempts without any restrictions.i send the request to Intruder and set my email and set payload around 80 times and the server give me the 80 linkes on my eamil (forgot password emial link)

Impact:

Recommendation:

### Title:
Insecure Direct Object Reference (IDOR) Vulnerability: Unauthorized Commenting on Invisible Reports in [security.alwaysdata.com]

Note: I sent the vulnerability to [flyspray] They did not respond to the security report, and it has been a long time, So I had to send it to you.
—

#### Introduction
A security vulnerability has been identified in the site's report commenting feature, which allows unauthorized users to add comments to reports they should not have access to. This is due to an Insecure Direct Object Reference (IDOR) issue, compromising the integrity of sensitive data.

—

#### Steps to Reproduce
1. Create a New Report: Log in and create a new report.
2. Add a Comment: Use Burp Suite to intercept the HTTP request while adding a comment.
3. Modify the Report ID: Change the report ID in the request to one that is not visible to the public.
4. Submit the Modified Request: Forward the modified request through Burp Suite.
5. Check for Unauthorized Comment: Verify that the comment has been added to the invisible report.

##POC: To prove the concept, I commented on a report from my second account, and this report is not publicly available, Report number: 78
link: https://admin.alwaysdata.com/support/82086/382759-Screenshot_%D9%A2%D9%A0%D9%A2%D9%A4%D9%A1%D9%A0%D9%A2%D9%A4_%D9%A0%D9%A4%D9%A5%D9%A9%D9%A5%D9%A7_Kiwi%20Browser.jpg —

#### Impact
This IDOR vulnerability can lead to:
- Unauthorized Access: Users can manipulate and comment on reports they are not permitted to view.

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

### Bug Report: XSS Vulnerability via File Upload

- Bug Type: Cross-Site Scripting (XSS)
- Affected Site: https://admin.alwaysdata.com

#### Steps to Reproduce
1. Log in to the admin panel at [https://admin.alwaysdata.com](https://admin.alwaysdata.com).
2. Navigate to the Feedback section.
3. Create a new ticket for feedback.
4. Attach a file that contains an embedded XSS payload
5. Submit the feedback with the file attached.
6. After submission, open the file in the ticket view.
7. Observe that a popup appears as a result of the XSS payload execution.

#### Impact
- Security Risk: This vulnerability allows attackers to execute arbitrary JavaScript code in the context of the user's browser.
- Potential Exploits: This can lead to session hijacking, redirecting users to malicious sites, or stealing sensitive user information.
- Severity: High – Since the attack leverages file uploads and can be triggered by opening the file in the browser, it could potentially impact many users who interact with the file.

#### Description
The issue occurs when a file is uploaded with a malicious XSS payload embedded. The uploaded file is not sanitized or filtered correctly, allowing the script to execute when viewed. This vulnerability could lead to a serious security breach, compromising user accounts and system data.

Description:
An exposed .git folder has been discovered on the website https://security.alwaysdata.com, which allows unauthorized access to sensitive files related to the site's source code repository. This could potentially lead to the leakage of sensitive information, such as configuration settings and code, which can facilitate further attacks.

URL:
https://security.alwaysdata.com/.git/config

Details:
By accessing the .git folder, the following sensitive files were found to be publicly accessible:

.git/config
.git/index
.git/packed-refs
.git/info/exclude
.git/logs/HEAD
And many more.

Example of Sensitive Information Exposed:

[core]

  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true

[remote "origin"]

  url = https://github.com/flyspray/flyspray.git
  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]

  remote = origin
  merge = refs/heads/master

Using a tool such as GitDump, the entire .git directory was successfully dumped, providing full access to the contents of the repository. This may lead to further exploitation by attackers.

Exposed URLs:
https://security.alwaysdata.com/.git/index https://security.alwaysdata.com/.git/packed-refs https://security.alwaysdata.com/.git/info/exclude https://security.alwaysdata.com/.git/logs/HEAD

Impact:
Unauthorized Access to Source Code: Attackers can gain access to the complete source code, potentially uncovering proprietary algorithms, logic, and confidential information that could be misused for malicious purposes, including code analysis or redistribution.
Sensitive Information Disclosure: The .git/config file and other repository metadata may contain sensitive information, such as database credentials, API keys, or other secrets, which could allow attackers to gain unauthorized access to critical components of the infrastructure.
Potential for Further Exploitation: With access to the source code and potentially sensitive configuration details, attackers may be able to exploit additional vulnerabilities or gain deeper access to the system.

Remediation:
Remove these files from production systems or restrict access to the .git directory. To deny access to all the .git folders you need to add the following lines in the appropriate context (either global config, or vhost/directory, or from .htaccess):

<Directory ~ ".git">
Order allow,deny
Deny from all
</Directory>

If further information is required, please let me know.

Thanks.