StorXNetwork / StorX-Node

StorX Docker Network
22 stars 9 forks source link

StorX Bug Bounty Program #38

Open hi2murphy opened 2 years ago

hi2murphy commented 2 years ago

Bug Bounty Program The StorX Bug Bounty program is an experiment in improving StorX’s cybersecurity through community involvement. Feel free to inspect our source code and web assets. If you have discovered a security issue that you believe we should know about, we’d welcome working with you. Please let us know about it and we'll make every effort to quickly correct the issue.

StorX Website : https://storx.tech See How StorX Works : (https://www.youtube.com/watch?v=GX-0egZEZ0Y&t=8s) Read StorX Blogs : https://storxnetwork.medium.com/ Github: https://github.com/StorXNetwork White Paper: https://storx.tech/storx_whitepaper_v1.pdf

Prize First Prize : USD $ 5000 Worth XDC Tokens Second Prize : USD $ 1000 Worth XDC Tokens Third Prize : USD $ 500 Worth of XDC Tokens

Vulnerabilities Not Covered Under Bug Bounty Any bug that does not pose a substantial or demonstrable security risk Clickjacking, open redirects, or lack of security headers Denial of service (DOS) Social engineering Physical exploits of our servers or network Local network-based exploits such as DNS poisoning or ARP spoofing

Rules 1.In order to take part in this program you must first register ands submit your plan

  1. Do not publicly disclose any vulnerabilities
  2. Do not perform any tests that will disrupt StorX services or impair users' ability to use them
  3. Do not use automated scanners
  4. To be eligible for bounty, all testing must be performed within the scope described above. 6. Out-of-scope submissions will be accepted and acted upon, but are not eligible for bounty
  5. If you become aware of a vulnerability involving an out-of-scope domain, it is still appropriate to report the vulnerability via this program
  6. Access does not equate to authorization. If a vulnerability provides unintended access to data, do not access the data beyond the minimum extent necessary to effectively demonstrate the presence of a vulnerability. If you encounter any Moderate or High Risk data during testing (such as Personally Identifiable Information (PII), Protected Information), cease testing and submit a report immediately
  7. Testing must not violate any applicable laws
  8. To the furthest extent possible, only interact with test accounts you own or accounts with explicit permission from the account owner

How severity is determined StorX reserves the right to make a final decision regarding the severity of a reported finding. Upon receipt of the finding, we will conduct an internal investigation and determine the severity of the finding by considering multiple factors including but not limited to:

  1. The quantity of affected users and data
  2. The sensitivity and classification of the affected data, and the security requirements surrounding it
  3. The impact to the affected data's confidentiality, integrity, or availability
  4. The privilege level required to exploit
  5. A working and reproducible proof of concept
  6. The difficulty to exploit
  7. Whether it requires user interaction Other, if any, mitigating factors or exploit scenario requirements

Terms & Conditions

  1. StorX reserves the right to not reward any submission if we so choose, and we will not provide compensation for time spent researching.
  2. Bounties are awarded only to the first unique report of a previously unidentified vulnerability. Subsequent reports will be closed as duplicates and not eligible for a bounty.
  3. Vulnerability severities and reward amounts are determined at the discretion of StorX. For instance, a cross-site scripting vulnerability on a static, unauthenticated website may be classified as less severe compared to a cross-site scripting vulnerability that has the potential to compromise user accounts.

Time Frame

  1. StorX will make a best effort to meet the following Time Frame for participating in Bounty Program:
  2. Time to First Response (from report submit) - 3 - 5 business day
  3. Time to Confirm (from report submit) - 5 -7 business days
  4. Time to bounty (from triage) - 10 - 15 business days

Submit vulnerabilities via the submission form. In order to qualify for a reward, submissions must include details about the vulnerability, proof of concept/steps to demonstrate the vulnerability, your impression of its impact and severity, and a proposed fix. You can also submit any questions you have via the same form.

Out-of-scope submissions will be accepted and acted upon, but are not eligible for specified bounty, But StorX at its own discretion might reward users, based on the severity of the issue. If you become aware of a vulnerability involving an out-of-scope domain, it is still appropriate to report the vulnerability via this program.

For more information or clarifications, Please email at info@storx.io / Subject : StorX GitCoin Bounty

About StorX StorX is a decentralized cloud storage network, which empowers users to store their data securely. Each file uploaded on StorX is split, encrypted into multiple data fragments and then distributed world wide across autonomous storage nodes operated by individual operators. StorX provides a democratic marketplace for hosting data, replacing the centralized monopolistic providers with a decentralized storage secured by blockchain technology.

gitcoinbot commented 2 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done


Work has been started.

These users each claimed they can complete the work by 4 weeks from now. Please review their action plans below:

1) skidad75 has been approved to start work.

Use a common security framework and OWASP criteria to review the website of any ongoing or new vulnerabilities and report them. 2) platinii has applied to start work _(Funders only: approve worker | reject worker)_.

Jxjkksksksjjsjsjjdjsldhjsjxidjhdishdjx 3) h4ss has been approved to start work.

1) I would firstly lead a source code analysis, based on secure coding standard

2) Then, analyzing the network layer and the user interface

3) Finally, I would lead attacking scenario, that would be a PoC if there is any vulnerabilities, in order to the assure the integrity of each functionality of the platform.

Learn more on the Gitcoin Issue Details page.