The security of our products is very important to us, and we constantly strive to guarantee our users' security. The deriv.com security team aims 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
- 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 Deriv’s services
- changing, copying, or stealing data from related system services
- 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 change, degrade, damage, or destroy information within our systems or that may impact or affect our users.
- 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.
- Do not mass create accounts, only create accounts necessary for your testing
- Only interact with accounts you own or with the explicit permission of the account holder.
- Do not incur loss of funds that are not your own
- No destructive automated testing. Under no circumstance should automated testing cause intentional damage to our systems
- Do not publicly disclose vulnerabilities without our explicit consent
- Social engineering (e.g., phishing, vishing, smishing) is prohibited.
- Always be respectful when interacting with our team
- When conducting research always follow our guidelines set out in Test plan
- The final assessment of each vulnerability is determined by the impact, risk, and current mitigation measures. Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.
- 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.
Test plan
- In order for us to separate testing traffic from real user traffic, we ask that you include a unique HTTP header to each and every testing request. Please use format "X-HackerOne-Research: [H1 username]"
- Our assets are self sign up, please use your [username]@wearehackerone.com email alias for any accounts created on our assets
Response targets
We will make our best effort to meet the following response targets for hackers participating in our program, however these are dependent on severity and complexity:
- Time to first response (from report submission): 2 business days
- Time to triage: 2 business days
- Time to bounty (from triage): 2 business days
We will aim to keep you informed throughout the process.
Disclosure policy
Do not publicly or privately disclose this program or any vulnerabilities (even resolved ones) outside the program without prior written consent from deriv.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.
Eligibility to Participate
To participate in our Bug Bounty Program, you must:
- Abide by the terms and conditions of Deriv.com
- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to our Bug Bounty Program.
- Not be employed by Deriv or any of its affiliates or an immediate family member of a person employed by Deriv or any of its affiliates.
- You are responsible for any tax implications of a reward from our Bug Bounty Program depending on your country of residency and citizenship.
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.
Categorisation
Important businesses:
- cashier.deriv.com
- oauth.deriv.com
- Websocket API on deriv.com (see api.deriv.com)
- https://app.deriv.com/bot (Deriv's trading bot functionality)
- https://app.deriv.com
- https://smarttrader.deriv.com
- MetaTrader 5 (only functions handled by deriv.com)
- *.deriv.cloud
General businesses:
Edge businesses:
- *.deriv.com (excluding any deriv.com subdomains not mentioned above)
- *.binary.com (legacy)
- https://hub.docker.com/u/deriv
- Any issues in 3rd party apps
- Deriv X: Our CFD trading app by DevExperts (Android app, iOS app)
https://dx.deriv.com
https://play.google.com/store/apps/details?id=com.deriv.dx
https://apps.apple.com/by/app/deriv-x/id1563337503
- https://ct.deriv.com/ trading app by ctrader (Android app, iOS app)
- https://academy.deriv.com/
- 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 $5,000 |
| General business | Up to $2,000 |
| Edge business | Up to $1,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 $2,500 |
| General business | Up to $1,500 |
| Edge business | Up to $500 |
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)
- 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
Bounties for LOW Vulnerabilities
We will triage reports of low-severity vulnerabilities, and you will receive reputation points, but we will only reward important business issues.
| Business type | Bounty |
|---|
| Important business | Up to $100 |
| General business | Up to $50 |
| Edge business | Up to $50 |
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
- Issues in 3rd party app myaffiliates.
- Issues in 3rd party support chatbox (Livechat/freshworks).
- Clickjacking without any impact
- Jira service desk signup public allowed on https://deriv.atlassian.net/servicedesk/customer/user/signup (its not owned by deriv)
- XMLRPC related brute-force/enumeration/DDoS Attacks
- Firebase DB open without sensitive information
- Design flaws and best practices that do not lead to security vulnerabilities
- Vulnerabilities that are no threat to deriv.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. https://hackerone.com/deriv/safe_harbor
For any questions, please contact us at [email protected]. Thanks for keeping our business and our customers secure!
