Apache Security - Ivan Ristic [177]
To begin the review, you need the following:
Complete application documentation and the source code.
Direct access to application developers and system administrators. There is no need for them to be with you all the time; having their telephone numbers combined with a meeting or two will be sufficient.
Unrestricted access to the production server or to an exact system replica. You will need a working system to perform tests since looking at the code is not enough.
The process of white-box testing consists of the following steps:
Architecture review
Configuration review
Functional review
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.
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:
Application security policy
If you are lucky, the application review will begin with a well-defined security policy in hand. If such a thing does not exist (which is common), you will have difficulties defining what "security" means. Where possible, a subproject should be branched out to create the application security policy. Unless you know what needs to be protected, it will not be possible to determine whether the system is secure enough. If a subproject is not a possibility, you will have to sketch a security policy using common sense. This security policy will suffer from being focused too much on technology, and based on your assumptions about the business (which may be incorrect). In any case, you will definitely need something to guide you through the rest of the review.
Application modules
Code review will be the subject of later review steps. At this point, we are only interested in major application modules. A typical example would be an application that consists of a public part and the administrative interfaces.
Libraries
Applications are built onto libraries that handle common tasks. It is these libraries that interact with the environment and should be the place to look for security problems.
Data
What kind of data is the application storing? How is it stored and where? Is the storage methodology secure enough for that type of data? Authentication information (such as passwords) should be treated as data, too. Here are some common questions: Are passwords stored in plaintext? What about credit card information? Such information should not be stored in plaintext and should not be stored with a method that would allow an attacker to decrypt it on the server.
Interaction with external systems
Which external systems does the application connect to? Most web applications connect to databases. Is the rule of least privilege used?
Further questions to ask yourself at this point are:
Is the application architecture prone to DoS attacks?
Is the application designed in such a way as to allow it to scale to support its users and processing demands?
Configuration Review
In a configuration review, you pay attention to the environment the application resides in. You need to ask yourself the following questions:
What
What operating system is the server running? What kind of protection does it have? What other services does it offer?
How
Is the server exclusively used for this application? Are many applications sharing the same server? Is it a shared hosting server managed by a third party?
Who
Who has access to the system and how? Shell access is the most dangerous because it gives great flexibility, but other types of access (FTP, CGI scripts) can become equally dangerous with effort and creativity.
Preparing a storage area for review files
To begin