Before presenting my top 10 vulnerability list, I want to mention that Cobalt was the first crowdsourced security platform that I registered on and the one that got me into bug bounties as more than just a hobby. I’m a security researcher and I found that bug bounties were a new challenge in my life, giving me the opportunity to establish new friendships, better financial support and the ability to work with the biggest companies in the world.
I started submitting security reports to Cobalt (back then it was still called Crowdcurity) in March 2015. I was invited to a private security program and started working my way up the ladder. Initially I mostly submitted API related issues but I quickly noticed that many other web attacks (OWASP Top 10 issues) were possible. So I started hacking. After I had worked on the private program for a few days I got invites for additional security programs, where I also found critical vulnerabilities. Participating in these programs got me in the top of the rank at the Cobalt Hall of Fame, which I’m holding since August 2015 — almost a year .
At the current stage have submitted 174 valid and rewarded reports on Cobalt.
In the following I will present the top 10 vulnerability types I used to reach the no. 1 position.
The Top 10
1. Reflected File Download (47 reports)
Love this one. I even wrote a Cheat Sheet to promote this vulnerability. It’s present in almost every web application and it has lot’s of potential. Keep in mind that this is not a JSON issue but you most find it there.
2. Cross-Site Scripting (Stored, Reflected and DOM — 46 reports)
One of my favorite vulnerabilities. Who doesn’t love to bypass what developers think is secure or that clean pop-up showing up after trying to inject your payload? Stored XSS always delivers a good reward and it’s still present many times but DOM XSS is conquering terrain and getting forgotten by many developers. Keep that in mind.
3. Cross-Site Request Forgery (19 reports)
The number of valid findings related to this would be larger if more program scopes allowed sandboxed admin access. Most administrator areas are not protected against CSRF. Why? Developers think that because it’s a protected area it doesn’t matter to secure it. Imagine a logged admin visiting a page that created another admin?
4. Authorization related (12 reports)
Unprotected cookies, sessions or even no authorization at all sometimes are very popular. I even had a case where just entering /admin in the URL I got access to the admin area.
5. HTML Injection (10 reports)
Usually present on “Send to friend” operations. You can play with it forgering HTML to look like it was sent by the program itself. “Click here for bonus” with the company colors and stuff like that.
6. Logic Flaws (9 reports)
I’m still learning this new way of hacking. I recommend reading the PDF — Breaking the Web with Logics .
7. Open Redirect (8 reports)
I usually don’t go after this type of vulnerability but if I notice something like retURL, URL, goto, etc in the URL, I immediately go for it. Some of them are very “juicy” and can even get a CRLF injection. You never know right?
8. JSON related issues (7 reports)
Callbacks that can lead to information stealing, information disclosure on APIs using JSON files, etc. Many of the web applications use JSON so it’s important to check their security.
9. File Disclosure (6 reports)
Usually I come across this type of vulnerability by spidering the web application but also when files that are public without admins knowing about. Fuzz and spider is my advice.
10. Clickjacking (5 reports)
I usually prefer to report other vulnerabilities but sometimes web applications “are asking for” reporting of Clickjacking. Depending on the proof-of-concept you can get few bucks with it.
This concludes the top 10, which is only an inspiration for other security researchers (and developers), but not a full checklist for what to check for when participating in pen tests and bug bounty programs.
As runner-ups to my top 10 vulnerability types I have components vulnerabilities (Wordpress, Joomla, Drupal and many other CMS or frameworks could be forgotten by developers when updating so take a look into it) and CSV Injection (Not many people try it. You can even hijack a computer using this method. It’s very easy to detect and implement). If a program is public and more researchers have tested the application I always try to find less common vulnerabilities — logic based, API, Reflected File Download, Template Injection, CSV Injection and so on. As a final side note, I want to mention that out of the 174 rewarded issues on Cobalt, I only had one LFI and one SQL Injection. Imagine that? Nowadays I don’t think they’re very common because developers are using already prepared statements in most cases. But when you find it, it puts a smile on your face (not a Joker one).
Don’t miss my next blog post on Cobalt — How to write good vulnerabilities reports.