Avoid rookie mistakes and progress positively in bug bounty
Hope everyone is having an awesome holiday and wishing everyone Happy New year 2019.
I will try to summarize all the Rookie mistakes which most of the people commit and got N/A, so people can avoid and progress further.
You can also check out https://medium.com/@d0nut/5-tips-bug-bounty-programs-want-you-to-know-about-544d29888aeb where Donut explained really well about process and tips.
Note: I will cover up rookie mistakes including my experiences as well.
I am going to explain each aspect one by one
1) Writing reports
Although report writing differs from person to person however if you don’t explain correctly in a proper format, then security Triager will have difficulty to understand the report.
So You can always follow the proper format in terms of report writing:
Title( It should be catchy and also related to that bug)
Step To Reproduce (Cover up from steps upto Coding part explanation as well)
Proof Of concept ( Attached Screenshots or Video)
O/S and Browser ( Need in special reports, not all the time)
If you follow good report Format styling, you can always project your security bugs and convey it to the Team members in the easiest way as possible.
2) Being Patient
Although, this sound very ignorable but if you try to write comments on your reports frequently about report status, then Team member will face difficulties in following up and working with reports. Everyone needs to realize that Team members have hundreds of reports to work with or more than that.
Some issues are so critical that it can take more than 6 months to resolve from the backend and developers are continuously working every day.
So, give some time and knock once if you think Team members are not responding at all. You can try email support service if you think no one is responding over a period of time.
3) Analyze your security bugs ( over and over again)
If you think that you got a security bug, don’t rush with excitement and submit directly, analyze over and over again.
- Whether this bug is temporary or not.
- Is it a well-known bug mentioned in the policy of a program, check program policy thoroughly.
- How much user interaction will be required to exploit this bug? Is it too complex to execute?
- Can this bug be chained with other bugs to create greater impact or not?
- Is it depends on Time factor as well?
Let me give you an example:
Security Bug — Deleted files can still be fetched using API endpoints or any other endpoints.
Most of the people will be in hurry to submit but turns out that report will be closed as N/A.
What’s the reason?
Apparently, most of the time server has their own maintenance time in which people can fetch the deleted file within 15- 45 mins, but after one hour, files will be permanently got deleted from the server and by the time you’ll submit the report, you’ll be frustrated that I can’t fetch the deleted file at all and suffered an N/A.
So Time factor always count when you try to fetch deleted files.
Never rush with excitement to submit, analyze your bug first from every aspect and then submit.
4) Think Like a Team member
This one has helped me in terms of bug bounty. Whenever I get any bug, I try to question myself in terms of the team member’s perspective,
“ where you can execute this bug? How it’s different from that report? Have you gone through our Documentation? Please read the policy first and check out the excluded scope.”
If you always think like this way, I can assure you that 70–80% of N/A reports will not be happening at all from your side.
5) Great Interaction level and ask for feedback as well.
When you went wrong, then you can always ask feedback and explanation from Team member, believe it or not, but it really helped me to progress more.
Also, If you have great interaction level where you can understand each other’s perspective, then that report will set an example of good quality reports where people can learn as well.
6) Some exclusion Bug mistakes and don’t practice
- Content Injection — If you really think content injection will work, then it won’t. People are becoming smarter these days, they can recognize that the page is filled with fake content until and unless that page is having HTML Content injection, then it might be something else.
- Cookies are still working even after session expired- Now this is arguable, People think it’s a bug but it’s an information preventive measure, you’re just giving information not exploiting at all, so developer and security team members are already aware of. It’ll be critical when you get an XSS where all the cookies are in HTTP mode, you fetch those cookies completely, victim log out from their session and now you are injecting those stolen cookies and it’s working, then it will be critical.
- CORS exploitation mistakes with auth header and static information — So, origin injection in a request is giving response correctly. But in order to CORS work fully: First, check whether actually auth header is present, newcomers always make mistakes when they report CORS and didn’t check auth header and straightaway, copy paste burp request and response, also static info is not very helpful at all. If auth header is crackable, then you can combine with CORS to further exploit.
- CSRF on request not attached to any user sessions-
CSRF without session attached area- Any help site where “was this article helpful?”
Shopping sites where an item can be added in a cart without using session and can be actively added.
Shopping sites review item’s comment area vote section up and down where despite using any session , you can create CSRF request to add a vote.
These type of CSRF are not accepted by any company and you can have report status either duplicate, informative or N/A.
- SELF XSS — Most of the Company accept and don’t accept, so it depends on them, but if you encounter a self XSS and if there are any other ways to create normal XSS, you can combine with either CSRF or pastejacking technique mentioned by Geekboy. (Note: page should be vulnerable to clickjacking as well).
Here is the link :- https://www.geekboy.ninja/blog/cross-site-scripting-for-fun-pastejacking/.
There are more exclusion bugs to discuss but I think you can get a glimpse of exclusion bugs and when to report and when not to.
Lastly, there are many other aspects which you can progress further, but I think most importantly, before progressing in more depth, we need to practice in basic methodology and style in terms of reports and bugs.
I just learned all these points over a period of time and considering these points when I find bugs now. I am just having one year experience since I started from January 2018 and I think people can progress with bug bounty and increase their knowledge if they focus on small things as well.
To every newcomer, focus on these small things and you can progress further, no need to rush anything, take your time, slowly learn, consider every points and progress.
If anyone wants to add anything, feel free to comment down below.