Case Your Own Joint

Every complex software program has costly security vulnerabilities. These are the vulnerabilities that allow viruses and worms to thrive and that allow criminals to grab personal financial data from websites. Ideally, security is designed into a program, and the program is coded by developers trained in secure programming. Yet, even when this philosophy is adhered to, security flaws creep in as mistakes are made, and complex software interactions go unnoticed.

Security researchers have developed a way to perform vulnerability testing during the development process: application penetration testing. Application penetration testing is a way to break into a software application to uncover its security flaws. Programmers and testers can use this little-known technique to find security flaws in their programs while they’re in development.

This article will teach you how to prioritize your security testing, how to build a lab environment for security testing, and how to actually stage attacks to uncover application security flaws.

Prioritize Security Testing
Application penetration testing, like code review, is still a mostly manual process. Therefore, prioritizing the risk of program interfaces and features is crucial for finding the most serious security flaws first. To come up with this prioritized list, I recommend threat modeling. (See sidebar on p. 32 for an in-depth look at threat modeling.) In threat modeling, potential risks are hypothesized based on an understanding of the application's design, not on how an application was meant to be used. An example threat might be "authentication process accepts data from anonymous users and passes it to the SQL server." The output of threat modeling is a list of threats. In this example, if the program properly validates input, it will have mitigated this threat, which then would not be considered a vulnerability.

Once hypothesized, the threats then are ranked according to how easy they are to attack and the seriousness of the impact of that attack. The risks that are easiest to attack but whose exploitation yields the greatest impact are the threats that should be focused on first during staged attacks, where the identified threats will be attacked to determine if they are actual vulnerabilities.

Build A Lab Environment
Note that a "threat" is only a potential "vulnerability." We need to determine which threats on our prioritized list are, in fact, vulnerabilities. To do this, we need to stage some application attacks. The best place to do this is in a lab environment so that every aspect of an attack can be controlled. Typically, this will include an isolated network that is instrumented and under our control, so we can stage any potential network attacks. The software should be installed on an instrumented machine. This is similar to the hardware and software that a developer would use to debug the application. In a client-server application, we want to have both the client and server software installed on instrumented machines so we can control every input.

It is important to be able to generate any arbitrary network traffic. Many applications make the assumption that the network input they receive is well formed. Attackers can exploit this assumption to get a program to perform erroneous processing on the malicious input they provide. This erroneous processing often leads to buffer overflows, a common vulnerability.

Common security mechanisms used by programs that communicate over the network are authentication and session management. These allow the application to verify that incoming data was actually sent by a user who has been validated by the application. In order to modify the data sent to such a program, it is often easier to perform a man-in-the-middle class of attack than to