Ruslan Rakhmetov, Security Vision
Today's attackers use several effective attack vectors, the main ones being phishing, exploitation of VPOs, and vulnerability exploitation. Vulnerabilities are what allow attackers to penetrate protected infrastructure, and automated application vulnerability scans help them scale and accelerate cyberattacks. Many companies, especially large companies, develop their own software, from utility tools to heavy-duty web applications. In this case, the company itself is responsible for detecting vulnerabilities in a timely manner and issuing updates to fix them. Both attackers and developers, despite their diametrically opposed goals, are interested in detecting vulnerabilities quickly - various methodologies and tools are used for this purpose. In this article, we will review the main methods of testing IS applications using white box, grey box and black box methods.
Let's start with the terminology:
- White box method (White box, open box method) implies testing a system (software) with prior knowledge about it - architecture, documentation, source code, description of its behaviour;
- The Gray box method involves testing a system (software) with partial prior knowledge about it - a general description of the whole system or more precise descriptions of only some of its parts may be known;
- Black box method (Black box method) means testing a system (software) without prior knowledge of it - without understanding its architecture, without documentation and source code, without initial understanding of its behaviour.
1. White box testing
The white box method is used by developers, testers, IS auditors and AppSec specialists who need to monitor software security at every stage of the lifecycle. The open box method is also used to eliminate all bugs and errors that do not directly affect security, but can negatively impact user experience and information system performance. White box checks usually take a long time due to the rather large testing depth and multifaceted nature of the checks (security, functionality, UI/UX, compatibility, etc.). To increase the efficiency of white box checks, a system (software) can be decomposed into several constituent parts or logical modules, testing each of them sequentially and then checking their connectivity and interaction as a whole. In addition, it is the "open box" method that makes it possible to analyse attack scenarios by an insider, who may have legitimate privileged access to the system and a good knowledge of its features and even its architecture.
To automate testing using the "white-box" method you can use static code analysis methods, in particular, use static analysers and solutions for static application security testing (SAST, Static Application Security Testing). Static analysers are solutions for automating the extremely time-consuming manual process of code review which implies reading the source code and forming recommendations for its improvement. The simplest static analysers are built into most compilers - they warn developers about trivial errors and misprints. SAST solutions focus on detecting vulnerabilities in code at the earliest stages when the price of fixing an error is much lower. Static code analysis tools do not guarantee a hundred per cent result, give a high level of false positives, cannot detect configuration errors - in general, their task is to highlight possible problem spots to developers, testers and IS auditors and automatically check the code for the most common types of errors. To work effectively with static analysers and with the "white box" method in general, testers will need high expertise and considerable labour input. Besides, such tools as software composition analysis (SCA, Software Composition Analysis) and open source analysis (OSA, Open Source Analysis) can be used as part of white box testing.
If we turn to the regulatory and legal documentation, then in the standard GOST R 56939-2024 "Information Protection. Development of secure software. General requirements" static analysis of the source code of a program is defined as a type of works on the instrumental research of a program based on the analysis of the source code of a program with the use of specialised tools (static analysers) in the mode not providing for the code execution and performed to determine the properties of a program; in particular, static analysis is used to detect potential errors in a program. Besides, the standard GOST R 71207-2024 "Information Protection. Development of secure software. Static analysis of software. General requirements".
Note that attackers can also use the white box testing method, but only for products whose source code they have access to - for example, Open Source solutions used by the target victim company, or if they have gained access to the source code of a product that is already in use by various customers.
2. Gray box testing
Gray box testing allows a company to compensate for some of the disadvantages of white box testing - such as resource-intensive and time-consuming, as well as partially replicate the actions of an attacker who has limited privileges on the system. Gray box testing can simulate attack scenarios from an APT group that has been collecting information about the victim and the software they use for a long time - as a result, such advanced attackers gain partial knowledge of how the system works and what techniques can be used to compromise it. In the case of pentesting a system, experts have a general understanding of the system's architecture beforehand and have limited accounts within the system (e.g., user privileges rather than administrative privileges). On the one hand, such restrictions narrow the scope of the pentest and do not allow to identify all vulnerabilities, on the other hand - do not give pentesters the opportunity to accidentally disrupt the information system. Grey-box testing can be chosen by those companies that have concluded from threat and intruder modelling that attacks by highly motivated attackers (APT groups, cybercrime syndicates, cyberarmies, advanced hacktivists) are relevant to them.
3. Black box testing
The black box method allows to look at the software or information system as a whole through the eyes of external attackers who, without prior knowledge of it, will search for potentially exploitable vulnerabilities by searching for entry points, web forms, transmitted parameters and potentially dangerous constructs and elements using debuggers and decompilers. In addition, attackers will look for vulnerabilities not only in the system itself, but also in its configuration and in the defence measures applied, including antimalware defences. Thus, the "closed box" method allows modelling the actions of real attackers with different degrees of preparedness and determination.
Black box testing can be divided into five phases:
- Exploration: obtaining initial information about the target (system or software), including searching for documentation, manuals, customer reviews, product user communities on social networks;
- Scanning: looking for "entry points" such as open ports, banners, API endpoints, data entry forms, methods available for invocation, web requests;
- Enumeration: obtaining detailed information about the system under attack, including user accounts and groups, directories, shared folders, infrastructure data, and devices on the network;
- Gaining access: unauthorised (or authorised, in the case of pentest) access through password cracking, exploitation of vulnerabilities, social engineering;
- Privilege escalation and entrenchment: Successful pentesting typically requires elevated privileges as well as methods to maintain access to the compromised network (e.g., backdoors, reverse-shells, remote online management tools).
Automation tools such as DAST (Dynamic Application Security Testing) solutions can be used in black box testing to detect vulnerabilities and simulate how users and attackers work with the system. Unlike SAST, dynamic code analysis solutions do not have access to the source code, but they allow detecting errors and vulnerabilities while a compiled program is running. If we refer to the definition from the standard GOST R 56939-2024, dynamic program code analysis is defined as a type of work on instrumental program research based on the analysis of program code in the mode of direct execution (functioning) of the code. In general, DAST solutions work with the software under test from the point of view of the user (or attacker), whose task is to find a vulnerability in the running application. For this purpose, among other things, the fuzzing method is used, in which incorrect, incorrectly generated, unexpected or random data is deliberately fed to the application's input in order to test the application's security and resistance to such errors.
Thus, DAST solutions help to detect errors at later stages of the software development life cycle, but may allow detecting vulnerabilities that appear only after the programme is installed and launched (e.g. configuration vulnerabilities). In addition to DAST, IAST (Interactive Application Security Testing) and BAST (Behavioral Application Security Testing) products are also used, which also work with an application that is already running and can detect flaws later in the development cycle. IAST solutions check the security of command and data flows of a running application and check its work with the execution environment and infrastructure (for example, file access, calling system functions, opening sockets, etc.). BAST solutions verify the security and correct operation of business-critical application functionality (e.g., access to sensitive data, use of encryption, user authentication, etc.).
To summarise, the following characteristic differences between SAST white-box testing tools and DAST black-box testing tools can be highlighted:
- The SAST solution analyses the source code of the system, while the DAST solution tests an already completed and running application;
- SAST involves testing the internal components of the system from the developer's perspective, while DAST tests the external "shell" of the system by simulating the actions of an attacker;
- SAST cannot detect flaws and vulnerabilities related to the execution environment or that only manifest themselves at runtime, while DAST can;
- SAST detects flaws and vulnerabilities in a system earlier in the development lifecycle, which helps reduce the cost of fixing them, while DAST detects problems later in development, which increases the cost of fixing them;
- For more efficient elimination of errors and vulnerabilities it is recommended to use both SAST and DAST tools together at different stages of software development, as well as to apply solutions of IAST, BAST, SCA, OSA classes.
.jpg)
