Bug Bounty Program

About alwaysdata

alwaysdata and its subsidiaries constitute a hosting provider that offer a PaaS solution for everyone since 2006, but is particularly focused on developers everyday-use.

alwaysdata's platform is designed to host hundreds of accounts on each server. Each account get a full access to all wanted interpreters, various databases, email accounts, brokers (for VPS and Dedicated servers), backups, various remote access, an API to control settings, etc. Each account can host as many websites as wanted.

Program Rules

We believe that no technology is perfect and that working with skilled security researchers is crucial to identify weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.

Let us know as soon as possible upon discovery of a potential security issue, and we'll make every effort to quickly resolve the issue. Provide us a reasonable amount of time to resolve the issue before any disclosure to the public or a third-party.

Test vulnerabilities only against accounts that you own or accounts that you have permission from the account holder to test against.

Never use a finding to compromise/exfiltrate data or pivot to other systems. Use a proof of concept only to demonstrate an issue.

If sensitive information -- such as personal information, credentials, etc. -- is accessed as part of a vulnerability, it must not be saved, stored, transferred, or otherwise accessed after initial discovery. All sensitive information must be returned to alwaysdata and any copies of such information must not be retained.

Any type of denial of service (DDoS) attacks is strictly forbidden, as well as any interference with network equipment and alwaysdata infrastructure.

Do not try to over exploit the bug and access internal data for further vulnerabilities. We will determine the severity and reward accordingly.

If you find the same vulnerability several times, please create only one report and eventually use comments. You'll be rewarded accordingly to your findings.

Violation of any of these rules can result in ineligibility for a bounty and/or removal from the program.

Legal considerations

We will not pursue civil action or initiate a complaint to law enforcement for accidental, good faith violations of this policy. We consider activities conducted consistent with this policy to constitute “authorised” conduct. We will not bring a claim against you for circumventing the technological measures we have used to protect the applications in scope of this program.

If legal action is initiated by a third party against you and you have complied with this security policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

It is also important to note, we will not take legal action against you simply for providing us with a proof of concept of the security vulnerability. Please follow the guidelines listed in the Proof of concepts section below to ensure that your proof of concept is detailed enough to demonstrate the issue and still follows the guideline listed above.

Scope and Testing

• https://www.alwaysdata.com
• https://admin.alwaysdata.com
• https://webmail.alwaysdata.com
• https://api.alwaysdata.com
• ssh://ssh-<accountid>.alwaysdata.net
• https://webdav-<accountid>.alwaysdata.net
• ftp://ftp-<accountid>.alwaysdata.net

Vulnerabilities reported on other services or applications are not allowed.

Provide your IP address in the bug report. We will keep this data private and only use it to review logs related to your testing activity.

Include a custom HTTP header in all your traffic. Burp and other proxies allow the easy automatic addition of headers to all outbound requests. Report to us what header you set so we can identify it easily. For instance:

• A header that includes your username: X-Bug-Bounty:Hacker-<accountid>
• A header that includes a unique or identifiable flag X-Bug-Bounty:ID-<sha256-flag>

When testing for a bug, please also keep in mind:

• Use test accounts so as not to inadvertently compromise the privacy of our users
• When attempting to demonstrate root permissions with the following primitives in a vulnerable process please use the following commands:
  • Read: `cat /proc/1/maps`
  • Write: `touch /root/<accountid>`
  • Execute: `id`, `hostname`, `pwd` (though, technically `cat` and `touch` also prove execution)

Minimize the mayhem. Adhere to program rules at all times. Do not use automated scanners/tools - these tools include payloads that could trigger state changes or damage production systems and/or data.

Before causing damage or potential damage: Stop, report what you've found and request additional testing permission.

Rewards

Hall of Fame

We'll be pleased to credit you in our HoF at https://www.alwaysdata.com/en/transparency/ for your reports until patches are applied.

We mention our security partnerships on our social networks accounts (e.g. https://twitter.com/alwaysdata).

If you report critical vulnerabilities, we'll be pleased to interview you as a security researcher, and publish the interview in our blog at https://blog.alwaysdata.com/.

Swag

We offer t-shirts, swag stuff and/or vouchers as rewards for validated reports.

Cash

Our minimum reward is 50 Euros.

The following is merely an indicator of rewards, but does not reflect what the final decision might be. _We value quality reports and proofs of concepts._

Qualification	Score CVSS	Bounty
None	N/A	No Bounty
Low	0.1 - 3.9	<= 50 €
Medium	4.0 - 6.9	<= 200 €
High	7.0 - 8.9	<= 350 €
Critical	9.0 - 10.0	<= 500 €

Eligibility and Responsible Disclosure

We are happy to thank everyone who submits valid reports which help us improve the security of alwaysdata. However, only those that meet the following eligibility requirements may receive a monetary reward:

• You must be the first reporter of a vulnerability.
• The vulnerability must be a qualifying vulnerability (see below).
• Any vulnerability found must be reported no later than 24 hours after discovery.
• You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots or proof of concept code as necessary.
• You must avoid tests that could cause degradation or interruption of our service (refrain from using automated tools, and limit yourself about requests per second).
• You must not leak, manipulate, or destroy any user data.
• You must not be a former (1 year) or current employee of alwaysdata, or one of its contractor.

Reports about vulnerabilities are examined by our security analysts. If you need to encrypt payload, we strongly recommend you to use the 0x53EC46DAA71D9A1A GPG public key available on hkps://hkps.pool.sks-keyservers.net. Reports must be submitted using our ticketing interface available at https://admin.alwaysdata.com/support/. Please do not report directly by email.

Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.

Time to first response: 2 business days or less.

Time to triage: 3 business days or less.

We are continuously working to evolve our bug bounty program. We aim to respond to incoming submissions as quickly as possible and make every effort to have bugs fixed within 10 days of being triaged. Rewards will be paid when patch is applied.

No vulnerability disclosure, including partial, is allowed before the patch is applied and we agree the publication.

Proof of concepts

• XSS: For XSS, a simple alert(document.domain) should suffice.
• RCE: Please only execute harmless code. Please refer to the Testing section.
• SQLi: Report it as soon as you have a SQL error that indicates SQL injection or you are able to disclose the SQL server's version number.
• Unvalidated redirect: Set the redirect endpoint to http://example.com if possible.
• CSRF: Either attach a file to demonstrate the issue or paste the code in a code block in your report.
• SSRF: Do not go playing around on any internal networks. Report as soon as you believe that you have a potential SSRF issue and we will look into it for you.
• LFI: The same applies here — please do not go against the guideline listed in the Program Rules section. We investigate LFI reports in a dev environment to make sure it is valid.

Qualifying Vulnerabilities

• SQL Injection.
• Finding numeric user id (even yours).
• Exposure of Sensitive members information (lastname, phone number, email, physical address, physical id copy).
• Exposure of internal tools.
• Exposure of configuration files or secrets.
• Directory Traversal Issues.
• Local files access and manipulation (LFI, RFI, XXE, SSRF, XSPA).
• Local File Disclosure (LFD).
• Code injections (HTML, JS, SQL, PHP, ...).
• Cross-Site Scripting (XSS).
• Cross-Site Requests Forgery (CSRF) with real security impact.
• Server-Side Request Forgery (SSRF).
• Open redirect.
• Remote Code Execution (RCE).
• Broken authentication & session management.
• Insecure direct object references.
• CORS with real security impact.
• Missing "secure" flags on authentication cookies.
• Access Control Issues.
• Horizontal and vertical privilege escalation.

Findings not eligible for bounty

• Any hypothetical flaw or best practices without exploitable POC.
• Login, logout, unauthenticated or low-value CSRF.
• Missing security-related HTTP headers which do not lead directly to a vulnerability.
• Presence/absence of SPF/DMARC records.
• Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept).
• Mixed content warnings.
• Brute force / password reuse attacks.
• User enumeration attacks.
• Premium phone numbers attacks.
• Disclosure of known public files or directories, (e.g. robots.txt).
• Massive automated actions on the platform through robots/crawling (except if it gathers sensitive information from members).
• "Self" XSS.
• Missing cookie flags.
• SSL/TLS best practices.
• Mixed content warnings.
• Denial of Service attacks.
• "HTTP Host Header" XSS.
• Clickjacking/UI redressing.
• Software version disclosure.
• Stack traces or path disclosure.
• Physical or social engineering attempts.
• Recently disclosed 0-day vulnerabilities.
• Presence of autocomplete attribute on web forms.
• Vulnerabilities affecting outdated browsers or platforms.
• Issues that require physical access to a victim's computer/device.
• Logout and other instances of low-severity Cross-Site Request Forgery.
• Missing security-related HTTP headers which do not lead directly to a vulnerability.
• Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.
• Reports about application we provide to our customers but aren't part of our system directly (phpMyAdmin, Roundcube Webmail, etc.), except
• the vulnerability is fixed in the upstream version and we're not up-to-date to it.
• Reports about know vulnerabilities in sub-component parts (e.g. OpenSSH) that are juste being disclosed. We aim to apply security patches in 30 days or less, so reports that concern to recent disclosed vulnerabilities are not relevant.
• Reports about sites or applications hosted by our customer, except if the vulnerability is due to our platform in conjunction with the customer application.