White Box Testing
In the quality assurance world, white box testing is nothing of a revelation. Also referred to as an open box clear box or simply ‘informed testing’, white box testing enables all information about the system under test to be known to the tester. In security parlance, this is also referred as an insider attack. Since the tester has access to the design documentation and source code, he can tester be efficient, do a line-by-line code review or can threat-model the system, thereby exploring information to guide the selection of test data.
Being one of the most effective ways to find security vulnerabilities, white box testing provides an accurate picture of the system’s security and consequent vulnerabilities as it doesn’t rely on security by obscurity (i.e. hoping that attackers will never discover information about how a system works). The assumption that follows in white box testing is that ultimately all data pertaining to the system will be leaked or discovered.
One of the major benefits of white box testing is having access to the code, which makes it the only method of reaching 100% coverage in testing, in principle. Various white-box testing techniques can be utilized to catch irregular or suspicious codes at the stage of programming as well as when the code is being executed/performed.
Making the Code Readable- A prerequisite for catching problems is to make the code more readable and thereby easier to understand and debug. Good programming practices and coding conventions can help in standardizing the code, and they will also help in implementing various automated tools in the validation process. An example of such quality improvements is compile-time checks, which will detect the use of insecure function calls and structures.
Inspections and Reviews- Static analysis methods, such as various types of inspections and reviews, are widely used, and they are critical to the development of good-quality software. Inspections can focus on software development documents or the actual code. A requirement for successful inspections and reviews is agreeing on a policy on how the code should be implemented. Several industry standards from bodies like IEEE have defined guidelines on how and where inspections and reviews should be implemented.
Code Auditing- The simplest form of white-box testing is code auditing. Some people are more skilled at noticing flaws in code, including security mistakes, than others. In terms of security, the simplest code auditing tools systematically search the code looking for susceptible functions, including sprintf(), strcpy(), gets(), memcpy(), scanf(), system(), and popen(), because they are often responsible for overflow problems. Such a simplistic approach will necessarily reveal many false positives because these functions can be used safely. More complex auditing tools analyze the entire program’s structure, have models that represent common programming errors, and compare the structure of the program to these models.
A code review can take place either off-line or during compilation. Some static analysis tools check the compiled result of the code, analyzing weaknesses in the assembly code generated during compilation of the software module. Compilers themselves are also integrated with various quality-aware functionalities, issuing warnings when something suspicious is seen in the code or in an intermediate representation. Thus, the problem usually encountered with tools enabling code auditing is a number of false-positive issues, which are security warnings that pose a little security risk. Another major problem that is encountered with a majority of code-auditing practices is that they can only find problems they are taught to find, meaning the functionality of executing actions on its own is absent- a major drawback to security testing.
Grey Box Testing
Usually, security testing is a combination of white and black box techniques. Whereas white box testing allows discovery of functionality flaws occurring in the development and design of the product, black box testing is utilized to ensure the discovery of flaws without having access to application internals. A combination of both these techniques is referred to as grey box testing.
In a grey box testing technique, the tester ensuring application security performs grey box testing in order to find vulnerabilities in software design or flaws occurring due to unspecified functionality. The tester gains the advantage of the grey box by running the software under test in a debugger (i.e. black box test) and melding it with the source code. Once the software runs in the debugger, black box testing can be used by means of various automated regression suites or fuzzers. The tester can thereafter put a number of breakpoints on lines of code that are dangerous, in order to ensure they cannot be accessed with an external input to the program.
Testing has to be measurable and quality assurance practices have used various means of validating the quality of the tests themselves. Black and Gray box methods of testing can be instrumental in improving the security of your business and products.