What Can Go Wrong During a Web Application Penetration Test?
In today’s blog, we’re going to discuss what can go wrong during a web application penetration test and some strategies that can help you and your testing team avoid running into these issues. Any type of penetration test is an exercise in identifying and exploiting vulnerabilities in a target, just like an attacker would. In the case of web applications, finding and exploiting these vulnerabilities can be noisy and have unintended consequences, so the potential problems that can be encountered should be carefully considered and addressed by all stakeholders during the Rules of Engagement (ROE) review. By taking a collaborative approach during the planning phase and making sure everyone is on the same page as to what could potentially go wrong, the test team can work with the development team to greatly reduce the likelihood and impact of problems.
Some of the Potential Problems
Web applications are unique in that they are all different. From language to architecture to application frameworks, there are an infinite number of possibilities for what a penetration testing team will encounter during a web application penetration test. So with all this variation, it stands to reason that it is extremely hard for a tester to predict exactly how a website is configured, especially on the back-end. So some of the things that can go wrong during a web application penetration test include:
- Form submission results in erroneous entries to back-end database or data corruption – To adequately assess the security of a target application and identify all vulnerabilities, your test team is going to have to use the application and submit form fields throughout. Of course by doing this, there is likely going to be some kind of erroneous entries made to the back-end database in some cases. Worse, if there is a particularly bad vulnerability like SQL injection, these entries could result in portions of the database being accidentally overwritten or deleted altogether.
- Hidden automated processes are triggered by testing – As mentioned, all web applications are different and many modern web applications can do amazing things. We’ve seen back-end processes that are invisible to the application user, but dispatch sales executives to certain locations in an automated fashion when certain functions are triggered. While this is certainly useful for a production application, any automated processes like this or automated email triggers can cause issues if they are hit with an automated scan during dynamic application analysis.
- Service degradation due to automated scanning activities – Certain application architectures or configurations are not built for high load or contain legacy elements that do not handle stress well. While our automated web application scanning activities are not intended to explore and denial of service conditions are primarily consist of normal levels of application traffic, we’ve seen some apps struggle more than others. As with network penetration testing, particular vulnerabilities or misconfigurations can contribute to reduced web server responsiveness or a complete denial of service.
What Can You Do to Prepare and Reduce Risk
While all of the noted issues are not often encountered, we wouldn’t be talking about them if they didn’t happen from time to time. With that being said, of course there are ways to even further reduce the likelihood of your testing team running into any of these problems when performing a web application penetration test for your organization. Consider the following:
- Use a cloned or dev/test/QA environment for testing – When performing a web application penetration test, we prefer to assess an environment that mirrors production as closely as possible without actually being your main production web site. This is so we can reduce the impact to your organization if we do encounter problems while still giving you a robust and accurate depiction of your risk when we’re done. Using a lower-level or cloned environment with sufficient test data allows us to rigorously test an application without concern for data corruption or service degradation, and allows you more peace of mind while we complete testing.
- Make sure you’ve got full database back-ups before testing – This should be something your organization is doing on a regular basis anyways, but it’s never a bad idea to double and triple check that you’ve got recent and valid database back-ups that you are able to restore from, just to handle any “worst-case scenarios.” It also gives you a quick and easy way to restore your environment following a web application penetration test.
- Talk to your penetration team before the test – During the ROE review is a great time to voice any concerns you have about the testing process for the target application(s). This is also the time when your testing team should be asking you what potential impacts testing could have on your environment, e.g. form submissions that could trigger detrimental back-end processes or emails. By keeping open lines of communication, we can help ease your mind about the impacts or take the appropriate actions to help mitigate risks you are concerned about, such as tempering automated scans in certain areas or performing some scanning activity after-hours and manual testing during regular business hours.
With all that in mind, you should have a better picture of what can go wrong during a web application penetration test. While this niche of penetration testing is certainly more unique and requires more preparation than other variants, such as network-level penetration testing, there are some sensible steps you can take to better prepare for the process. If you have any questions are interested in getting started with a web application penetration test today, please reach out and we’d be happy to help!
