All Projects

Hello Team,

Summary:
There exists a Race Condition in which the subscription are added multiple times which will make them unremovable. As you know, same subscription is not added in admin.alwaysdata.com, but through race condition same subscription can be added multiple time and admin can't remove that in which another user are created them.

Steps To Reproduce:

1. Go to https://admin.alwaysdata.com/transfer/add/?type=account.
2. Fill the form which have new owner(for e.g: example@gmail.com) and click on validate it.
3. Go to admin.alwaysdata.com and login your account example@gmail.com. 4. Then go to https://admin.alwaysdata.com/transfer/ and accept the transfer request and intercept the request on Burpsuite.

5.Make 10 to 15 request and group them to send it from repeater.
6. You can see that any subscription are added and if want to delete them you can't.

Impact
Irremovable/permanent subscription. Even the admin cannot remove that subscription in which another user created it in that account.

Thank You,

Waleed Anwar

#Failure to invalidate session after logout from 2nd tab.

Hello Team,

I hope you are doing well. While Researching in your domain I found Failure to invalidate session after logout from 2nd tab vulnerability in your domain. Attacker can view token and any sensitive data.

This Vulnerability found in:
1. admin.alwaysdata.com
2. webmail.alwaysdata.com

#Steps to Reproduce:

1. Login to admin.alwaysdata.com
2. Open another tab and copy the login account URL and paste into 2nd tab.
3. Go to profile option into 1st tab or any other sensitive data page.
4. Logout your account from 2nd tab and then visit to 1st tab, don't refresh that page, so you can see that page is still active and attacker can see victim details or any sensitive data.

Impact:

If a user login their account in café or in a office, Victim open another tab for doing their work and then logout the account in that tab. Victim assume that the account are logged out and victim forget to close the browser but into 1st tab, victim account are still logged in and attacker can view any sensitive data and token or any bank details.

#Note:

I can make a one video for both('admin.alwaysdata.com','webmail.alwaysdata.com')

Thank You,

Waleed Anwar

#Csrf Lead to remove Google auth from account

Hello Team, I hope you are doing well. I found Csrf Lead to remove Google auth from account in admin.alwaysdata.com.

Steps To Reproduce:

1. Login to admin.alwaysdata.co
2. Go to https://admin.alwaysdata.com/user/ and click on delete button and capture the request in burpsuite.
3. Make Csrf Poc and save in to csrf.html.
4. Send this request to another account which have Google Auth.
5. You can see that Google Auth is removed into second account.

Thank You,

Waleed Anwar

#Client-Side Desync Http Request Smuggling in https://admin.alwaysdata.com/site/resolver/

Severity(Critical)

Hello Team, I hope you are doing well. While, Researching in your domain, I found Client-side desync in https://admin.alwaysdata.com/site/resolver/ vulnerability in your domain.

#Steps to Reproduce:

1. Go to https://admin.alwaysdata.com/site/resolver/ and Capture the request in Burp.
2. Paste the code to perform Client-side desync ( Code is Below):

POST /site/resolver/ HTTP/1.1
Host: admin.alwaysdata.com
Cookie: csrftoken=; mtm_consent=; roundcube_sessid=*; roundcube_sessauth=*; django_language=fr; sessionid= Content-Type: text/plain
Content-Length: 104
Transfer-Encoding: chunked

0

GET /en/ HTTP/1.1
Host: www.alwaysdata.com Content-Type: text/plain

{
"addresses":["<script>alert(1)</script>"
]

}

3. Run this Request and you can see 2 Responses occurs.
4. Send this Request multiple time and see it's Caching the request( Screenshot attached Below).

#Video is attached below for confirming Client-Side Desync Http Request Smuggling

# Impacts of client-side desync:

Inject malicious scripts: Smuggle a request that injects a malicious script into a victim's session.

Hijack the session: Use the injected script to steal the victim's session cookie, allowing the attacker to impersonate the victim.

Force authenticated actions: The attacker can compel the victim's browser to perform unauthorized actions on their behalf.

Web cache poisoning
If the vulnerable endpoint involves a web cache, a CSD can be leveraged to poison it.

Redirect users: An attacker could poison the cache to redirect users to a malicious site, potentially leading to phishing or other scams.

Sensitive information disclosure
A CSD can force a victim's browser to send a request that leaks sensitive information, such as their session cookies

Denial of service (DoS)
Overwhelming a server with malformed or inconsistent requests can cause it to become unstable or unresponsive, leading to a denial-of-service condition.

Thank You,

Waleed Anwar

#Attacker Can Access Webmail.alwaysdata.com without validating account in admin.alwaysdata.com

Hello Team,

I hope you are doing well. I found Attacker Can Access Wemail.alwaysdata.com without validating account in admin.alwaysdata.com.

#Steps to Reproduce:

1.Go to https://www.alwaysdata.com/en/marketplace/ and install any application you want.
2.Fill the form then submit the request.
3.Then go to webmail.alwaysdata.com to put your address and password in which you had submitted in Step 2.
4.You can see that attacker can login in webmail.alwaysdata.com without validating account in admin.alwaysdata.com.

#Impact:

Attacker can use victim email to create an account and then use the address to login in webmail.alwaysdata.com. Attacker send fake emails and phishing email to someone as a behalf of a victim.

Thank You,

Waleed Anwar

#Insecure Cache-Control Leading to View Email, Password and User Information in https://www.alwaysdata.com/en/marketplace/ (All Applications).

Hello Team, I hope you are doing well. I found Insecure Cache-Control Leading to View Email, Password and User Information in https://www.alwaysdata.com/en/marketplace/ (All Applications).

Steps to Reproduce:

1. Go to https://www.alwaysdata.com/en/marketplace/.
2. Click on Install any application button you want to install.
3. Fill the form and submit the request.
4. It will go https://admin.alwaysdata.com/user/validation-needed/.
5. Press Back Button and you can see all of these information you are submitted these are shown in the form.

# Impact:

In a PC scenario in an office or in a library or in a coffee shop or such places allow for an attacker to exploit this vulnerability (since the amount of pages visited after visiting doesn't matter). Also it is very easy to get access to a laptop, so this is a likable scenario, and once it happens the attacker has full control over the victim's app data since he/she can use the account.

# Note:

Tested in Chrome latest version, Firefox and Microsoft Edge.

Thank You,

Waleed Anwar

Hello Team,

CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing.

CSRF HTML Code:

  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://www.alwaysdata.com/en/contact/" method="POST">
      <input type="hidden" name="address" value="************" />
      <input type="hidden" name="name" value="janam" />
      <input type="hidden" name="number" value="**************" />
      <input type="hidden" name="slot" value="" />
      <input type="hidden" name="message" value="hello" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState(', '', '/');
      document.forms[0].submit();
    </script>
  </body>

There is a csrfmiddleware but when i was removing and sending the request to autenticated user its working and submitting the request.

Thank You,

Waleed Anwar

Hello Team

I hope you are doing well. While Researching in your domain, I found csrftoken not unique to session or specific user and csrfmiddlewaretoken can be altered issue in https://admin.alwaysdata.com

Steps to Reproduce:

1: A post request will be sent /api/tokens/delete/302 or /api/tokens/delete/some_number and i see in burp that in the cookie's header csrftoken = vhHMjvtks3jwGkHikbY48d5gQR76yvPA and i see in the params sent that csrfmiddlewaretoken= 8b9QkWMZgnqohp9R77Tu4m46PQW0YZRwtiGsth59ygzKNzGZh8Ho2pZcvxTWmkwW

what i noticed is that changing csrfmiddlewaretoken's value to csrftoken 's value will still make the request work..
ie setting csrfmiddlewaretoken = vhHMjvtks3jwGkHikbY48d5gQR76yvPA will still let the request work.

2: I noticed that the csrftoken sent in requests is not unique to the session id or user logged , meaning if im logged in as user1 and have csrftoken=x then i can login as user2 and send the request with csrftoken=x and csrfmiddlewaretoken=x and it will work!

what does this mean?

3.this means csrfmiddlewaretoken does not really add another layer of protection, i can easily change it the csrftoken stored in the cookie and it will still work

4. given a valid csrftoken from any user (for example csrftoken=c7wq7XJaQq71Eump3tVwNJpOSHLbiqSC), its possible to create a csrf request that sends the POST /api/tokens/delete/index request (where index can be enumerated ) with this valid csrftoken being sent as the csrfmiddlewaretoken value and with
X-CSRF-Token set also as the valid csrf token as well and it will work and we can manage to delete user api tokens through csrf exploit( for example clicking on a website that sends such request).

Note:

First account user csrftoken can be used to remove second account api token.

Thank You,

Waleed Anwar

# HTTP Parameter Pollution Lead to Crash the Website of admin.alwaysdata.com:

Hello Sir, I hope you are doing well. While, Researching on your domain, I found HTTP Parameter Pollution Lead to Crash the Website of admin.alwaysdata.com.

Steps to Reproduce:

1. Login into admin.alwaysdata.com.
2. Go to https://admin.alwaysdata.com/search/?q=1.
3. Input &q= after q=1
4. Input long string which is attached below in the report.
5. You can see that Chrome are crashed and not responding.

Impact:

When attacker can send this https://admin.alwaysdata.com/search/?q=1&q=longstring to any authenticated user, his/her browser was crashed for long time.

#Note:

Tested in Chrome, Mozilla and Microsoft Edge.

Thank You,

Waleed Anwar

#Attacker Can Force to Stop Victim to Forget their Account Password in admin.alwaysdata.com.

Hello Sir, I hope you are doing well. While, Researching on your domain, I found Attacker Can Force to Stop Victim to Forget their Account Password in admin.alwaysdata.com.

Steps to Reproduce:

1. Go to https://www.alwaysdata.com/en/register/ for Signup.
2. Input Meow.bow+evil@domain.com.Burp Collab and then input password and click on submit to register your account.
3. Verify this account and after login and then logout from the account.
4. Register another account in https://www.alwaysdata.com/en/register/.
5. Input Meow.bow+evil1@domain.com.Burp Collab and then input password and click on submit to register your 2nd account.

6.After that verify your 2nd account in admin.alwaysdata.com.
7.Registering two account in admin.alwaysdata.com and then go to https://admin.alwaysdata.com/password/lost/ to forget their account.

8. Input first and second account email to forget their password but you can see that when you click on reset button it should say that email doesn't have account register.

Impact:

When victim register their account with email Meow.bow+evil@domain.com.Burp Collab and attacker know victim email then he/she can use abuse email Meow.bow+evil1@domain.com.Burp Collab to register the account, If victim forget their password and victim want to forget their password with https://admin.alwaysdata.com/password/lost/, victim lost their account can can't forget their account.

#Note:

Try to remove symbols in email to prevent from this.

Thank You,

Waleed Anwar

#No limit in email length may result in a possible DOS attack in admin.alwaysdata.com

From the page: https://admin.alwaysdata.com/profile When I tried to update the email address, I noticed that the database field was allocating 255 characters there and if the input was more than 255 character that field was truncating.
For example:

haxorsistz+axorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxoailrsistzh@gmail.com

You will see that the long email is readily accepted and there is no fixed length for this user input parameter.

Mitigation: The email parameter must have a specific user input length

Impact
An attacker can store a large email address as per his requirement which will possibly lead to a DOS attack / Buffer Overflow.

Thank You,

Waleed Anwar

#No email verification required when we change email from settings

Hello Team,

Issue:
When we try to signup with an email, it asks us for clicking a email validation link which is sent to our email, then we have to login, without clicking that link, we cannot login, but when we change email from user settings page/edit settings page, it doesn't asks us for validation..

Impact:
For example, a user creates an account with his email (user@example.com) and verifies it using the link which has been sent to his email, as he/she have access to user@example.com, but next he goes to settings and in email change mechanism, he can put any email like (president@whitehouse.gov) and no verification is required, and the user can login with that email and access his account with the email president@whitehouse.gov, and do some abusive or not good activities and the company will be blamed!

New steps to reproduce:
Go to profile settings
Enter any email
Submit settings → Account will be accessible without verification!

How to fix?
Email verification/validation should be required when a user changed email from user settings page..
I hope you'll fix it soon.

Thank You,

Waleed Anwar

# Weak password policy in Webmail.alwaysdata.com

Hello Team, I hope you are doing well. While, Researching in your domain I found Weak password policy in Webmail.alwaysdata.com.

I get to know that you are using strong password policy.
I gone through application and checked for that.
and get to know that as per ISO9001 security compliance weak password policy.

#Steps to Reproduce:

1. Login into https://admin.alwaysdata.com/login/.
2. Go to https://admin.alwaysdata.com/mailbox/ and Change Password to 👨‍👩‍👧‍👦.
3. Password will be Changed to 👨‍👩‍👧‍👦.

Impact:

Use Strong Password Policy and remove these Unicode Character's.

Thank You,

Waleed Anwar

# Insecure Cache-Control Leading to View Email and Message's in https://www.alwaysdata.com/en/abuse/

Hello Team, I hope you are doing well. While, Researching in your domain I found Insecure Cache-Control Leading to View Email and Message's in https://www.alwaysdata.com/en/abuse/

# Steps to Reproduce:

1. Go to https://www.alwaysdata.com/en/abuse/.
2. Fill the form and submit it.
3. Visit every page in url or press back button in browser you can see that email or any sensitive message's are already feeded.

# Impact:

In a PC scenario in an office or in a library or in a coffee shop to view sensitive message's and email also.

# Note:

Tested in Chrome latest version, Mobile Device, FireFox and IE.

Thank You,

Waleed Anwar

# Summary:
The discovered vulnerability allows for the bypass of Two-Factor Authentication (2FA) mechanisms through the exploitation of leaked cookies. By intercepting and utilizing these cookies, an attacker can gain unauthorized access to user accounts without the need for the second authentication factor, compromising the security of the system.

# Steps To Reproduce:
1.Navigate to the account settings and enable 2FA.
2.Log out and log back in using valid credentials.
3.Enter the required 2FA code to proceed.
4.Export session cookies using a cookie editor tool.
5.Paste the copied cookies into another browser
6 Access the account without providing the 2FA code,2FA Authentication bypassed.

# Mitigation:
Introduce device-based Two-Factor Authentication (2FA) mechanisms that require additional verification steps when signing in from new or unrecognized devices, browsers, or locations. This adds an extra layer of security by verifying the identity of the user and the device being used for authentication.

# Impact:
The vulnerability allows attackers to bypass Two-Factor Authentication (2FA) mechanisms by stealing and utilizing session cookies obtained through various means, such as man-in-the-middle (MITM) attacks using tools like Evilginx2. By exploiting this vulnerability, attackers can gain unauthorized access to user accounts without the need for the second authentication factor, compromising the security of the system and potentially leading to unauthorized data access, fraudulent transactions, or other malicious activities.

Thank You,

Waleed Anwar

# Insecure Cache-Control Leading to View Email and Password in https://webmail.alwaysdata.com/?from_roundcube=1.

Hello Team, I hope you are doing well. While, Researching in your domain I found Insecure Cache-Control Leading to View Email and Password in https://webmail.alwaysdata.com/?from_roundcube=1.

# Steps to Reproduce:

1. Login to https://webmail.alwaysdata.com/?from_roundcube=1.
2. Visit every Pages in https://webmail.alwaysdata.com/?from_roundcube=1 after the login.
3. Logout from the account.
4. Click Back Button 9 to 10 times.
5. You can get your email and password in the Login form. ( Toggle to See the Password)

# Impact:

In a PC scenario in an office or in a library or in a coffee shop or such places allow for an attacker to exploit this vulnerability (since the amount of pages visited after visiting doesn't matter). Also it is very easy to get access to a laptop, so this is a likable scenario, and once it happens the attacker has full control over the victim's app data since he/she can use the account.

# Note:

Tested in Chrome latest version, Mobile Device.
Doesn't exploitable in FireFox.

Thank You,

Waleed Anwar

#Account creation with invalid email addresses / email is accepting % and %0d%0a line termination chars

Hello Team, I hope you are doing well. While, Researching in your domain. I found Account creation with invalid email addresses / email is accepting % and %0d%0a line termination chars in your domain in admin.alwaysdata.com.

Summary:
Alwaysdata SignUp feature is misconfigured with email parameter. Email address parameter is accepting % and %0d%0a character along with genuine email address. Using this technique alwaysdata user account can be created but cannot be verified as there is not possible to verify those invalid email accounts. Basically random use of invalid email address, attacker can create multiple accounts.

Description:
As email address field always being verified with any special character (except @ and .) but here email is accepting % and line termination char %0d%0a

#Steps to Reproduce:

1.SignUp in admin.alwaysdata.com
2.Use email address adding with character like % or %0d%0a, account will be created and you will get account validation message.

3.Even if you try now to login using same above email and password then you will get same message for account validation and need to verify email.
4.You can not use the same invalid email again, as it will show an error of reuse of that invalid email address.

Impact
Garbage value can be stored in database using user account signup form
Multiple account can be created, just like if any use has real account with his email address, then also account can be created by adding %0d%0a or % char
Account is created using invalid email address, but can not be used.

Thank You,

Waleed Anwar

Hello Team,

I hope you are doing well. While researching in your domain, I found User can Create Token after Disabling 2fa.

Steps to Reproduce:

1. Login into your account admin.alwaysdata.com
2. Go to Profile Section and enable 2fa for Generate Token.
3. 2fa is Enabled and now you can Generate a Token.
4. After then, Disable 2fa and don't refresh the page and don't logout from your account, you can click on Generate Token Button and if you can see that You can Generate Token after disabling 2fa.

Impact:

User Can Create Multiple token after disabling 2fa, which is the bypass of 2fa also.

Thank You,

Waleed Anwar

#2FA is not Initiating on User Account

Hello Team, I hope you are doing well. While Researching in your domain I found 2Fa is not Initiating on User Account in your domain.

Steps to Reproduce:

1: Create a account in admin.alwaysdata.com.
2. Initiate 2fa on your account.
3. Go to Permission Section Add a Email in email Section and Check the 2fa Required box and make some Global Permission you want to proceed and then submit.

4. User receive Profile Initialization in your email, User can fill the form and then submit the form, he/she directly login on o your account without any 2fa Initialization in which administrator can check the 2fa required box.

Impact:

Administrator can imagine he/she initiate 2fa requirement on user account but 2fa is enabled on user account. User can easily access their account and admin permission without 2fa prompting.

Thank You,

Waleed Anwar

Failure to invalidate sever after password change in Webdav

Hello Team,

I hope you are doing well. While Researching in your domain I found Failure to invalidate server after password change vulnerability in your domain.

Steps to Reproduce:

1.Go to https://admin.alwaysdata.com/webdav/ and set a password for user and then submit.
2.Then, go to your PC to Connect Webdav Server with your Windows/Linux.
3.Again go tohttps://admin.alwaysdata.com/webdav/ and then change the password and submit it.
4.You can see that server is still validated and files are accessible in your webdav server which is connected with your PC.

Impact
If attacker have gain access in someone Pc, he/she access these files without any error. As server is not destroyed, attacker will be still access these files, cause his server is still active.. Server should be destroyed can take effect immediately when password is changed.

Thank You,

Waleed Anwar

#CSRF TOKEN BYPASS WITH GET REQUEST.

Hello Team, I hope you are doing well. While, Researching in your domain I found Csrf Token Bypass with Get Request Method.

#Steps to Reproduce:

1. Login https://webmail.alwaysdata.com/?from_roundcube=1.
2. Go to https://webmail.alwaysdata.com/roundcube/?_task=settings&_action=folders and Click on Save Button and Capture the Post Request in BurpSuite.

3. You got the POST request like this.

POST /roundcube/ HTTP/1.1
Host: webmail.alwaysdata.com
Cookie: csrftoken=xxxxxxxxxxxxxxxxxxxxxxx; roundcube_sessid=xxxxxxxxxxxxxxxxx; mailviewsplitterv=165; mailviewsplitter2=405; prefsviewsplitter=195; colorMode=light; sessionid=xxxxxxxxxxxxxxxxxxxxxxxxxxx; roundcube_sessauth=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.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://webmail.alwaysdata.com/roundcube/?_task=settings&_action=add-folder&_mbox=&_framed=1 Origin: https://webmail.alwaysdata.com Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: iframe
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=4
Te: trailers
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 89

_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&_framed=1&_task=settings&_action=save-folder&_name=test&_parent=INBOX&_viewmode=0

4. Change the POST Request to GET and remove the token into null request.
5. Send this request to someone, he/she create folder without token and CSRF Protection also bypassed.

#Before Changing the Request(POST Method):

REQUEST CHECK FAILED
For your protection, access to this resource is secured against CSRF.
If you see this, you probably didn't log out before leaving the web application.

Human interaction is now required to continue.
Please contact your server-administrator.

# After Changing the Request(GET Method):

Location
Folder name
Parent folder

— Settings
List view mode

List

Thank You,

Waleed Anwar

#PHP info page disclosure

Hello Team, I hope you are doing well. While Researching on your domain, I found PHP info page disclosure.

Steps to Reproduce:

1.Ping www.alwaysdata.net
2.Found 185.31.40.5
3.Next thing I did was a Whois request on that domain to find the Netrange of this IP Address.
inetnum: 185.31.40.0 - 185.31.40.255
netname: ALWAYSDATA-PARIS1
country: FR
admin-c: ALWS1-RIPE
tech-c: ALWS1-RIPE
status: ASSIGNED PA
mnt-by: ALWAYSDATA
created: 2024-09-24T12:04:24Z
last-modified: 2024-09-24T12:04:24Z
source: RIPE

4.Then I wrote a bash script to find Sensitive Data on IP Address.
#!/bin/bash
for ipa in 185.3{1..0}.{40..255}.{0..255}; do
wget -t 1 -T 5 http://${ipa}/phpinfo.php; done &
and yes the result was the one i’ve found above.

5. I found http://185.31.41.136/phpinfo.php

An attacker can obtain information such as:
Exact PHP version.
Exact OS and its version.
Details of the PHP configuration.
Internal IP addresses.
Server environment variables.
Loaded PHP extensions and their configurations and etc.

Impact
This information can help an attacker gain more information on the system. After gaining detailed information, the attacker can research known vulnerabilities for that system under review. The attacker can also use this information during the exploitation of other vulnerabilities.

Thank You,

Waleed Anwar

Failure to invalidate session after password change

Hello Team,

I hope you are doing well. While Researching in your domain I found Failure to invalidate session after password change vulnerability in your domain.

Steps to Reproduce:

1.Go to https://admin.alwaysdata.com/mailbox/id/ and set a password and then submit.
2.Then, go to another browser and login into https://webmail.alwaysdata.com/?from_roundcube=1.
3.Again go to https://admin.alwaysdata.com/mailbox/id/ and then change the password and submit it.
4.You can see that session is still login in https://webmail.alwaysdata.com/?from_roundcube=1 and you can make any Changes in https://webmail.alwaysdata.com/?from_roundcube=1.

Impact
If attacker have user password and logged in different places, As other sessions is not destroyed, attacker will be still logged in your account even after changing password, cause his session is still active.. Malicious actor can complete access your account till that session expires! So, your account remains insecure even after the changing of password.

Thank You,

Waleed Anwar

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

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