Program rules
Supported languages
Contents
- Vulnerabilities to look for
- Vulnerabilities NOT to look for
- Participation rules
- Rewards
- Useful information
- How to register test accounts
SQL injection testing rules
When testing for SQL injection vulnerabilities, researchers must adhere to the following policy.
Only the following actions are allowed on the server:
- Get information about the current database (SELECT database()), its version (SELECT @@version), the current user (SELECT user() or SELECT system_user()), or hostname (SELECT @@hostname).
- Get the database schema (SELECT table_schema), list of tables (SELECT table_name), and table column names (SELECT column_name).
- Perform mathematical, conversion, or logical queries (including using SLEEP) without retrieving data (excluding those mentioned above).
Any other actions must be coordinated with the company.
File read and upload rules
When testing for arbitrary file read vulnerabilities or arbitrary file upload vulnerabilities on the server, researchers must adhere to the following policy.
Actions prohibited during file upload testing include the following:
- Change, modify, delete, or replace any files on the server (including system files) except for files associated with the researcher's own account or the account of a user who gave explicit consent for such actions.
- Upload files that could cause a denial of service (for instance, large files).
- Upload malicious files (such as malware or spyware).
If an arbitrary file read vulnerability is discovered on the server, the researcher is only allowed to read the /etc/ufw/user6.rules file. Any other actions must be coordinated with the company.
Vulnerabilities to look for
We are primarily interested in critical server-side vulnerabilities. Still, you're welcome to hunt for any other types of vulnerabilities. If you are unsure whether to contact us about an issue you have found, check if it's on the "Vulnerabilities NOT to look for" list. If it's not on the list, feel free to submit a detailed report.
Examples of vulnerabilities we'll be happy to reward you for are listed below (the list is incomplete and is based on the OWASP Top 10).
General
- Remote code execution (RCE)
- Injections (such as SQL and XML injections)
- LFR/LFI/RFI
- Blind SSRF
- Business logic vulnerabilities
- IDOR
- Access control vulnerabilities
- Sensitive information disclosure
- Account hijacking
- Flawed authentication/authorization
- XSS and CSRF that affect sensitive data
- Bypass of financial tools (fund withdrawal), removal of restrictions on chargeable operations and services
Vulnerabilities NOT to look for
Out-of-scope submissions include the following:
- XSS that can only be performed from a single account (regardless of the number of account users)
- Disclosure of non-confidential information, such as product versions
- Disclosure of public user information, such as usernames
- Simplified registration and authorization without CAPTCHA validation, SMS verification, or other best practices
- Reports from security scanners and other automated systems
- Vulnerability reports based solely on software or protocol versions with no credible proof of concept
- Lack of security mechanisms or non-compliance with recommendations (for example, the absence of a CSRF token) without mentioning specific negative consequences
- Logout CSRF
- Blind SSRF with no ability to scan or send requests to the internal infrastructure
- Framing
- IDN homograph attacks
- Disclosure of public information about a user or a community
- Attacks that rely on full access to a user device or page, or browser profile
- Vulnerabilities in partner services and products that do not directly affect the security of Craftum products and services
- Session fixation
- Self-XSS
- Scripting in PDF documents
- Hypothetical attacks without proof of feasibility
- Any issues related to bruteforcing
- Problems associated with validation of input data in any form without an actual vulnerability
- Any possibilities of user enumeration, login enumeration, and so on
- Clickjacking
- Any types of hijacking
- Missing security headers
- Missing security flag or HttpOnly cookie
- Unvalidated redirects and forwards
- Open redirects, unless they compromise the security of the service (for example, by allowing authorization token theft)
- Web application firewall (WAF) bypass, or direct access to the server
- HTTP OPTIONS or TRACE methods enabled
- Man-in-the-middle (MITM) attacks or interception
- Attacks that require a user to be present online
- Any product features implemented without taking into account best cybersecurity practices, dark patterns, and so on
- DoS/DDoS
- Possibility of sending a large number of messages
- Possibility of sending spam or malware files (for example, spam registration or password recovery emails)
- Exposure of private API methods or tokens
- Exposure of EXIF image metadata
- Vulnerabilities that allow disclosure of an IP address without revealing other identifying information about the client (such as the client's full name or login)
- The “Got an Idea” section
Participation rules
By participating in our bug bounty program, you confirm that you have read and accepted these participation rules. Violation of any of these rules may result in forfeiture of rewards.
General rules
- The scope of the bug bounty program is limited to technical vulnerabilities in the company's services. If you encounter problems that have nothing to do with security, please contact customer support.
- If you discover a 0-day or 1-day vulnerability for which an official patch was released less than a week ago, your report will be considered on an individual basis and may be awarded with a bounty at the discretion of the Craftum security team.
Testing rules
- For testing, you can use only your own accounts, accounts of users who have explicitly given their consent, or accounts provided for testing with bonus rates. Do not attempt to access other people's accounts or any sensitive information.
- While searching for vulnerabilities, avoid compromising the confidentiality, integrity, and availability of information in our services.
- Any activity that could harm the company's applications, infrastructure, customers, or partners is strictly prohibited. Examples of prohibited activities include social engineering, phishing, denial-of-service attacks, and physical attacks on the infrastructure.
- To confirm a vulnerability, use the smallest possible proof of concept (POC). If this could impact other users or the system's performance, please contact us to get permission. Further exploitation of vulnerabilities is strictly prohibited.
Report requirements
A report must contain the following:
- A full description of the discovered vulnerability
- A description of the impact on user and/or system security
- The steps required to reproduce the vulnerability, including the following (if possible):
◦ Screenshots
◦ Videos
◦ Requests/responses
◦ Code of the exploit used
◦ Date and time of request execution
- IDs of accounts used in testing
- Other materials required to reproduce the vulnerability
- Brief recommendations for remediation
Vulnerability severity assessment
We reserve the right to make the final decision on the severity of the discovered vulnerability. After receiving the report, we conduct an internal investigation and determine the severity level based on multiple factors, including the following:
- Privileges required to conduct the attack
- Difficulty of discovery and exploitation
- Need for user interaction
- Impact on the integrity, availability, and confidentiality of the affected data
- Potential business and reputational risks
- Number of affected users
Rewards
We reward external security researchers only for the discovery of previously unknown vulnerabilities, provided that all participation rules are complied with.
All reports are considered on a case-by-case basis with regard to the severity of the discovered vulnerability and the criticality of the affected system.
Reward amounts
| Vulnerabilities | Reward |
|---|
| Remote code execution (RCE) | Up to ₽150,000 |
| SQL injection with access to critical data | Up to ₽100,000 |
| SQL injection | Up to ₽25,000 |
| Blind SSRF | Up to ₽25,000 |
| Server-side vulnerability with disclosure of sensitive information (IDOR) | ₽10,000–₽75,000 |
| Stored XSS | ₽10,000–₽20,000 |
| XSS, except for Self-XSS | ₽5,000–₽10,000 |
| Business logic errors | On a case-by-case basis |
| Other confirmed vulnerabilities | On a case-by-case basis |
Additional information on rewards
We understand that each vulnerability is unique and may have an unexpected impact on security and business operations. The reward amounts listed in the table are based on our general guidelines, but if you identify a particularly severe vulnerability, the reward amount may be significantly increased.
Discovered vulnerabilities that pose a significant risk to our company and are eligible for a larger reward include the following:
- Remote code execution (RCE) that can take down our servers, destroy data, or disrupt business operations
- SQL-injections that can be used to access, manipulate, or completely delete critical data
- Any other scenarios that pose major risks to data, infrastructure, or users
In such cases, we are willing to consider increasing the reward up to ₽500,000 after assessing the risks and implications for the business.
We appreciate your efforts and are willing to reward you fairly for finding vulnerabilities, which helps us protect our users and our business.
How long does it take to check your report?
Vulnerability reports are reviewed by our internal security team. Response times may vary depending on our workload, but we try our best to process requests within two to three days.
Rules for handling duplicates
We reward only the first submissions (provided the report contains all the necessary information to reproduce the vulnerability). Any subsequent reports addressing the same vulnerability will be marked as duplicates. Reports containing similar attack vectors may also be considered duplicates if our security team believes that the information from an earlier report is sufficient to address all reported attack vectors or errors. Your report may be considered a duplicate of a report authored by another researcher or our security team.
Vulnerability disclosure policy
You may not share any details of the vulnerabilities you discover without written permission of the Craftum security team.
How to register test accounts
- Sign up for the products to test using your own mailboxes.
- After signing up, tell us your test account id.
- Provide a link to your Standoff 365 profile (your profile must be verified).
- Send us an email with these details to bugbounty@craftum.com, and we will credit you with a bonus payment for testing.
Link to the service
Issues found within the testing scope are evaluated based on their severity, to the maximum extent applicable.
However, some cases may be considered on an individual basis if the discovered vulnerability has a significant impact on the whole infrastructure.