Download Apache Security - Ivan Ristic - Oreilly - 2005 - My E

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?
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:
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.