At BeesApps we take security very seriously. If you believe that you have found a security vulnerability on Beesy.com, we encourage you to let us know straight away. 

Process

Your submission will be reviewed and validated by a member of the Product Security Team.

When investigating a vulnerability, please, only ever target your own accounts. Never attempt to access anyone else’s data and do not engage in any activity that would be disruptive or damaging to other users. Depending upon the severity of your issue, it may take us time to respond to you.

• When submitting a vulnerability, please provide concise steps to reproduce that are easily understood.
• In the case the same vulnerability is present on multiple products, please combine and send one report.
• When duplicates occur, we consider the first report that was received to be treated as unique, and subsequent reports will be marked as a duplicate.

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

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

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

Any design or implementation issue that substantially affects the confidentiality or integrity of user data is likely to be in scope for the program. Common examples include:

• SQL Injection.
• Finding unwanted numeric user id (even yours) in views, that allow you to forge requests.
• Exposure of Sensitive members information
• 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 (JS, SQL, PHP, …).
• Cross-Site Scripting (XSS).
• Cross-Site Requests Forgery (CSRF) with real security impact.
• Mixed-content scripts
• 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.
• Authentication or authorization flaws
• Server-side code execution bugs

Out of concern for the availability of our services to all users, please do not attempt to carry out DoS attacks, leverage black hat SEO techniques, spam people, brute force authentication, or do other similarly questionable things. We also discourage the use of any vulnerability testing tools that automatically generate very significant volumes of traffic.

Non-Qualifying Vulnerabilities

Depending on their impact, some of the reported issues may not qualify. Although we review them on a case-by-case basis, here are some of the issues that typically do not earn a monetary reward:

• HTML Injection as it is part of the user features
• 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 third-party applications we provide to our customers but aren’t part of our system directly (phpMyAdmin, Roundcube Webmail, etc.), if the vulnerability doesn’t directly exposes customers data and/or metadatas.
• Reports on third-party applications that we provide to our customers but are not directly part of our system (phpMyAdmin, Webmail Roundcube, etc.), unless the vulnerability that exposes user data and/or metadata is fixed for more than a month in the upstream version and we are not up to date.
• Reports about know vulnerabilities in sub-component parts (e.g. OpenSSH) that are just 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.
• Reports about vulnerabilities from third-party applications that we use that are either unknown, unfixed or fixed in unreleased versions.
• Bugs requiring exceedingly unlikely user interaction
• Non security related bugs (e.g. disclosure of server/software versions)
• Abuse
• Phishing

Eligibility and Responsible Disclosure

We are happy to thank everyone who submits valid reports which help us improve the security of BeesApps . 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 above).
• Any vulnerability found must be reported no later than 24 hours after discovery and exclusively through an email send to [email protected]
• You must send a clear textual description of the report along with steps to reproduce the issue using standard Linux tools. We may ask you to send a proof of concept that reproduces the vulnerability (e.g. a shell script).
• 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 BeesApps, or one of its contractor.

 

REWARD AMOUNTS FOR SECURITY VULNERABILITIES

LEGAL POINTS

 

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 “authorized” 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 above to ensure that your proof of concept is detailed enough to demonstrate the issue and still follows the guideline listed above.

We are unable to issue rewards to individuals who are on sanctions lists, or who are in countries (e.g. Cuba, Iran, North Korea, Sudan and Syria) on sanctions lists. You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon your local law. This is not a competition, but rather an experimental and discretionary rewards program. You should understand that we can cancel the program at any time and the decision as to whether or not to pay a reward has to be entirely at our discretion. Of course, your testing must not violate any law, or disrupt or compromise any data that is not your own.