To report a new bug, please send the report to firstname.lastname@example.org
"Subject: [Platform & version][App version][Level]Bug name
Platform & Version - IOS or ANDROID and android/ios version
App version - GoodX app build number
Level - low/medium/high the importance of the bug."
While describing your bug, please try to be as more specific as you can. Explain the flow how to reproduce the bug and attach the screenshots if required. We will check it as soon as possible and get back to you.
Depending of the bug importance, we will reward each user with our XFN tokens.
There's always the chance that we might have missed one posing a significant vulnerability. If you discover a bug, we appreciate your cooperation in responsibly investigating and reporting it to us so that we can address it as soon as possible. To show our appreciation for external contributions, we (GoodX) maintain a Bug Bounty Program designed to reward responsible disclosure of qualifying security vulnerabilities.
The scope of the GoodX Bug Bounty Reward program extends to the GoodX mobile application along with the APIs and GoodX website (https://goodx.network)
To be considered for a reward it is necessary that you follow the below mentioned steps:
Detect a vulnerability, or a persisting bug within the scope of the program
Either create a proof depending on the type of bug (screenshot, video or some sensitive data collected and reported responsibly) Or write the sequence of actions required to reproduce the bug.
Present the proof or the sequence of actions required to reproduce the bug to the GoodX team on https://www.reddit.com/r/GoodX_bugs/.
Responsible investigation and reporting include, but isn't limited to, the following:
● Don't violate the privacy of other users, destroy data, disrupt our services, etc.
● Only target your own accounts in the process of investigating the bug. Don't target, attempt to access, or otherwise disrupt the accounts of other users.
● Don't target our physical security measures, or attempt to use social engineering, spam, distributed denial of service (DDOS) attacks, etc.
● Initially report the bug only to us and not to anyone else.
● Give us a reasonable amount of time to fix the bug before disclosing it to anyone else and give us adequate written warning before disclosing it to anyone else.
If you do your best to follow these guidelines in discovering and disclosing a vulnerability, we won’t take any legal action against you. We will do our best to respond to your submission as quickly as possible, keep you updated on the fix, and award a bounty where appropriate.
Services in Scope
All services provided by GoodX are eligible for our Bug Bounty Program, including services offered through our web site, GoodX APIs, and our mobile application for IOS & Android.
Any design or implementation issue that could result in substantial financial loss, data breach, or service degradation is within scope including, but not limited to:
● Authentication or authorization flaws
● Server-side code execution bugs
● Exposure of User Data: The ability to access user or employee data without having an authorized relationship with the Victim.
● Unauthorized Requests on Behalf of User/Employee: The ability to forge authenticated requests on the behalf of a Victim.
● Monetary Impact: the ability to cause monetary impact to GoodX or GoodX users through a technical vulnerability.
● Phishing: (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on GoodX users.
● Safety: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.
Things that are not eligible for reward include:
● Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website.
● Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attack, etc.
● Vulnerabilities in third party applications that make use of GoodX API.
● Bugs that have not been responsibly investigated and reported.
● Bugs already known to us, or already reported by someone else (reward goes to first reporter).
● Issues that aren't reproducible.
● Issues that we can't reasonably be expected to do anything about.
Calculating Security Impact
Understanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.
● sensitivity of user data exposed -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.
● scale of exposure -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.
● severity of forged actions -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.
● forge communication from Goodx -- when a vulnerability allows an Attacker to send communication (and control the content) to a Victim and have it come officially from Goodx. An example would be the ability to control the contents of an in-app push notification.
● requires user interaction -- when an exploit scenario requires a human from Goodx or a Victim to manually interact before exploit is successful.
● authorized relationship -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.
● requires brute forcing -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.
● existence of rate limiting -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.
● physical access -- exploit scenarios requiring physical access to a device.
● noticeable to victim -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.
● account put into arrears or banned -- when an exploit then puts the Attacker’s account into arrears or results in a ban.
● social engineering -- when an exploit requires social engineering a person to be successful.
● requires privileged network position -- when an exploit (often times MiTM) requires having privileged network position to be successful
● requires multiple accounts -- when an exploit requires the ability to mint new accounts indefinitely.
How to Disclose
High quality Submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.
● Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.
● Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).
● Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.
● In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.
● Video only proof-of-concepts (PoCs) will not be considered.
● A vulnerability must be verifiable and reproducible for us to be considered in-scope.
Any information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request to GoodX team.
We strive to be consistent with how we close reports and below are the details for each state:
● spam -- a report with no useful information
● needs more info -- not enough actionable information in report to triage
● not applicable -- no reproducible security vulnerability or explicitly out-of-scope per our guidelines
● duplicate -- a vulnerability that has previously been found internally
● informative -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named goodx-secret-stuff that isn't actually related to us)
● triaged -- either a valid report or a report that needs more investigation from an internal team, typically the former
● resolved -- a verified vulnerability that has been fixed
We focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. We recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.
The general process for determining bounty:
● Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”
● Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”
● Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”
● Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”
● With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.
The bounty ranges for the different security impact buckets:
● Exposure of User Data -- the payout ranges for this bucket range from $10 to $10,000.
● Unauthorized Requests on Behalf of User/Employee -- the payout ranges for this bucket range from $10 to $10,000.
● Monetary Impact -- the payout ranges for this bucket range from $10 to $10,000
● Phishing -- the payout ranges for this bucket range from $100 to $5,000
● Safety -- the payout ranges for this bucket range from $100 to $10,000
Bounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.
All bounty payouts will be made in GoodX tokens - XFN.