The security of our products is very important to us, and we constantly strive to guarantee our users' security. The Binary.com Security team hopes to raise the comprehensive security of our products by working closely with individuals, organisations, and companies. To protect the interests of our users, we thank and reward researchers who help us improve our security.

Contents

• Ground rules

• Response targets

• Disclosure policy

• General vulnerability assessment

• Vulnerabilities and reward structure

• Out of scope vulnerabilities

• Safe harbour

Ground rules

1. Respect our users’ privacy. We oppose and condemn the actions of hackers who use vulnerability testing as an excuse, for example:

   • exploiting vulnerabilities to steal user data

   • intrusion into Binary’s services

   • changing, copying, or stealing data from related system services

2. Do not cause more harm than good. You should never leave a system or users in a more vulnerable state than when you found them. You should not engage in testing or related activities that degrade, damage, or destroy information within our systems or that may impact our users, such as denial of service, social engineering, or spam.

3. When the results of the vulnerability review are disputed, we will handle the disputes according to the principle of prioritising the reporters’ interests, and, if necessary, external parties may be invited to decide and introduce the Common Vulnerability Scoring System (CVSS) standard jointly.

Response targets

We will make our best effort to meet the following response targets for hackers participating in our program:

• Time to first response (from report submission): 1 business day

• Time to triage (from report submission): 3 business days

• Time to bounty (from triage): 7 business days

We will keep you informed throughout the process.

Disclosure policy

Do not discuss this program or any vulnerabilities (even resolved ones) outside the program without consent from Binary.com.

Follow HackerOne's disclosure guidelines. If you believe you have discovered a security vulnerability, please report it with a thorough explanation of the vulnerability in compliance with our bug bounty guidelines.

General vulnerability assessment

• Please provide detailed reports with reproducible steps. If the report is not precise enough to reproduce the issue, the issue will not be eligible for a reward.

• Unverified vulnerabilities reports using automated tools or scanners will be closed as N/A or spam.

• The final assessment of each vulnerability is determined by the impact, risk, and current mitigation measures. We reserve sole discretion on final assessment decisions.

• If one vulnerability source causes several vulnerabilities, we will consider it as one vulnerability. For example, multiple problems caused by a certain server configuration, the same file or template, generic domain name resolution, and the like will be considered as one vulnerability.

• In the event of duplicate submissions, we will only award the first report received (provided that it can be fully reproduced).

• Regarding any 0-day vulnerabilities, we will only accept the report if it has been > 30 days since the relevant patch release.

• Vulnerabilities regarding information disclosure of cloud storage buckets (e.g., S3, KSS, FDS, and the like)：

  • We will confirm internally whether the information or link should be publicly accessible/viewable.

  • Confirmation of the valid vulnerability will be based on the sensitivity of information leakage and is at our sole discretion.

Vulnerabilities and reward structure

The decision to grant a reward for a vulnerability report and the value of the reward is entirely within our discretion. We will reward based on the impact and severity of the reported vulnerability. Please note that web and mobile application vulnerabilities of low severity will be triaged, but not awarded with a bounty (except in cases where the impact is severe enough to be eligible for a reward).

Categorisation

Important businesses:

• cashier.binary.com

• crypto-cashier.binary.com

• binary.com

• Websocket API on binary.com (*.binaryws.com)

• webtrader.binary.com

• binary.bot

• secure-dfadmin.binary.com

• MetaTrader 5 (only functions handled by Binary.com)

General businesses:

• github.com/binary-com

• tradingview.binary.com

• charts.binary.com

• Tick Trade mobile app

Edge businesses:

• *.binary.com (excluding any Binary.com subdomains not mentioned above)

• Some operation and maintenance monitoring, test pages, test environments, and open source systems that lack access permissions

• The list above is not exhaustive. We’ll update it according to business changes from time to time.

Bounties for CRITICAL vulnerabilities

| Business type | Bounty |

|--------------------|---------------|

| Important business | Up to $10,000 |

| General business | Up to $5,000 |

| Edge business | Up to $2,500 |

Examples of CRITICAL Vulnerabilities in WEB

• The ability to obtain sensitive user data and system permissions directly via command injection, order traversal, remote overflows, SQL injection, and the like

• Payment vulnerabilities that could potentially lead to a critical logic error, causing loss to the company and our clients

• The ability to exploit account-related vulnerabilities to obtain user details, bypass authentication, and the like

Examples of CRITICAL Vulnerabilities in MOBILE

• Severe logic vulnerabilities that could cause losses to our clients

• Remote command execution

• The ability to access and extract users’ data

Bounties for HIGH Vulnerabilities

| Business type | Bounty |

|--------------------|--------------|

| Important business | Up to $5,000 |

| General business | Up to $2,500 |

| Edge business | Up to $1,000 |

Examples of HIGH Vulnerabilities for WEB

• Accessing read-only back-end code and manipulate our systems

• Accessing internal session cookies and other sensitive information

• Bypassing verification (OTP, 2FA), log in to client accounts, extract clients’ sensitive data, and perform actions without consent

• Causing damage to critical functions via privilege escalation (horizontal and vertical)

• Obtaining sensitive intranet information via server-side request forgery (SSRF)

• Manipulating trade contracts to earn profit

Examples of HIGH Vulnerabilities for MOBILE

• Bypassing the lock screen (where applicable)

• Exploiting interactive logic issues that can cause loss to clients

• Gaining remote access to clients’ sensitive information

• Installing malicious apps on clients’ devices, gain access to their accounts, and perform actions without their consent

Bounties for MEDIUM Vulnerabilities

| Business type | Bounty |

|--------------------|------------|

| Important business | Up to $500 |

| General business | Up to $250 |

| Edge business | Up to $100 |

Examples of MEDIUM Vulnerabilities for WEB

• The ability to access a limited portion of:

  • client’s sensitive information

  • our back-end code

  • internal information on GitHub

• Attacks via:

  • cross-site and server-side request forgery (without access to our internal network)

  • directory traversals

  • privilege escalation (causing damage to functional properties of our systems)

  • reflected and stored cross-site scripting with minimum impact (including unauthorised file uploads on our servers to enable phishing)

  • social engineering attempts (that prompt the user to perform unusual actions on our platforms)

  • subdomain takeovers

Examples of MEDIUM Vulnerabilities for MOBILE

• The ability to exploit interface logic vulnerabilities to deceive our clients or to enable phishing

• Attacks via SQL injection with the ability to access sensitive information in local applications

We will triage reports of low-severity vulnerabilities, and you will receive reputation points, but we will not reward them unless the impact is severe enough.

Examples of LOW Vulnerabilities for WEB

• Attacks via:

  • cross-site request forgery (non-critical)

  • ‘HTTP Host Header’ cross-site scripting

  • mail/SMS bombing

• The ability to access:

  • non-sensitive information on third-party platforms like GitHub

  • non-sensitive .svn or .git files

  • phpinfo()

  • temporary files and debug information

Examples of LOW Vulnerabilities for MOBILE

• The ability to:

  • access low-risk back-end information

  • exploit vulnerable app configurations

  • exploit vulnerabilities in complex, unusual conditions

  • hijack app upgrades

  • load URLs arbitrarily through a component that’s exposed to phishing

  • obtain clients’ data via social engineering

  • obtain non-sensitive information from local apps via SQLite injection

Out of scope vulnerabilities

When reporting vulnerabilities, please consider the attack scenario/exploitability and the security impact of the bug.

The following issues are considered out of scope and will be closed as N/A:

Web

• Design flaws and best practices that do not lead to security vulnerabilities

• Vulnerabilities that are no threat to Binary.com or other users, for example, self XSS, having a user paste - JavaScript into the browser console etc.

• Exposure of third-party API keys with no significant security impact

• Theoretical vulnerabilities without a working proof of concept (PoC)

• Theoretical subdomain takeovers

• Minimal security implications such as low impact CSRF (login/logout), low-impact UI redressing, misconfiguration that lead to CORS bypass but without any sensitive information leak

• Content spoofing/text injection that cannot be leveraged for XSS or sensitive data disclosure

• Session not invalidated after logout

• Insensitive disclosure of information such as error message, software version disclosure, IP address disclosure, etc.

• Arbitrary file upload without any impact

• Vulnerabilities that can only be reproduced by some low-level IE browsers

• HTTP codes/pages, other HTTP non- codes/pages, or etc/insensitive information files

• Public links, such as social media profile pictures, live videos, etc.

• Reflected file download attacks

• SSRF vulnerability that does not expose intranet server information (only DNS request without any impact)

• Issues related to payment providers such as skrill.com, paypal.com etc.

• Misconfigurations such as:

  • DNS issues (e.g., MX records, SPF records, etc.)

  • Reports of insecure SSL/TLS cyphers (unless you have a working proof of concept and not just a report from a scanner)

  • Presence of autocomplete attribute on web forms

  • Mixed content warnings

  • Missing security-related HTTP headers that do not directly lead to a vulnerability

Mobile

• Absence of certificate pinning

• Sensitive data in URLs/request bodies when protected by TLS

• Unencrypted user data stored on external storage (except for APP logs with sensitive information or user data for which encryption has been promised)

• Lack of obfuscation

• OAuth and app secrets that are hard-coded/recoverable in APK without proven impact

• Any kind of sensitive data protected by the app’s private directory

• App setting allowBackup: true

• Local DoS attacks with limited impact

• Malformed intents sent to exported components that only causes the app to crash

• Any data leak because a malicious app has acquired the appropriate permissions

• Runtime hacking exploits using tools like, but not limited to, Frida and Appmon

• Exploits that are only possible in a jailbroken environment

• Spoofing vulnerabilities

• Attacks that are only available in lower versions of Android (< 6)

Safe harbour

Any activities conducted in a manner consistent with this policy will be considered authorised conduct, and we will not initiate legal action against you. If a third party initiates legal action against you in connection with activities conducted under this policy, we will make it known that your actions have complied with this policy.

For any questions, please contact us at security@binary.com. Thanks for keeping our business and our customers secure!