White Box vs. Black Box Web Application Penetration Testing
Information Security can be a difficult topic for organizations to understand and communicate about for a variety of reasons, but perhaps none more prevalent than the terminology that gets thrown around. As such a dynamic and fast-moving industry, it can be hard for inside veterans to get on the same page about certain topics, much less folks that don’t have InfoSec as part of their primary job description. In this vein, we tend to get a lot of questions asking for help translating requirements that are part of vendor self-assessment questionnaires (VSAQs) or other due diligence-style information requests. One of the most confusing revolves around web application penetration testing requirements, as there’s often not a lot of information on the specifics of that testing and the investment/results can vastly differ. Let’s dive into one particular aspect of this, which is the use of white box vs. black box testing.
First, let’s lay some foundation for the terms “white box” and “black box” themselves. White box is usually used as a synonym for a “full-knowledge” type of assessment. A tester has access to anything related to the testing target that they need and can access any bit of information that may be useful in assessing a target. The opposite to that paradigm would be a black box assessment, also known as “zero-knowledge”. As the astute reader may have guessed at this point, this is where a tester is not provided with any information about a target.
How Does This Apply to Web Applications?
So now with a basic understanding of the context behind these terms, how can they be applied to web application penetration tests in particular? Well the answer is that in most cases, it depends. In most types of penetration testing services performed, the actual process is more of a grey-box approach (somewhere in between white box vs. black box) due to client limitations, the desire to identify as many security issues/vulnerabilities as possible, and the goal of emulating real threat actors. It can also depend on the person asking you for these types of penetration testing and what their interpretations of the terms are.
The key features that tend to make something a white box web application penetration test are:
- Information about application architecture provided, such as language, technologies, frameworks, etc.
- Credentials provided to perform authenticated testing
- Source code provided to allow for static analysis in concert with dynamic testing
Of those items, the first two are oftentimes part of grey-box web application penetration tests, too. You really need to be doing both unauthenticated and authenticated testing to do any kind of thorough application-level assessment. The thing that truly makes something a full-knowledge web application penetration test is that the source code is given to the test team. This allows for a level of auditing/review that would make it possible to find many types of vulnerabilities that would be impossible to find during a black box test. The drawback, as you might guess, is the additional time it would take to perform this kind of assessment, which translates into a higher investment from an organization looking to have this sort of testing performed.
Triaxiom’s Approach for Web Application Penetration Testing
As I alluded to above, Triaxiom is similar to most penetration testing firms we’ve seen in that a web application penetration test is usually a grey-box approach that mixes the best of both worlds. We want to adequately emulate an attacker to give you a realistic view of your risk, while providing you as in-depth and holistic an assessment as we can in the time we have. This is balanced by the need to control time and cost for the assessment so that it is accessible to all the organizations that need it.
All of our web application penetration testing includes both unauthenticated and authenticated testing, so we’ll always ask for credentials for the user roles that are in scope. This allows us to identify vulnerabilities that could be leveraged by an external attacker to gain access and vulnerabilities that could result in information disclosure between users/clients or privilege escalation, as these issues can be just as devastating for an organization. We may also ask for an application walkthrough at the beginning of the assessment. This allows us to gain an understanding of normal business operations for an application, especially when they are large and/or complex. As a result, we can jump into testing more quickly and efficiently to unveil high value security issues.
In the end, it can be hard to discern what is being asked of you when it comes to required web application penetration testing. And there could be a lot riding on getting the right answer, fast. We’re always happy to help translate requests into understandable terms so you can make a decision based on the type of testing you’re being asked to have performed, and get you accurate pricing for what that type of testing could cost you at the same time. So please reach out if you have questions or need help in this area!
