The big count of the bug bounty hunters usually does not care about their report quality. I was no exception.
I started my work on the HackerOne platform at the end of the October 2016. Actually, I registered there in the May 2016, but was busy with startup and forgot about it (I worked as PHP Developer in that time).
I can’t say that I was completely new in infosec — I had some experience as Backend Web Developer, and as Hacker Newbie (in the old times, when I was studying at the University, I hacked some amount of online games). But I have no idea about basics — bugs types, classification, exploitation, responsible disclosure, etc. I think I was familiar only with request interception, and XSS/SQLi in that time, because as webdev I had tasks about sanitization/neutralization of malicious user’s input.
When I started in October 2016, I was excited by HackerOne platform. Big count of public programs, friendly interface and usability, great markdown, strict reputation system and awesome hacktivity timeline — I liked all these features. I chose the random public program, and wrote my first report, included 3(!) POC tools, written on C#, and immediately got N/A. Reason? I didn’t read the policy, and submitted the outscope bug (credentials brutforce).
Me, when I got my first N/A
So, I submitted more bugs…And more…And even not security bugs…When my signal was less than -1, I started to think that I’m doing something wrong. And the answer was simple — I wanted the bounties too much. Then I told myself — stop, I’m not ready yet, I need some practice and learning, and realizing, what is really important for me in this area.
Here are a 5 simple rules, from my own experience, which helped me. Following them, In 1 year I jumped from the -1 signal, and 95 rep to the 6+ Signal, and 3k+ rep:
Rule #1. Patience.
If you use H1 platform and have this badge, you know what I’m talking about
If you interested in the bug bounties, such ability as patience is a great thing. If you can’t sleep, thinking about your opened report, you definitely should upgrade this awesome skill. Every security team has different handling of the security reports, and such thing, like, for example, continuous asking for the updates every 2–3 days can cause even greater delay.
Patience does not mean inactivity
Rule #2. Continuous learning.
Insanity — it is doing the same thing over and over again and expecting different results.
If you not have good results in the bug bounty, the faster you understand, identify and accept your weaknesses — the faster success will come to you. Worse, if you report all the things, as I did, without reading the policy, hoping for the bounties. As the companies implement continuous security, s security researcher must continuously keep up and improve the knowledge.
Rule #3. Understanding that security is more important than the bug bounty money.
Bounties are the great motivation, but your success as security researcher is more important, if you really like this work.
Rule #4. Be unique. Use improved tools. Develop your own bugs discovery techniques.
Learn from others, but do not copypaste others. When using the public tools, try to improve them, add something unique stuff. Using Sublist3r? Make it more speedy & add new discovery techniques! It will bring you more bugs & less duplicates. Writing your own tools is a big advantage too – you can develop exactly what u need!
Rule #1337. Report quality. Please, do not assign improper severity for your bugs. Marking Text Injection or SSL Poodle on the static site as Critical is a bad idea, and it’s making infosec community cry.
And, some programs reward an extra bonuses for good and well-written reports!
P.S. I also recommend to read this articles: