Medium.com posted a really good overview of the methodology for performing bug hunting. The key point he brings up is its not about the tools but the approach you take. That approach will also vary based on your goals for doing bug hunting. Read this one … its good to know regardless if you are a bug hunter. This is good knolege for any security professional. The original post can be found HERE.
Some of the most common questions out there in the industry are “what is your methodology?” or “how do you look for bugs”? This post will be an attempt to answer that from the point of view of an average and continuously learning bug hunter. This has certainly evolved over time, and will certainly continue to evolve. There are many great, existing resources on the subject, but this post will look to answer these questions in a bit of a different way. This will also hopefully be different in the sense that it’s not coming from someone who has been in the industry for 5–10+ years, but rather someone learning and to be quite blunt, average. This will also focus more on the methodology, rather than the tools. In general, you don’t need to run certain tools to be successful, and most of this methodology will be very manual-testing oriented. Everyone has different goals, styles, and preferences when it comes to bug bounty, and methodologies cannot be a one-size fits all for everyone. Here is another perspective on how to approach bug hunting.
What do you want out of bug bounties?
Before thinking of a methodology, you need to know what you want out of bug bounties. Is it to maximize money? Is it to learn more about certain technologies? Is it to increase your security & technology knowledge? Your methodology will vary greatly depending on the answer to this. For example, if your goal is to maximize money, you probably want to invest a lot of your time and effort in recon & automation, as these will allow you to find more bugs quicker than others.
I got into bug bounties to learn more about application and web security, with the money being a nice additional benefit, but certainly not the main goal. Because of this, my methodology focuses greatly on main or large applications, and going deeper, rather than wider.
Main app methodology from your friendly, average bug hunter
1. When picking a new program to start working on, there’s a few things to consider. For the above preferences described, programs that have a few assets, but large and deep, are ideal. This is always the first criteria to ensure the application has enough functionality to spend a considerable amount of time on. Then, focusing on other things such as program responsiveness, time-to-bounty, type of assets, and general reputation are other things to consider.
2. Once the program has been selected, the first step should always be to learn more about the company and what is important to them. Every company is going to have different goals. Some will care far more about user privacy than others. Some will have certain regulations they need to comply with, and accessing certain data could be a critical issue for them. Learning this will allow you to focus your efforts on what is best to maximize your time and rewards. For example, applications that deal with sensitive information such as user’s PHI (Protected Health Information) are going to care a lot about unauthorized access to user medical data. So focusing on finding authorization flaws, IDORs, etc. related to medical data is almost certainly going to be a high or critical issue.
3. Learn the application. I always start a new application by creating 2 accounts, and going through all the functionality in the application. If there’s different user types and roles, you’ll probably need to create a few more. This will give you a great opportunity to see what the application is all about, and how it’s used by normal users. It’s very important to run through the application as a normal user, check out as much functionality as possible, and not blindly inserting XSS/SQLi payloads from the first minute. A better understanding of the app will allow you to find critical logic flaws after you get some more experience with it. While doing this, I like to look for authorization flaws/IDORs at the same time. I find that it generally doesn’t take too much focus off of the learning, and actually will help to understand more about access controls and expected workflows. This allows you to not only learn the application, but also tackle some very common bug classes at the same time. Take notes on things such as:
- Is there public API/technical documentation? Try to find their actual technical documentation. Not their marketing docs that boast about their military grade cyber warfare encryption. Read up on whatever the company has available either within their documentation or built in to the application. You can understand more about the application, expected workflows, infrequently used/hidden endpoints, etc. Even consider combing through things like their privacy policy to understand what information they are maintaining private as this can be used to further demonstrate impact if you find something that is non-compliant with their policy.
- What technology is being used? This will open up different bug classes to focus on, and allow you understand what framework/language specific things to focus on.
- What do requests look like? Are sequential IDs passed around for pulling & modifying data? Great opportunity to focus on IDORs. Is data fetched and modified from an API specific domain? How is authorization handled for that? Look for things like CORS misconfig, auth flaws, etc.
- Are there any interesting requests to investigate later? Anything that seems interesting, take note of it. One way to do this is to simply send it to repeater for further analysis. By the end of this step, I generally have about 10–15 interesting features or endpoints that I want to come back to for some more focused testing.
- After working through most of the application, how does it handle inputs? Are certain characters universally blocked? or filtered? Can you control IDs of objects or update/fetch? These answers will help you determine what bug classes you can and should focus on.
This step will take a while, but it will pay off later as you’ll have a much more detailed understanding of how the application is supposed to work.
4. Take it feature by feature. Many hunters recommend walking through the application bug class by bug class, and while I don’t think that’s a bad approach, I prefer to go feature by feature. Starting with the interesting functionality noted in the step above, you can begin to work through a deep dive of all functionality. Your tests will vary based on the specific functionality. It’s rare to have the exact same test cases for each feature, so you’ll need to be flexible for what you see. For example, if a feature allows you to import data from a URL, you are going to have a whole set of bug classes you’ll likely want to test, as opposed to a feature that allows you to send messages from one user to another. Being as flexible as possible in your approach and testing will ensure you don’t miss bug classes that you should be caring about.
5. After you’ve gone through the functionality readily available, discover more content! Using some directory bruteforcing tools and parsing through JavaScript files to find hidden endpoints and functionality will find you so many bugs. While it’s almost a running joke in the industry, security by obscurity is utilized very often. If you can discover this hidden content, there’s a good chance it’s not protected in the same way as commonly found and tested functionality.
6. Retest already tested functionality. The amount of times I’ve missed a bug the first pass through a given feature is very high. It may seem like a waste of time at first, but you’ll absolutely miss things. As you learn more about the application, you’ll also think of new things to try that you wouldn’t have thought of your first time through. At this point, you can go back to your Burp target, and manually view each endpoint to ensure you’ve covered it. You don’t want to miss anything here!
7. Come back after you’ve learned more. Even if you’ve moved on to another program, come back to your old program and test out some of the new functionality, new techniques you’ve learned, and incorporate techniques from disclosed reports or blog posts on your targets. If you’re doing bug bounty right, you’re continuously learning new and interesting attack vectors and techniques. It would be a waste to only test that on your new programs!
Summary
Posts like this are difficult because it’s hard to give meaningful advice without making it a novel length. Hope this was helpful to understand a bit more about bug hunting methodologies, and how to approach new targets (specifically large application testing). As you get more and more experienced, a lot of this will become second nature. You’ll start to anticipate bugs based on certain behavior, or technology, from what you’ve learned before.
As said earlier, methodology will greatly depend on your goals. If your goal is purely monetary, you probably don’t want to take some of the advice in this post, but want to focus on more recon-oriented, or automatable bugs. I want to deepen my knowledge in application and web security, so a lot of this methodology focuses on learning about applications, development, and how different technologies work. This approach will be a lot more manual in nature but can be verify profitable. The difference in methodologies can really be night and day, it depends on what your goals and interests are.