Apache Security - Ivan Ristic [180]
Library files
Library files should never be kept under the web server tree either, but they are found there sometimes. This is relatively safe (but not ideal) provided the extension used is seen by the web server as that of a script. Otherwise, having such files under the web server tree is a configuration error. For example, some programmers use a .inc extension for PHP library files or a .class extension for individual PHP classes. These will probably not be recognized as PHP scripts.
Obscure files
This class covers temporary files placed under the web server for download, "special" folders that can be accessed by anyone who knows their names. Such files do not belong on a web site. Temporary files should be moved to the assessment storage area immediately. If there is a genuine need for functionality that does not exist (for example, secure download of certain files), a note should be made to implement the functionality securely.
Uploaded files
If file upload is allowed, the folder where writing is allowed should be configured not to allow script or code execution. Anything other than that is a code execution compromise waiting to happen.
Files that should not be there
All sorts of files end up under the web server tree. Archives, backup files created by editors, and temporary files are dangerous as they can leak system information.
At the end of this step, we go back to the file permission report and note as errors any assigned permissions that are not essential for the application to function properly.
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:
Basic review to understand how the application works
Review of critical application components
Review of hot spots, the parts of the code most vulnerable to attacks
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.
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:
Input validation
Input data should never be accessed directly. Individual bits of data should first be validated for type ("Is it a number?") and meaning ("Birth dates set in the future are not valid"). It is generally accepted that the correct strategy to deal with input is to accept what you know is valid (as opposed to trying to filter out what you know is not).
Output escaping
To prevent XSS attacks, output should be properly escaped. The correct way to perform escaping depends on the context. In the case of HTML files, the metacharacters < (less than), > (greater than), & (ampersand), ' (single quote), and " (double quotes) should be replaced with their safe equivalents: <, >, &, ', and ", respectively. (Remember that an HTML file can contain other types of content, such as Javascript, and escaping rules can be different for them.)
Database interaction
Examine how database queries are constructed. The ideal way is through use of prepared statements. Constructing queries through string concatenation is easy to get wrong even if special care is taken.
External system interaction
Examine the