Reusing Existing Test Cases for Security Testing

Traditional test case generation methods usually consider coverage criteria like statement or path coverage and ignore security characteristics. The result is that a test case may fail to find vulnerabilities even if it covers the vulnerable statements. However, we argue that existing test cases are still of great value because significant human effort and time have been invested to achieve high coverage criteria. A high coverage indicates a high possibility that vulnerable statements occur in the execution traces of these test cases. Thus existing test cases could guide us to those vulnerable statements. Under this intuition, we present a method of security testing by re-examining existing test cases. The basic idea is to discover two types of constraints in a program: program constraints (PC) and security constraints (SC). The former are the constraints imposed by program statements. For example, an assignment statement i=0 constrains the value of i to be 0. The later are the constraints derived from security concerns. For example, a buffer should never be overflowed. Intuitively, a statement is vulnerable if it can make PCrarrSC be false, which means the program constraints are not strict enough to ensure the security constraints. We design and develop a tool named RETAST to demonstrate our idea and the initial result is promising.