follow us on twitter . like us on facebook . follow us on instagram . subscribe to our youtube channel . announcements on telegram channel



Author Topic: Bumble Bug Bounty  (Read 14071 times)

Angelina

  • Moderator
  • Experienced Member
  • *****
  • Posts: 357
    • View Profile
Bumble Bug Bounty
« on: June 09, 2023, 06:46:28 pm »
submit bug report: https://bumble.com/

Bumble and Badoo vulnerability disclosure program
We pay for all newfound vulnerabilities in Bumble, Badoo, Fruitz, and Zodia products.
Vulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.
Where to look for vulnerabilities for Bumble:
In scope:
(www).bumble.com
bumble.com (+mobile web version)
bma.bumble.com
Bumble mobile application (App Store, Google Play)
Out of scope:
blog.bumble.com
thebeehive.bumble.com
Where to look for vulnerabilities for Badoo:
badoo.com (+mobile web version)
eu1.badoo.com
us1.badoo.com
corp.badoo.com
m.badoo.com
meu1.badoo.com
mus1.badoo.com
chatdate.app
heyfiesta.com
bma.badoo.com
badoocdn.com
translate.badoo.com
ccardseu1.badoo.com
ccardsus1.badoo.com
Badoo Mobile Applications (App Store, Google Play).
Where to look for vulnerabilities for Fruitz:
Fruitz mobile application (App Store, Google Play, Web app)
Where to look for vulnerabilities for Zodia:
Zodia mobile applications (App Store, Google Play, Web app)
For more information please take a look into the assets list.
We don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.
Non-qualifying vulnerabilities
Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.
“Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability
Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones;
Reports from security scanners and other testing tools
Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);
Reports about issues in third-party applications and services
Reports about missed headers or cookie flags;
Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)
Data enumeration;
One-click authorization from emails and login CSRF via these links;
Captcha bypass using OCR;
Attacks based on social engineering or phishing.
Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.
And another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports without any check that these reports at least suitable for our services and apps. In other words: be kind!
To make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:
In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).
More dangerous: SQL-injection. Let's say you've found a vulnerability that "breaks" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.
If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.
Personal Data
You should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo, and Fruitz products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.
Public disclosure
We're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.