James Kettle reopened the desync/smuggling vulnerability in the last two years. While doing so, he has an interesting set of notes on finding bugs.
The amount of bug available is based on a few things:
- How well understood or explained is a bug?
- How complex is the system or bug?
- How obscure or known is the bug class?
The bugs exist with complex, obscure and poorly explained issues. If you're looking at SQL injection on a popular website, there will be heavy competition on it. If you're looking for Web Cache Deception, a bug class from a few years ago, then you'll have less competition.
Where the good opportunities in research? Most of my stuff is passed upon others, as James alludes too. They have a few points:
- Did the researcher miss anything?
- Did they release a scanning tool? If not, can I make one?
- If they did release a scanner, does it detect every vulnerability mentioned in the paper?
- Can I see any blind spots in their scanner's design or code?
The example that James gives is on his own research on desync attacks. They mentioned that CL.0 style vulnerabilities were mentioned in the presentation, with several obfuscated payloads to make it possible. However, these were never added to the scanning tool.
James added these to the scanning tool and instantly found 15 unique bug bounty programs vulnerable to this type of desync. They claim that added new permutations is the easiest way to find fresh desync vulnerabilities.
Overlooked research is an easy way to find new bugs. Most people simply use current techniques to find bugs. Overall, good write up!