Web applications are essentially a complex set of functioning systems. They store, process, and transmit critical data. Like any other intricate web-based system handling valuable information, they are also susceptible to hackers who can find vulnerabilities. For many businesses and organizations their web applications are one of the key assets. Not only their business operations depend on it but their brand image depends on it too. Most businesses today are just one data breach incident away to be labelled as unsafe and unsecure for users. With so many organizations, of all sizes and scales, falling victim to damaging cyber-attacks, companies are willing to ensure best possible security for their internal and external web applications. Although vulnerability scans are commonly considered ‘good enough’ to secure the web applications but they only highlight known weaknesses. Alternatively, web application penetration testing demonstrates how well a web-app would resist a real-world attack by an unauthorized user.
Penetration testing or the more commonly known term to developers – Pentesting assignments are classified based on the level of knowledge and access granted to the testers at the preliminary stages of a particular assignment. The scale runs from black-box testing, where the tester is given minimal knowledge of the target system, to white-box testing, where the tester is granted a much higher level of knowledge and access. This range of knowledge makes different testing methodologies ideal for different situations.
Black-Box Pentesting
It is the most basic level of pentesting that as an obvious benefit requires very minimum efforts from the client. A pentester testing an e-commerce web application will usually only be able to test the login page and any other publicly accessible pages like its contact forms etc. for vulnerabilities. Unless the pentester is able to breach the login page and gain access to the application, no further functions would be testable. This is similar to an outsider trying to break into a system with limited knowledge. The primary disadvantage of black-box is that it yields limited information about real vulnerabilities of a target system.
Typical Vulnerabilities Uncovered In Black-Box Pentesting
- Injection vulnerabilities on forms
- Web server misconfigurations (eg. directory access to sensitive files, TLS issues)
- Web server vulnerabilities (eg. Heartbleed, default CGI access)
- Password guessing and Login Bypass
- Network vulnerabilities
White-Box Pentesting
Unlike the black-box approach, white-box pentesting is a very cumbersome exercise on the client’s end. The client is heavily engaged to help the designated tester understand the web application’s system to the core, granting them full admin access and detailed information including source code and documentation of the web application. With this, enumeration or fuzzing is less required, since vulnerabilities can be directly verified on the source code or through the server access.
White-box pentesting is also considerably labor-intensive on the tester’s end. A lot more time needs to be invested in analyzing the information. The advantage, though, is that white-box pentests provide the most comprehensive report when it comes to understanding complex vulnerabilities such as logic flaws or second order injections.
A white-box approach can uncover a vulnerability located in a backend batch job function that requires several conditions to be fulfilled together in order to be successfully exploited — for instance, being able to locate the right parameter to inject on the correct form with the correct test payload and knowing exactly when the execution happened. In a black-box or gray-box approach, it is not easy to detect such a vulnerability.
Typical Vulnerabilities Uncovered In White-Box Pentesting
- Hidden or hard-to-reach functions
- Security control bypass
- Second order injections
- Complex logic flaws
- Vulnerabilities found in both black and gray-box approaches
Gray-Box Pentesting
The final shade of gray-box pentesting falls between the black-box and white-box approach, to no one’s surprise.
The gray-box pentesting is the most popular option because
- Balanced effort on client’s end: The client needs to only provide partial information such as API documentation about the target system.
- Balanced effort on tester’s end: The partial information provided minimizes the need for enumeration or fuzzing of the target system.
- Flexibility: If more support is required at any point in time, such as code snippets, the tester can simply request the information from the client.
- Privacy on client’s end: The client does not need to reveal too much proprietary or sensitive information such as source code.
For instance, if the pentester was planning to exploit a cross-site scripting vulnerability, they would simply request for the blacklist or whitelist filter from the client and find the right payload to exploit the vulnerability. This can potentially save the tester hours of guessing or extensive fuzzing to find that payload.
For most part of it picking the right pentesting methodology for your business isn’t as straightforward as just choosing a color of your liking. You need to align the right pentest type to your goals and your willingness to follow up on the test results, be that a simple management report establishing annual security system considerations or maybe an attack simulation to prove or even deny that operations and security teams are ready for whatever threats come their way.
