“This is not a girl’s cup of tea. Are you crazy?” These are the lines I heard when I showed interest in bug bounty for the first time.
Hacking, bug bounty… I never dreamt of it as I did not know what all these things were. But when you see a friend of yours do all these things you are left with no choice but to applaud him/her. The sheer madness for this amazing program didn’t let me take a nap. Initially there was only failure; bugs were duplicate, out of scope. So I decided to learn those things first, which can improve my bug hunting. After months of hard work and patience I finally got my first hall of fame with Magix AG.
Allow me to share my experience that can help a beginner to start up in bug bounty, because I believe sharing stories and listening to them makes you a better human being to learn and achieve as well:
My friend Atul has already given a fair idea about tools and OWASP Top 10 last week, so in this blog I will be writing about the importance of validating bugs.
The important things one should keep in mind before starting bug bounty are:
- Understand the scope of the application, because it defines your testing. And it limits your wastage of time on unnecessary things.
- Spend some time in understanding application logic. Once logic is clear, finding bugs will be easier.
- Apart from OWASP top 10, try for some new things. Try to abuse the application functionality, apply your own logic.
- e.g: In a banking application, with OWASP top 10, you can also try for some logical vulnerabilities like: Transferring negative amount or Self account balance transfer
- Or in an e-commerce site, try to tamper the price details when buying and try to tamper quantity details when returning items etc.
- Do not rely on scanners, as there will be more false positives due to syntax/regex based response comparison and also many applications does not support auto scan usage due to application structure.
A list of responsible disclosure programs are available on Bugcrowd, you can pick up a target. Read the target scope carefully. Understand the application functionality and prepare a checklist of test cases accordingly. Then start your testing, you can take help of some tools like Burp, ZAP proxy and browser add-ons like wappalyzer, Tamper-data , Foxyproxy. If you are thinking of using an Auto Scanner to make your task easier, then keep it out of your mind, as most of the application does not allow use of Auto Scanner and many Auto Scanners will give you false results that you must validate. For example, an Auto Scanner may report a XSS, but if you do not validate and provide POC you have not done your job in reporting a vulnerability. This bug will likely be rejected.
This is why you must focus more in manual testing. Even if you do a manual testing, some bugs still need to be validated. For example:
Session Identifier Not Updated After Login Vulnerability
A Session Identifier Not Updated vulnerability exists when a session id value does not get updated even after login. A cursory glance at an HTTP history might lead a researcher to guess that “jsessionid” controls the session token for an application. This is a reasonable assumption given the suspicious “session” naming within the token, particularly if the value of jsessionid remains the same prior to and after authentication – suggesting a session fixation vulnerability. But does this assumption stand up to scrutiny? Can we reliably say that test.example.com is vulnerable to session fixation? Or does the application have more than one session token? Whenever a user authenticates to an application, a new session token value should be issued. Similarly, when a user logouts out of an application, e.g. by clicking on an logout button, the session token is expired / invalidated. So for such vulnerabilities, it is mandatory to validate again before submitting or you may have the bug rejected.
When submitting a bug, it is important to provide proper analysis and recommendations to mitigate the bug, because, some applications will be expecting these. Without proper analysis provided, even a real bug can be treated as a not-valid.
About the Author:
Archita Aparichita holds a Bachelors of Computer Science Degree from BPUT University – India, and currently works as a Security Consultant at iViz Securities. Archita has acknowledgements from popular companies such as, but not limited to: Barracuda,Yahoo, Indeed, Tagged, Mail.ru, Magix, Expression Engine, and many more.