Scoping a web app pen test - Burp Suite Tutorial

- [Instructor] In order to conduct an effective web application security test, you first need to determine what's in scope and what's out of scope for that test. Otherwise, you've run the risk of spending entirely too much time on the wrong things. The best place to start when scoping a pen test is to review the ultimate goal of that test. One of the most common goals is to compromise restricted or sensitive data, data that the tester is not authorized to access. Standards like the Payment Card Industry Data Security Standard and regulations like HIPAA in the US are two perfect examples of external forces that require companies to conduct a data-centric pen test. But your pen test could also be account-centric. Instead of stealing data, what if you could log in as someone else and manipulate that person's account? Better yet, what if you could log in as an administrator? How much damage could you do then? Take time to discuss the end goal of the web app pen test at the onset of your scoping discussion. With the goal identified, now you're ready to start discussing the scope in detail. Don't accept a generic answer that everything's in scope. Spend some time clarifying what's explicitly in for the test and what's explicitly out. Ask for a list of URLs that are to be tested. These should represent the apps themselves. An app could be accessible via a subdomain or via a subdirectory on a domain that hosts multiple applications. Confirm both the entry point for the application, as well as any specific URLs that might need to be excluded. Admin pages and password reset pages often end up in that excluded list. Go one step further and ask about specific IP addresses or net blocks that may be a part of your test. Even though the developer intended for users to access their apps via subdomains and subdirectories, there are many cases where you can access those same apps using the IP address instead. This works even if DNS entries haven't been created for those hosts. This is a good way to find publicly available apps, by the way, that companies mistakenly thought they disabled or decommissioned. If specific user or administrator accounts are out of scope, verify that before you begin testing. Depending on the type of pen test that you're running, you may be provided with valid user accounts specifically created for testing purposes. Finally, make sure you identify testing windows that are either approved or forbidden. The last thing you want to do is cause a production impact to an e-commerce application during their peak sales time. If you do, chances are you won't be invited back to test that app again in the future. Where possible, try to ensure that nonproduction instances of your applications are in scope for your pen tests. Why? In real-world pen test scenarios, you can only plan so much. There are times where you have a high level of confidence that an exploit might work, but you're not 100% certain whether the exploit will have a negative impact. If you can run that exploit against a nonproduction instance of the app, you can confirm both the positive and negative results of that action. In some cases, proving an exploit in a nonproduction environment and reviewing the organization's change control procedures may be enough to indicate that the same exploit would work in production. This approach yields the same security value while minimizing some of the risks encountered during the pen test. A few quick notes on the importance of selecting the right time frame for your testing activity. Because pen tests could have a potentially noticeable impact on the target web application, you'll want to take extra precautions to minimize the severity or even the visibility of that impact. Someone in the organization should already know the peak times when users are most likely to be accessing the application. Testing outside of these peak times will automatically reduce your risk. There are also larger business drivers at play that you need to consider. Depending on the organization's industry, there may be times of the year or a month where testing is off limits. Retailers for example often implement a code freeze before, during, and after holiday seasons. During this freeze, nothing is allowed to take place, nothing that might impact those production e-commerce apps. Emergency break fixes only. One other consideration when determining in-scope and out-of-scope times is the monitoring and response capability of the operations and the security teams. Your testing activity could very well set off alerts, and those alerts could be misinterpreted as an actual attack depending on who's on call at the time. Talk through all of this with those teams, and the time frame you ultimately select will be the best choice for everyone. Don't assume any of this information when scoping your test. Get it in writing. Your scope will be directly impacted by your hosting provider requirements if your in-scope apps live on their infrastructure. Amazon Web Services has a well-defined policy regarding what you're allowed to test and what you're not. If you're hosting any of your in-scope applications with AWS, make sure your testing scope aligns with their requirements. And while Microsoft doesn't require you to notify them before performing penetration tests against Azure resources, they do require you to comply with their unified penetration testing rules of engagement. Their site details standard tests that you're permitted to perform, tests that are explicitly prohibited, and the penetration testing rules of engagement that apply to their shared environment. And if you're hosting apps in Google Cloud, you need to be familiar with how your scope aligns with their acceptable use policy and their terms of service. They don't require you to notify them ahead of time, but they do require you to abide by the rules outlined in these two agreements. For any hosting provider you're using that I haven't listed here, please check with them beforehand when scoping your web app pen test.