How do you avoid duplicates?
Over the past year I’ve spoken with researchers and heard many different strategies and approaches to avoiding dupes. This topic can often piggyback off of the “How do you approach a target” discussion, but I’m interested in hearing about anything specific or special that you do to avoid the dreaded duplicate.
Some quick things I’ve heard from folks:
- Avoid the “low-hanging” fruit, stuff people are most likely to find and go after
- If you have a feel for where other researchers have looked, look elsewhere. Or try to build off of something someone else has found in the past.
- Go after Bounties that may be overlooked by other researchers lately
- Hit a target that was recently updated (new software updates, features, etc)
What else would you add?
Here are some additional tactics that we shared back in 2013 in @caseyjohnellis’s blog post “Three ways to avoid duplicates in bug bounty programs”
Duplicates are a necessary aspect of bug bounty programs, but they can be a bit of a bummer… Here are some tips on how to avoid dupes which apply to all bounty programs, both Bugcrowd and those out in the wild:
- Be the first to find the “easy to test for and easy to find” issues (e.g. XSS in an input on the Contact Us page of a web app). This requires planning to be around for the kickoff. Bugcrowd will usually send notifications ahead of time so that you can prepare if you want to.
- Go after the “easy to test but difficult to find” issues (e.g. XSS in a really obscure part of the applciation, or on another in-scope system which is hard to find). The more obscure the location the better. The goal here is to look in places the other ninjas probably haven’t looked yet. Bugs like these often come as result of HTML source review for clues which point to unlinked pages.
Think like a bad guy (e.g. finding an unlinked page that renders tweets for a logged in user, use Twitter to pipe exploit code to POC an XSS, use the XSS to steal the user’s session cookie). This is a different approach to testing… Instead of asking “is this field vulnerable to XYZ bug” for all applicable inputs, think about where you are, what the best objective is (e.g. super-admin with admin portal access), what the controls are between you and that objective, and how best to bypass them.