NiceHash welcomes user contributions to improve the security of the NiceHash platform in the form of responsible disclosure.
What is responsible investigation and disclosure?
- Target only items and URLs specified in the scope bellow.
- Don’t violate the privacy of other users or target other users, destroy data, or disrupt services.
- Target only your own accounts in the process of discovering the bug.
- Don’t use DDOS attacks, spam, or social engineering attacks.
- Report the bug only to NiceHash and not to anyone else.
To minimize the risk of executing security tests you should use the NiceHash public test environment at https://test.nicehash.com, where you can transfer and user test cryptocurrencies without some compliance related limitations (KYC is not required, you can open multiply accounts...).
What is in the scope?
- NiceHash Web Client at test.nicehash.com
- NiceHash Mobile Clients available at App Store and Google Play.
- NiceHash API interface available at api-test.nicehash.com
What is out of the scope?
Please do not report any of the following:
- 3rd party mining plugins included in the mining clients are not in scope!
- Any software/service not operated by NiceHash.
- Any type of DDOS attack.
- TLS cyphers.
- Attacks requiring MITM or physical access to or malware presence on a user's device.
- Previously known vulnerable libraries without a working Proof of Concept.
- Missing best practices without providing a working abuse scenario.
- Missing HttpOnly or Secure flags on cookies.
- Clickjacking on pages with no sensitive actions.
- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions.
- Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version].
- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).
- Standard/recommendation compliance - only repeatable scenarios with an actual and proven security risk will be rewarded, standard or recommendation non-compliance or any other theoretical risk will not be accepted.
- All infrastructure is cloud based, infrastructure itself is out of the scope, misconfigured cloud services are in scope.
API Documentation
All NiceHash clients (web, mobile, bots...) use same API calls documented on link: https://test.nicehash.com/docs/ where you can also test public and private API calls. You can generate your own API keys inside of platform if you would like to use some tools for testing automatisation, you can find examples here https://github.com/nicehash/rest-clients-demo.
How to get testnet crypto coins
NiceHash test platform supports testnet blockchain coins - you can get testnet crypto coins for free and fully test all functionalities of the platform.
To get testnet crypto coin:
- Do internet search on BTC faucet testnet (replace BTC with coin you would like to obtain).
- In faucet web page, enter your deposit address from NiceHash test platform for that coin and follow the instructions of faucet page.
- You should receive testnet coins as deposit to your account on the test NiceHash platform after some time (this time may from few hours to a few days, as testnet blockchains are not always fully operational). To be sure that you will get enough testnet coins quickly, use several different faucet to obtain different coins.
Credentials
An account is required for accessing private web pages and private API calls:
- You can self register on the platform using a valid email, Google or Apple account here https://test.nicehash.com/my/register
- After registration, user can only browse the platform until (s)he finishes KYC identification. In the test environment the real documents and data are not required to pass KYC, researcher can just open https://test.nicehash.com/my/settings/limits, press Verify and enter any data to activate the platform financial functionality on the test account. Please do not run security tests on this KYC simulation itself as it is not same as production and is not in the scope.
- Mobile clients available from official applications stores are connecting to the production platform.
- NiceHash platform was designed to require users to select strong passwords without length limitation (no DDos), email OTP token is used until user activates device 2FA.
- Users are encouraged to activate 2FA on their device (like Google authenticator on user phone and/or Yubikey), depending on an evaluated risk some actions might require use of an email one time used time limited token, 2FA OTP token or both.
- In the staging environment only, researchers can also use 123456 instead of 2FA/email authentication token - This was enabled to simplify scripting/automation of your tests, please do not report this as bug. Feel free to verify that this is not possible in NiceHash production environment.
How can I report bugs?
You can send your findings to the following email: [email protected]
Your report has to provide a proof-of-concept scenario that we can use to repeat your findings and confirm the existence of the reported vulnerability.
When do I qualify for a reward?
Security issues that typically would be eligible (though not necessarily in all cases) include:
- Unauthorized data access or manipulation
- Cross-Site Request Forgery (CSRF)
- Cross-Site Scripting (XSS)
- Code Injection
- Remote Code Execution
- Local or Remote File Inclusion
- Privilege Escalation
- Authentication or Authorization Bypass
- Clickjacking
- Leakage of Sensitive Data
To qualify for a reward, our analysis has to confirm that reported vulnerability presents an actual and severe risk to the security or privacy of our users or business.
For example, reported and confirmed vulnerability that enables the attacker to steal Bitcoins from user wallets is considered high risk and will be rewarded; finding of non-compliance with some industry-standard recommendation without proof that it can be used against NiceHash users or platform will not be rewarded.
For every reported finding, we will use the reported scenario to confirm reported vulnerability, and then we will evaluate risk based on our evaluation methodology considering the vulnerability exploit likelihood and consequences.
How are rewards calculated and paid?
Rewards are calculated according to the NiceHash internal policy and are not negotiable.
Only one reward per bug - the reward will be paid to the first reporter.
Rewards will be paid only if you followed all necessary steps of the responsible investigation and disclosure.
Rewards are paid out only in Bitcoin (BTC), so you will need a BTC wallet - you can use the wallet on the NiceHash platform if you don't already have one.