11.2. White-Box Testing
White-box testing is the complete opposite of what we have been doing. The goal of black-box testing was to rely only on your own resources and remain anonymous and unnoticed; here we can access anything anywhere (or so the theory goes).
The key to a successful white-box review is having direct contact and cooperation from developers and people in charge of system maintenance. Software documentation may be nonexistent, so you will need help from these people to understand the environment to the level required for the assessment.
To begin the review, you need the following:
At the end of your white-box testing, you should have a review report that documents your methodology, contains review notes, lists notices, warnings, and errors, and offers recommendations for improvement.
11.2.1. Architecture Review
The purpose of the architecture review is to pave the way for the actions ahead. A good understanding of the application is essential for a successful review. You should examine the following:
Further questions to ask yourself at this point are:
11.2.2. Configuration Review
In a configuration review, you pay attention to the environment the application resides in. You need to ask yourself the following questions:
184.108.40.206 Preparing a storage area for review files
To begin your configuration review, create a temporary folder somewhere to store the files you will create during the review, as well as the relevant files you will copy from the application. We assume the path /home/review is correct.
As you are making copies ensure you do not copy some of the sensitive data. For example, you do not want to make a copy of the server's private key. If configuration files contain passwords, you should replace them with a note.
There can always be exceptions. If you have a good reason to make a copy of a sensitive file, go ahead and do it. Review results are likely to be classified as sensitive data, too.
220.127.116.11 Preparing a file listing and initial notes
Armed with the knowledge of how the application works (or how it should work), we go to the filesystem to assess the configuration. This part of the review starts by creating a record of all files that are part of the application. I find it useful to have a folder tree at the beginning followed by the detailed listing of all files:
# find /home/application/ -type d | sort > /home/review/filelist.txt # echo >> /home/review/filelist.txt # ls -albR /home/application >> /home/review/filelist.txt
In the example above, I have assumed the application sits in the /home/application folder. Ideally, all application files will reside within a single folder. If they do not, the review should include all relevant folders. For now we assume we have everything listed in the file filelist.txt.
Continue to use the same file for your notes. It is convenient to have everything in one place. You will need at least two console windows and a browser window to test assumptions you make during the review. In your notes, include the following:
18.104.22.168 Reviewing the web server configuration
Make a copy of the web server configuration files first. Then examine the relevant parts of the configuration, making notes as you go. Remember to include the .htaccess files in the review (if used). Record the following information:
In most cases, you can copy the server configuration and add your notes to it. Remember your audience will include people who do not know how to configure Apache, so your notes should translate the configuration for them.
Creating a comprehensive checklist of things to look for in web server configuration is difficult. The approach most likely to succeed is to compare the documented requirements (if they exist) with the actual configuration to find flaws. Ask yourself if the web server is configured to mitigate DoS attacks (see Chapter 5).
22.214.171.124 Reviewing the application configuration
Applications typically have their own configuration files. You need to know where such files are stored and familiarize yourself with the options. Make copies of the files for record-keeping purposes.
You will probably be interested in options related to logging and access control. Applications often need their own password to access other parts of the system (e.g., a database), and you should note how those passwords are stored. If the application supports a debugging mode, you need to examine if it is used and how.
Examine how a connection to the database is made. You do not want to see:
The web application should have minimal database privileges. It is acceptable for an application to use one account to access a database and have full privileges over it. It is not acceptable to be able to access more than one database (think about containment). The application privileges should be further restricted wherever possible (e.g., do not allow the account to drop tables, or give it read-only access to parts of the database).
The same concept ("least privilege used") applies to connections to other types of systems, for example LDAP.
126.96.36.199 Reviewing file permissions
When reviewing file permissions, we are interested in deviations from the default permissions, which are defined as follows:
We examine the potential for information leakage first, by understanding who is allowed read access to application files. If read access is discovered and it cannot be justified, the discovery is marked as an error. We automate the search using the find utility.
Examine if any suid or guid files are present. Such files allow binaries to run as their owner (typically root) and not as the user who is executing them. Their presence (though unlikely) may be very dangerous, so it is worth checking for them:
# find /home/application -type f -and \( -perm -4000 -or -perm -2000 \) | xargs ls -adl
The following finds world-readable files, where any system user can read the files and folders:
# find /home/application -perm -4 | xargs ls -adl
The following finds files owned by users other than the application user:
# find /home/application ! -user appuser | xargs ls -adl
The following finds group-readable files, where the group is not the application group:
# find /home/application -perm -40 ! -group appgrp | xargs ls -adl
Allowing users other than the application user write access opens a whole new attack vector and is, therefore, very dangerous. This is especially true for the web server user because it may be possible for an attacker to control the publicly available scripts to create a file under the application tree, leading to code execution compromise.
The following finds world-writable files:
# find /home/application -perm -2 | xargs ls -adl
The following finds files owned by users other than the application user. This includes files owned by the web server user.
# find /home/application ! -user appuser | xargs ls -adl
The following finds group-writable files, in which the group is not the application group (group-writable files are not necessary but there may be a good reason for their existence):
# find /home/application -perm -20 ! -group appgrp | xargs ls -adl
188.8.131.52 Reviewing the files
We now go through the file listing, trying to understand the purpose of each file and make a judgment as to whether it is in the right place and whether the permissions are configured properly. Here is advice regarding the different types of files:
11.2.3. Functional Review
The next step is to examine parts of the source code. A full source code review is expensive and often not economical (plus it requires very good understanding of programming and the technology used, an understanding only developers can have). To meet our own goals, we perform a limited review of the code:
184.108.40.206 Basic application review
In basic application review, you browse through the source code, locate the libraries, and examine the general information flow. The main purpose of the review is to identify the application building blocks, and review them one by one.
220.127.116.11 Application infrastructure review
Web applications are typically built on top of infrastructure that is designed to handle common web-related tasks. This is the layer where many security issues are found. I say "typically" because the use of libraries is a best practice and not a mandatory activity. Badly designed applications will have the infrastructure tasks handled by the same code that provides the application functionality. It is a bad sign if you cannot identify the following basic building blocks:
18.104.22.168 Hot spot review
You should look for application hot spots by examining scripts that contain "dangerous" functions, which include those for:
Some hot spots must be detected manually by using the application. For others, you can use the find and grep tools to search through the source code and tell you where the hot spots are.
First, create a grep pattern file, for example hotspots.txt, where each line contains a pattern that will match one function you would like to review. A list of patterns to look for related to external process invocation under PHP looks like this:
exec passthru proc_open shell_exec system ` popen
Next, tell grep to search through all PHP files. If other extensions are also used, be sure to include extensions other than the .php one shown.
# find . -name "*.php" | xargs grep -n -f hotspots.txt
If you find too many false positives, create a file notspots.txt and fill it with negative patterns (I needed to exclude the pg_exec pattern, for example). Then use another grep process to filter out the negative patterns:
# find . -name "*.php" | xargs grep -n -f hotspots.txt | grep -v -f notspots.txt
After you find a set of patterns that works well, store it for use in future reviews.