White Box Application Penetration Testing

We’ve recently seen an uptick in vendor security assessment questionnaires (VSAQs) that are requiring organizations to do white box application penetration testing. Obviously this may be anecdotal, but we thought it would be a good opportunity to discuss what is being asked of you when it comes to white box or clear box testing, and how this kind of testing applies to web applications specifically. As large companies continue to outsource elements of their business operations to cloud-based software-as-a-service (SaaS) products, the number of VSAQs aimed at these providers is growing as well. Respondents are often unsure of how to meet their client or potential client’s requirements and what exactly they should be doing from a security assessment standpoint.

Many times, it’s hard enough for organizations to decipher and respond to one VSAQ for a potential customer. Combine this with the fact that they may be getting multiple VSAQs from different clients on a regular basis, all with different requirements and different wording, and you’ve got a recipe for confusion. So let’s start with some of the different testing/wording that may be asked of you for a web application specifically.

Authenticated vs. Unauthenticated Testing

When you’re testing a web application, one of the first questions is usually whether this is unauthenticated testing only or authenticated testing is included. With unauthenticated penetration testing, the test team isn’t provided any credentials to authenticate to the application and test it from the inside (from the perspective of an attacker that is able to gain access or from that of a malicious insider). This testing is solely conducted from outside the application trying to evaluate what is exposed to unauthenticated attackers and determine if a malicious actor can gain unauthorized access to the target application. While this is important, it’s often very limited in what it tells you from a security perspective, as there are a ton of different angles and a lot of different attack surfaces that aren’t being evaluated. Sometimes unauthenticated web application penetration testing is also known as black box or external testing, as well.

Conversely, most web application penetration testing should always consist of authenticated testing, as well. This means the penetration testing team is provided with credentials to authenticate as each of the different user roles available within the application to conduct testing from each of their perspectives. This means that testing is performed on all facets of the application, from the application perimeter to the internal functions. This allows vulnerabilities to be identified that could be exploited from within the application, allowing lateral movement or privilege escalation, for example. A thorough web application penetration should really always consist of authenticated testing.

Black Box vs. White Box Testing

Beyond the initial question of unauthenticated vs. authenticated testing, we need to consider black box, grey box, and white box testing. In black box testing, this is often called a zero-knowledge penetration test. The test team will be given a target URL but nothing more. No credentials, no information about the application, etc. With a white or clear box penetration test, the test team has full knowledge of the application, including access to developers to gain an understanding of business processes/intended use, credentials to fully explore the application, and, probably most importantly, access to the source code for the entire application. This last piece is what really differentiates white box testing in most scenarios, as access to source code provides a much more thorough and complete insight into potential vulnerabilities that otherwise may never be identified. Source code is analyzed for evidence of vulnerabilities, those vulnerabilities are evaluated for exploitability, and vice versa, as discovered vulnerabilities can be matched up with the pieces of source code associated with them.

In between these two types of testing, there’s also grey box testing that takes a hybrid approach between the two. Most high quality web application penetration tests will utilize this approach to strike a balance between time, thoroughness, and realism. With a grey box approach, the testing team will be given credentials and an understanding of the application, but not have full access to the source code. This helps create a more realistic attack scenario from the perspective of both an external attacker and a malicious insider.

So ultimately, the style of testing you need will depend on what questions you are trying to answer about security, the cost/thoroughness balance you are striving for, and what clients are asking of you from a security assurance perspective. White box application penetration testing, which can be the most thorough, may not be right for everyone or every scenario. Hopefully this helps you understand what is being asked of you a little bit better to help avoid confusion and make sure you are the getting the type of testing you need to meet compliance. If you have any questions about the type of testing you need to meet a specific VSAQ or client requirement, we’d love to help so feel free to reach out!