RBKmoney Vulnerability Disclosure Program policy
If you found a security vulnerability at any of RBKmoney services, let us know. We will review all legitimate reports and do our best to quickly fix the issue. Before reporting vulnerability, check out the materials on this page including information disclosure policy and vulnerabilities that should not be reported.
Program scope and terms
The Program's scope involves the following RBKmoney domains:
If you are unsure whether a service is eligible for Program or not, feel free to ask us.
+ Use your own test accounts for vulnerability research. Do not interact with other accounts without their owner permission.
+ Avoid breach of data confidentiality.
+ Do not use discovered vulnerabilities for your own benefit. This includes demonstrating additional risks, attempting to disclose confidential data or finding other problems.
+ Do not use any vulnerability testing tools that automatically generate very significant volumes of traffic.
+ Do not perform any attack that could harm the reliability / integrity of our services or data (denial-of-service attacks, etc.).
+ Do not try sneaking into RBKmoney offices and data centers.
+ Do not perform spamming and social engineering attacks against our clients and employees and do not carry out other similarly questionable things.
* Any design or implementation vulnerability that substantially affects the confidentiality or integrity of data is likely to be in scope for the Program. Common examples include:
* server-side code execution vulnerabilities
* authentication or authorization vulnerabilities
* business logic vulnerabilities
* cross-site request forgery
* cross-site scripting
Scope of the Program is limited to technical vulnerabilities in our services and web applications.
We do not accept and review reports generated by automated vulnerability scanners and reports of:
* CSRF for non-significant actions (logout, etc.)
* Self-XSS without demonstration of real security impact for users or system
* framing and clickjacking vulnerabilities without a documented series of clicks that produce a real security impact
* lack of security mechanism / inconsistency with best practices without demonstration of real security impact
* not enforced SSL/TLS, use of insecure SSL/TLS ciphers
* attacks which require full access to passwords, tokens, browser profile or local system
* non-sensitive information disclosure (such as product or protocol version)
* bugs that don’t affect the latest version of modern browsers and bugs related to browser extensions
* vulnerabilities that only affect users with specific browsers
* attacks requiring exceedingly unlikely user interaction
* denial-of-service attacks or vulnerabilities related to rate limiting
* timing attacks, that prove the existence of a user account, etc.
* insecure cookie settings for non-sensitive cookies
* bugs in content / services that are not owned or operated by RBKmoney (include third party services operating on our subdomains)
* vulnerabilities that RBKmoney determines to be an accepted risk
* scripting or other automation, brute forcing of intended functionality and parameters (include invoice, url-shortener payment link brute forcing, etc.)
* weak password policy
Vulnerability report requirements
By submitting a bug report you agree to comply with RBKmoney information disclosure policy.
A bug report must contain a detailed description of the discovered vulnerability:
* vulnerable hosts and components
* discovered vulnerability and security impact
* reproduction steps
* attack scenario
* recommendations for remediation
Reproduction steps describes the exploitation process required, step-by-step, in the proper order.
Attack scenario describes details about how an attacker would use the bug you are submitting, any necessary conditions for it to work, and what the attacker would gain through a successful attack.
Reports that clearly and concisely identify the affected component, present a well-developed attack scenario, and include clear reproduction steps, will get triaged much faster.
We accept reports in Russian and English.
Currently we not provide awards according to HackerOne Vulnerability Disclosure Program (VDP) rules.
Information disclosure policy
Vulnerability details should be disclosed only in accordance with HackerOne disclosure guidelines (https://www.hackerone.com/disclosure-guidelines) and RBKmoney vulnerability disclosure program policy.
Public or private disclosure of the details of any vulnerability found on RBKmoney is allowed 90 days after vulnerability is fixed and only by mutual agreement of the parties.
Request for vulnerability disclosure should be filed via HackerOne report interface. No vulnerability disclosure, including partial is allowed before vulnerability is disclosed on HackerOne.
Any sensitive information accidently obtained during vulnerability research or demonstration should not be disclosed. This information includes (but not limited to) infrastructure and implementation details, internal documentation and interfaces, source code, user’s and employee’s data.
Intentional access to this information is strictly prohibited.
Hall of Fame