Storage Commander Bug Bounty Program
Updated November 29, 2022
Storage Commander Software LLC (“Company”) takes the security of our products and services very seriously. If you believe you have found a security vulnerability, we encourage you to let us know right away. We will investigate all legitimate reports and do our best to quickly fix the problem. Before reporting though, please review this page including our rewards, rules, disclosure guidelines, and those things that should not be reported.
You will be eligible for a bounty only if you are the first person to disclose an issue not previously known to us. Rewards for valid bugs are paid based on the severity of the qualifying bug, to be determined by the Company at its sole discretion. Reward amounts typically range from $100 to $500. Rewards cannot be paid to individuals or organizations if prohibited by US law. Rewards cannot be paid to non-US governments or agencies.
The final award may be higher based on the impact of your report. Bounty payments are made via PayPal, which is currently our preferred method of payment, but we reserve the right to change the payment method at our sole discretion.
- When you are creating an evaluation account for research purposes, please add the “bugbounty_” prefix to the username of your test account. “Only applies for systems that allow user signup for evaluation purposes”
- Ensure that you test vulnerabilities only on accounts that you own or have permission to test on. “Only applies for systems that allow user signup for evaluation purposes”
- Never use any findings to compromise the system, exfiltrate data or pivot to other systems. Submit your report as soon as you have discovered a vulnerability. We will pay you based on the maximum impact of your finding.
- If you stumble upon sensitive information, such as personal information, credentials, etc., during the assessment; do not save, copy, store, transfer, disclose, or otherwise retain the data or personal information.
- Do not perform social engineering, phishing, and physical security attacks against the Company’s offices, users, or employees.
- It is strictly prohibited to disclose any vulnerabilities without the Company’s explicit permission.
- Stay within the program’s scope.
- The usage of automated scanners is not allowed.
- Be respectful when you are interacting with our team.
- If you do not follow the rules, you may be banned from the Company Bug Bounty Program.
- We reserve the right to modify the rules for this program or deem any submissions invalid at any time. We may cancel the Company Bug Bounty Program without notice at any time.
- We will use the CVSS base scores and apply the relevant Temporal and Environmental Score Metrics to determine the actual overall score to use for bounty payments.
- Sensitive Data Exposure
- Remote Code Execution (RCE)
- Server-Side Request Forgery (SSRF)
- Cross-site Scripting (XSS)
- Cross-site Request Forgery (CSRF)
- SQL Injection
- XML External Entity Attacks (XXE)
- Access Control Vulnerabilities (Insecure Direct Object Reference, Privilege Escalation, Broken Access, etc.)
- Path/Directory Traversal Issues
- Any vulnerability with a CVSS base score less than or equal to 3.9.
- Bugs that do not pose any security risk.
- Click-jacking/UI-redressing, or issues only exploitable via click-jacking.
- Open redirect – unless an additional security impact can be demonstrated (such as stealing an authentication token, API keys etc.).
- Denial-of-service attacks.
- Self-XSS without a reasonable attack scenario.
- Injecting HTML or hyperlinks to emails which will be sent out from the Company.
- Fingerprinting on common/public services.
- Disclosure of known public files or directories (e.g., robots.txt, sitemap.xml).
- Information disclosure without significant impact.
- SSL/TLS version and configuration issues, weak ciphers, or expired certificates.
- Missing rate limits for non-critical actions.
- Cross-site Request Forgery (CSRF) with minimal security implications (e.g., Login/Logout CSRF).
- SPF/DKIM/DMARC related issues.
- Missing or misconfigured security headers (e.g., CSP, HSTS) which do not directly lead to a vulnerability.
- Missing Secure or “HTTPOnly” flags on cookies.
- Vulnerable software version disclosure without proof of exploitability.
- Reports generated from automated tools.
- Comma Separated Values (CSV) injection.
- EXIF metadata not being stripped from images.
- Brute-force attacks.
- Scenarios that require unlikely user interaction and/or outdated OS or software version.
- Broken link hijacking.
- Attacks requiring Man-in-the-middle (MITM) or physical access to a user’s device.
Reporting a Bug
- If our security team cannot reproduce or verify an issue, a report cannot be awarded.
- Please write your report in a way that makes it easier for us to reproduce the submitted issue.
- You must send a clear textual description of the vulnerability along with steps to reproduce the vulnerability.
- For the vulnerability report to be understandable and acceptable, you may include attachments such as screenshots or proof of concept code as necessary.
- List the related URL(s) and any affected parameters.
- Reports that only feature a video proof of concept without written reproduction steps will be refused.
- Don’t do more harm than good. You should not leave systems or users in a more vulnerable state than how 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. While researching a vulnerability, if you are unsure whether you should continue, immediately engage with the Company security team [email protected].
- Please be patient while we are working on the remediation process of the corresponding vulnerability. Refrain from asking for additional updates before 30 days have passed since your last response, as this will only increase our load and cause more delays.
How Severity is Determined
We reserve the right to make a final decision regarding the severity of a reported vulnerability. Upon receipt of the report, we will conduct an internal investigation and determine the severity of the vulnerability by considering multiple factors, including but not limited to:
- The quantity of affected users and data
- The sensitivity and classification of the affected data, and the security requirements surrounding it
- The impact on the affected data’s confidentiality, integrity, or availability
- The privilege level required to exploit the vulnerability
- Whether user interaction is required to exploit the vulnerability
- Other, if any, mitigating factors or exploit scenario requirements
While we try to be as consistent as possible with rewards, our program is evolving, and rewards may change according to how our program evolves over time.
This program does not allow disclosure. You may not publicly disclose information about vulnerabilities found in this program.
Any activities conducted in a manner consistent with this policy will be considered authorized conduct. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.
Thank you for helping keep our users safe!