A Model-Driven Penetration Test Framework for Web Applications

Transcription

1 2010 Eighth Annual International Conference on Privacy, Security and Trust A Model-Driven Penetration Test Framework for Web Applications Pulei Xiong, Liam Peyton, SITE, University of Ottawa, {xiong, lpeyton}@site.uottawa.ca Abstract Penetration testing is widely used to audit the security protection of Web applications. However, it is often performed by specialized security experts after development is completed and the application deployed into production. In this paper, we propose a model-driven penetration test framework for Web applications which provides a repeatable, systematic and cost-efficient approach fully integrated into a Security-Oriented Software Development Life Cycle. Security experts are still required to maintain knowledge used by the framework, but regular testing personnel are capable of creating, running and maintaining penetration test campaigns. A prototype of the framework has been implemented and applied to two Web applications: the benchmark WebGoat web application, and a hospital adverse event management system currently under development. A preliminary evaluation based on the prototype demonstrates the feasibility and efficiency of the proposed framework. Index Terms Model-Driven, Penetration Testing, Software Engineering, Web Security W I. INTRODUCTION EB applications have evolved from static Web sites which only host html pages, to database-driven N- Tiered applications with AJAX interfaces that implement complex business logic to provide critical services. Web applications live on the Web, and are open to all Web users both legitimate users and malicious users. There are numerous attacks against Web applications every day which can exploit any vulnerability in these applications. Vulnerabilities can result at any point in the development lifecycle due to either design or implementation errors or omissions. Furthermore, as Web applications evolve and new technologies are adopted, new vulnerabilities continue to emerge. Penetration testing is widely used in industry to uncover vulnerabilities in Web applications. However, penetration testing is often considered as a post-deployment vulnerability assessment task and is conducted as an isolated test process in a manual and even ad-hoc fashion. As the results, it suffers the problems of: a) Post Development: Any security flaws found after development are more costly to fix. Difficult to combine with supplementary security test methods such as code review. b) Manual, One-Time Audit: The tests require specialized manual effort which can be hard to duplicate. Follow up on fixes to vulnerabilities found can be inconsistent and incomplete and it is difficult to keep up to date as new vulnerabilities appear. c) Security Expert Dependent. The quality of a test campaign relies on the expertise and diligence of a security expert. Consequently, test results cannot be consistently reproduced, which make the test results less reliable, less measurable, and less assessable. In this paper, we propose a model-driven penetration test framework for Web applications which provides a repeatable, systematic and cost-efficient approach fully integrated into a Security-Oriented Software Development Life Cycle. Security experts are still required to maintain knowledge used by the framework, but regular testing personnel are capable of creating, running and maintaining penetration test campaigns. A penetration test campaign is conducted as an integrated process in the Software Development Life Cycle so that vulnerabilities in an application can be uncovered and fixed earlier. In this integrated test campaign, a penetration tester can collaborate with developers and utilize development artifacts to improve the cost-efficiency of the test campaign. In particular, a grey-box test approach can be taken to leverage knowledge of the application and its component architecture. And penetration testing can be used with other supplementary security test methods such as guided code review to improve the quality of the test campaign. In our proposed framework, a structured web application security test model is defined and linked to reference databases maintained by security experts who catalog known vulnerabilities, attack vectors and fuzz vectors in order to characterize penetration tests. A test platform is provided based on a penetration test campaign model and a modeldriven architecture to automate the major processes in test campaigns. These test campaigns test for the vulnerabilities cataloged by experts, generating specific test cases using fuzz vectors. Test results are more reliable as it much less reliant on the expertise and diligence of an individual tester. Instead, the quality of test results is assured by the Web security knowledgebase. Preliminary results indicate that this modeldriven, grey-box test approach integrated into a secure software development lifecycle should be more cost-efficient, and conduct tests in a more consistent and systematic way. The paper is presented as follows: section II provides background knowledge of our research, section III describes the proposed model-driven penetration test framework, section IV presents the case study we have conducted using the proposed framework, section V presents the evaluation results, /10/$ IEEE 173

2 section VI summarizes the contributions of our research and proposes the future work. II. BACKGROUND A vulnerability is a software or hardware bug or misconfiguration that a malicious individual can exploit [1]. Vulnerability assessment is the activities that identify security liabilities within a system (network, system software, and applications), and verify that no known security vulnerability is present on the target system [1] [2]. Penetration testing, also known as ethical hacking, is a process that goes one step further to substantiate the vulnerabilities reported during vulnerability assessment by attempting to recreate the trickery and creativity that a real attacker would use [1] [2]. Attacks against Web application typically fall into two high-level categories: resource enumeration e.g. blind resource enumeration and knowledge-based resource enumeration, and parameter manipulation e.g. SQL injection and Cross-Site Scripting (XSS). A third category includes the attacks that cannot be classified into the two categories above such as Cross-Site Request Forgeries (CSRF), phishing scams, and Denial of Service (DoS) attacks [3]. There are a few Web application vulnerability databases available on the Internet, e.g. OWASP TOP 10 Web application vulnerabilities [4], SANS Top Security Risks [5], WASC Threat Classification [6]. These databases classify and identify all known Web application vulnerabilities and attacks, and they are kept updated and maintained. These public security knowledgebase are very useful to penetration testers for selfeducation and used as test references. Penetration test is widely used in industry to ensure Web application security. In addition, vulnerability scanner, static analyzer, and code review are the other primary security test methods for Web applications [4] [7]. While penetration testing primarily takes a black-box test approach, grey-box approach is also mentioned in [7]. Grey-box is a test approach that is a combination of black-box and white-box. An application is still tested as a black-box but supplemented with the application s internal information [8] [9]. There are several references [7] [10] [11] to how penetration testing is typically conducted in industry. We will refer generically to this approach as an expert security assessment. In a typical expert security assessment process, a security expert first needs to gather the relevant application information and identify all the entry points by using various tools, e.g. spider, network scanner, HTTP proxy etc. The gathered application information may be inaccurate and the list of entry points can be incomplete, due to technical difficulty and human errors in this process. Based on the application information and the identified entry points, the tester develops test cases using his knowledge of Web application security. The tester is supposed to have comprehensive Web application security knowledge and correctly apply it for each entry point to determine: Any potential vulnerability an entry point may have, and accordingly which attack vectors are feasible. For each attack vector, which fuzz vectors can be loaded. What is the check point at the client-side that can be used to determine if the attack succeeds or not. Then the tester executes the test cases and observes the check point to determine if the potential vulnerability can be confirmed. The coverage of the test cases and the quality of the tests are constrained by the tester s knowledge, skills and experience on Web application security [12]. In addition, real hackers may have more resources than general penetration testers [13]. Usually they are not constrained to a specific schedule. Furthermore, while a hacker probably only needs to detect and exploit one vulnerability in a Web application in order to completely compromise the application, testers are expected to protect against all potential vulnerabilities in an application with an aggressive test campaign schedule. Some academic research on software security and penetration testing has proposed improvements on test methodology to guide a security test campaign conducted in a more systematic and efficient approach. In [12] and [14], the authors advocate integrating application penetration testing into a complete secure software development life cycle. In [15], the author presents a complete penetration testing process for applications integrated into a security-oriented software development life cycle starting with threat modeling. In addition to vulnerability and penetration test, there are a few terms that are frequently used in the context of Web application penetration testing. Unfortunately, we did not find precise and formal definitions for them during our literature research. We give informal descriptions below for them so that the content of this paper can be more clearly understood. Entry Point: an HTTP request that can be in the form of simple URL or a complete HTTP GET/POST message Check Point: an object and its value that can be used to determine if an attack succeeds or not, e.g. an HTTP response message or an entry in a log file at the serverside Attack Vector: a scenario of interaction in which a hacker can launch attack through an entry point against an application Attack Surface: consists of attack vectors Fuzz Vector: specific values that can be used to parameterize or replace part of an entry point as a malicious payload in an attack Application Footprint (Signature): system information of an application that might be relevant to a vulnerability. Elements of an application footprint include platform, e.g..net or J2EE or PHP, on which an application is developed, backend database, etc. III. MODEL-DRIVEN PENETRATION TEST FRAMEWORK A. Evaluation Criteria A careful review of the relevant literature plus our experiences working with developers in prototyping our 174

3 framework has led us to identify the following sets of criteria as most critical to address the issues existing in current penetration test practices. Better Application Development a) Integration with Software Development Life Cycle: enable penetration testing early in development to help identify issues and guide design b) Collaboration with Developers: facilitate structured and systematic communication between developers and testers c) Integration with Other Security Test Methods: support other security test methods (like code review) d) Test Method: support grey-box test architecture e) Test Results: consistently produce repeatable test results that are reliable and assessable. Ease of Use a) Test Automation: where possible the major processes of a penetration test campaign should be automated. b) Regression Testing: support consistent repeatable followup and continuous monitoring Complexity a) Web Application Security Knowledge: declaratively represent in a well-structured data model that can be understood and processed by computer programs. b) Test Effort: with the support of the security knowledgebase, a penetration tester does not have to be expert in Web application security knowledge and skills but is still able to produce quality test results. Applicability a) Unified and Flexible Test Process: provide a unified but still flexible test process that can be adopted for various Web application developments. b) Generic Test Platform: provide a generic test platform that can be used for various types of applications and vulnerabilities. B. Model-Driven Penetration Test Framework To address the criteria listed above we propose a Model- Driven Penetration Test Framework consisting of Grey-box Test Architecture Penetration Testing Process Integrated with Secure Software Development Life Cycle Web Application Penetration Test Security Model Test Campaign Process Automation 1) Grey-box Test Architecture A hacker, generally, does not have any knowledge about the Web application and must take a block-box approach. A penetration tester, on the other hand, can take advantage of the knowledge of the application that he can acquire from the development team and take a grey-box approach. In particular, the tester can obtain detailed knowledge of every application entry-point from which requests can be triggered as well as the intended functionality of the request. The tester can also determine checkpoints and expected results where one can conclusively verify whether a security vulnerability exists based on the system response or state at that point. Figure 1 shows the architecture of a typical Web application with browser-based interface (including AJAX). A user interacts with a Web App via Browser. Internally, an HTTP request is by Browser directly, or through Client App scripts in the format of JSON or SOAP messages. The most interesting components to a penetration tester are those in the Web Application Domain, including Client App scripts, the client-side DOM (Document Object Model) that represents the interface presented to the user, and the Web App on the server side that generates HTTP responses to HTTP requests. Fig. 1. Ajax Web Application Architecture 175

4 4 The different types of entry points where a penetration tester or hacker can launch attacks are shown as spots with right arrow in Figure 1. Table I shows the comparison of different types of entry points. In general, HTTP request is the best choice of entry point for testing as it provides the most flexibility for manipulation. TABLE I COMPARISON OF ENTRY POINTS Entry Point Advantages Disadvantages User Input Intuitive, easy to collect and use Limited types of attack surface: only URL and input fields. Difficult to manipulate hidden fields. Attacks are constrained by GUI controls and client-side validation. DOM Events HTTP Request Compared to User Input, it has more flexibility of manipulating attacks Provides the most flexibility of manipulating attacks: a) all types of attack surface. b) arbitrary encoding schema Only applied to DOM events. Unable to manipulate protocols. Unable to apply arbitrary encoding schema. Not intuitive to a general penetration tester The spots with left-up arrow shown in Figure 1 indicates where a tester can check for validation at either the server-side or client-site that a security vulnerability has or has not been handled properly. This flexibility helps the tester to determine more precisely if an attack succeeds or not. Table II shows the comparison of different types of check points. There is no generally best choice of check points. Choosing an appropriate check point is determined by the natures of attacks and characteristics of the application under test. TABLE II COMPARISON OF CHECK POINTS Check Point Advantages Disadvantages Serve-Side Server states Database Log Client-Side HTTP Response DOM Browser Display Can observe dynamic behavior of attacks Can reliably check the permanent data changes caused by attacks Can focus on abnormal events and exceptions that are usually logged. Easy to intercept and analyze response messages. No third-part utilities needed. Detect attacks that exploit client-site scripting Most reliable for the attacks that occur at the client-side. May need significant effort to build a utility to monitor the states in Server memory May need to build a customized utility May need to build a customized utility a) For some types of attacks checking HTTP responses may lead to false-positive and false-negative. b) Cannot detect attacks that do not involve HTTP communications, e.g. DOMbased XSS. Need a DOM engine to verify check points. Need a Browser simulator to test for all brands and versions of browsers. 2) Penetration Testing Process Integrated with Secure Software Development Life Cycle Figure 2 shows how the penetration testing process supported by our frameworks fits into an overall Secure Software Development Life Cycle. A web application security expert maintains and updates reference databases that declaratively represent Web Application Security Knowledge in terms of known vulnerabilities, attack vectors, and fuzz vectors. This is done independently of any development or test activities for a specific web application. The Web application security knowledgebase can either be a proprietary resource or a standardized open resource, and should continuously be updated and maintained. On the other hand, the penetration testers and web application developers are interacting systematically throughout the development lifecycle. A penetration test campaign starts as early as the application development starts, and it proceeds in parallel to the application development. A penetration tester utilizes the Web application security knowledgebase and the application analysis and design documents for test case development. From these the penetration tester can identify or mockup representative entry points that they anticipate for the web application in order to do a preliminary assessment, identity attack surface and initiate test case development. During the test case development, the tester may generate a list of potential vulnerabilities, and review them with developers. Developers can share with the tester information related to how they plan to handle the vulnerabilities in terms of check points and expected results. The tester will use that information to update attack surface and generate test cases. Test execution can be an iterative process, in that defects get fixed and probably new features get implemented then the tests get rerun. The end of the test execution means that all test cases and expected results are well understood and a comprehensive regression test is defined. If the regression test passes, the Web application is ready for release. As new features are added or other changes made, the regression test can be rerun to ensure vulnerability protection has not been compromised. 3) A Web Application Penetration Test Security Model We define a web application penetration test security model that can be understood, supported and processed by our test platform. The intent is to automate processing steps wherever possible, so that they are repeatable and consistent by using declarative representation of penetration test artifacts. Figure 3 shows the main entities in our model, and highlights the most important attributes. Application Footprint, Entry Point and Checkpoint are used to define the specifics of the web application which are relevant to penetration testing. Entry Point identifies all the interface points where requests can be formulated and sent to the Web Application, thus serving as potential doors to Web application attacks. Checkpoints define where expected results can be used to verify that appropriate protection has been provided in the web application. Application footprint which consists of running environment elements such as platform, backend database, OS and encoding schema, is used to filter out those attack vectors and fuzz vectors that are not applicable in the specific running environment of a Web application under test. 176

5 5 Fig. 2. Penetration Test as an Integrated Process In the Web application security domain, three objects, Vulnerability, Attack Vector, and Fuzz Vector, are fundamental to test case development. Fig. 3. Web Application Penetration Test Security Model A vulnerability is unveiled and exploited by launching a set of attack vectors which in turn are loaded with a bunch of fuzz vectors. Most of attacks are achieved by url manipulation to misuse the original functionality of the url request. Therefore, the functionality of an entry point is a key indicator to identify potential vulnerabilities that may exist in an entry point. The security expert will create, maintain and update a web application security knowledge base that catalogs all known vulnerabilities and indexes them both by functionality and by application footprint. Attack vectors and fuzz vectors will also be catalogued and linked to vulnerabilities to indicate how a penetration test should orchestrate an interaction with a Web application and parameterize the formulation of requests at entry points in order to exploit a vulnerability. 4) Test Campaign Process Automation Since the penetration test campaigns are conducted upon a well-structured model, automation of major steps in the test process becomes possible. Figure 4 shows the architecture of a basic test platform that supports automation. 177

6 6 The core components in this test platform include: Entry point Enumerator: generates entry points for a Web application by either using a WebAPI design document as input or processing the output of a tool such as Web crawler. Vulnerability Identifier: based on the collected entry points and Web security knowledgebase, identifies potential vulnerabilities for each entry point. Test Case Generator: generates executable test cases based on the attack surface, fuzz vectors and user scenarios. Test Loader: loads the executable test cases and sends them to the Test Runner. Test Runner: executes test cases and verifies verdicts Reporter: generates and prints final test results In addition, the Web security engine and Web security knowledgebase can be an internal resource or third-part open resource. A comprehensive security knowledgebase is an essential to a successful test campaign. IV. CASE STUDY A case study to evaluate the proposed penetration test framework was conducted by applying the framework to running two mini test campaigns against two different web applications. The first test campaign was used to test WebGoat, a deliberately insecure J2EE Web application that can be used as a benchmark to test security tools [16]. This Fig. 4. Test Platform Architecture test is an after the fact security test and is primarily to validate the effectiveness of the proposed framework all known vulnerabilities can be identified in the test campaign. The second test campaign is to test against AEMS, a.net Web application under development that is to manage the adverse events in a hospital [17]. An early prototype of AEMS has been implemented and deployed at a beta test site. This test followed the proposed integrated development life cycle and is being used to validate the proposed framework in a real project. A sample Web Application Security Knowledgebase was constructed and populated with 5 known vulnerabilities, 9 related 9 attack vectors and 9 fuzz vectors. The five vulnerabilities are Reflected XSS, Stored XSS, Numeric SQL Injection, String SQL Injection, and Cross-Site Request Forgery, which are the most popular vulnerabilities in today s Web applications [4]. The Web Application Penetration Test Security Model from Figure 3 was created and implemented in database used to store, maintain and update test campaigns. A Test platform prototype was built based on open source technologies including Java, Apache HttpClient, MySQL, and Eclipse. It was used in the two test campaigns to develop and execute test cases. The WebGoat test campaign was built using an initial set of 18 entry points that were defined based on an analysis of a subset features of WebGoat in which we are most interested 178

7 7 with respect to the vulnerabilities in our sample Web Application Security Knowledgebase. The entry points were collected by using an open source HTTP proxy WebScarab [18], and the functionality for each entry point was identified. The test platform then generated automatically a list of potential vulnerabilities and the corresponding attack surface. The check points and the expected results were manually identified for the attack surface. Based on that, the test platform generated a set of test cases which have the full coverage to the attack surface. Finally, the test platform loaded the test cases and ran against the live WebGoat application and produced a simple test report. In the WebGoat test campaign, 3 types of vulnerabilities were identified in 5 of the 18 entry points by first identifying potential vulnerabilities against the Web Application Security Knowledge Base based on functionality of entry points, and then by leveraging attack vectors and fuzz vectors to generate test cases. 19 test cases were generated and executed. The test result analysis confirms that all vulnerabilities under study in WebGoat have been identified successfully. The AEMS test campaign was performed while the system was under development. The test campaign was conducted in a similar process as the one in the WebGoat test campaign described above, expect that the developers provided development artifacts and were available as resources while the test campaign was developed. 7 entry points were tested in the test campaign and in total 10 test cases were generated and executed. 1 stored XSS vulnerability was identified in 1 entry point. 1 false-negative was identified in the review of test results with a developer. As it turned out, the false negative was due to a functional defect in the software (insufficient messaging to interpret the results conclusively). The defect was fixed in AEMS, and then the test case was re-run and passed. TABLE III CASE STUDY TEST RESULT SUMMARY Web Security Repository # Vulnerability 5 # Attack Vector 9 # Fuzz Vector 9 WebGoat AEMS # Entry Point 18 7 # Test Cases # Identified Vulnerability 3 1 # Vulnerable Entry Point 5 1 The case study demonstrated that the proposed penetration test framework enabled a tester who was not a security expert to run a penetration test campaign for Web applications effectively and efficiently. It also demonstrated the ability of our framework to integrate penetration testing with development. This ensured more comprehensive and systematic testing, as well as guiding developers in a consistent approach to protecting against vulnerabilities. Penetration testing was flexibly combined with code reviews and other types of standard testing. V. EVALUATION We compare our proposed Model-Driven Test Framework, using the criteria we identified in section III A, against the type of common Expert Security Assessment, which is typical of current practice. Table IV, V and VI summarize the comparisons. Expert Security Assessment refers to the current industry practice of bringing in experts to perform a security audit and perform penetration testing in a manner largely independent of the software development lifecycle as was mention in section II Background. In many cases, this assessment is performed after the application is released into production. TABLE IV EVALUATION: BETTER APPLICATION DEVELOPMENT Criteria Expert Security Assessment Model-Driven Test Framework Integration with Software Development Life Cycle Collaboration with Developers Integration with Other Security Test Methods Test Method Test Results a post-deployment security assessment against live systems an isolated and independent practice that does not require or even intends to avoid any collaboration with developers an isolated process that does not have a systematic approach to integrating with other security test methods black-box approach is the only viable choice test results rely on the expertise of an individual tester and his diligence, therefore the results may vary when the tests are performed by different security experts, or in different rounds of tests that is performed by same expert an integrated process in Security-Oriented Software Development Life Cycle facilitate collaboration between developers and testers with both a welldefined process and tools support support the integration with other security test methods via the collaboration with developers adopt grey-box approach to take advantages of development artifacts and expand test capacity with the support of the systematic test process and the test platform, test results can be consistently reproduced, and the test results are considered reliable and assessable TABLE V EVALUATION: EASE OF USE Criteria Expert Security Assessment Model-Driven Test Framework Test Automation Regression Testing Criteria Web Application Security Knowledge Test Effort various tools may be used at different steps but they are not integrated into one platform, the overall test process proceeds manually usually it is a one-time task so there is no consideration to regression testing the major processes of test campaigns are automated it is considered as one of critical tasks in the integrated test process and it is automated TABLE VI EVALUATION: COMPLEXITY Expert Security Model-Driven Test Assessment Framework text-based Web application is represented in a wellstructured security knowledge data model that interspersed on the Internet can be understood and processed by the test platform security experts have to keep themselves updated with all the text-based Web application security knowledge, understand them, and apply them correctly with the support of the security knowledgebase and the test platform, a penetration tester is relieved from considering all the vulnerabilities, attack vectors, and fuzz vectors in test case development 179

8 8 The proposed model-driven penetration test framework also meets the specific requirements of the two Web applications we tested. The framework enabled a unified and flexible test process. The two test campaigns are quite different. WebGoat is a deliberately insecure Web application for education and benchmark purposes; while AEMS is a real Web application under development. The framework provided a systematic guide to run the test campaigns and both the test campaigns were completed successfully. The framework provided a generic test platform. The two applications tested had very different application footprints. WebGoat is a J2EE application that can be accessed via HTTP, while AEMS is a.net application that has to be accessed over HTTPs. This is a preliminary demonstration that a generic test platform can be built up to support penetration testing for all kinds of Web applications and for various types of vulnerabilities. Overall, the evaluations above demonstrated some early indications that the proposed penetration test framework meets the pre-defined criteria, and has advantages over the current expert security assessment practices in terms of cost-efficiency and test quality. VI. CONCLUSIONS The research presented in this paper mad the following contributions: 1) Proposed a systematic, cost-efficient Web application penetration testing methodology which is integrated into a Security-Oriented Software Development Life Cycle. The proposed methodology advocates the collaboration with developers and the integration of penetration test with other supplementary security test methods to achieve quality penetration test campaigns. 2) Defined a grey-box, model-driven test architecture that expands penetration test capacity and enables the automation of the major processes in penetration test campaigns to support the proposed methodology above. 3) Defined a structured representation of Web security knowledge that can be understood and processed by test platform programs so that the quality of test campaigns is assured, and test results are more reliable, measurable, and assessable. We are not the first to advocate the integration of a systematic penetration testing process into a security-oriented software development lifecycle. Much of what we incorporate in our methodology has been advocated in [12] [14] [15]. The essential aspect of our approach is the penetration testing security model which is used to represent the relevant security knowledge, and define the key artifacts that are created by the testing process such that the tools can be created to automate the process, and the knowledge can be reused. In the future, we will continue our research: 1) Consider integrating threat modeling and analysis technology into the test framework, and using it to guide test case development and prioritize identified vulnerabilities. 2) Expand the Web security knowledge with more vulnerabilities, attack vectors and fuzz vectors, and conduct case study based on the expanded knowledgebase to further evaluate the test framework. REFERENCES [1] Manzuik, S., Gold, A., & Gatford, C. (2007). Network Security Assessment: From Vulnerability to Patch. Syngress Publishing. [2] Splaine, S. (2002). Testing Web Security: Assessing the Security of Web Sites and Applications. John Wiley & Sons. [3] Hoffman, B., & Sullivan, B. (2008). Ajax Security. Addison Wesley. [4] OWASP TOP 10. (2007). OWASP TOP 10: The Ten Most Critical Web Application Security Vulnerabilities. Retrieved August 2009, from The Open Web Application Security Project: [5] SANS TOP 20. (n.d.). TOP 20 Internet Security Problems, Threats and Risks. Retrieved September 2009, from The SANS (SysAdmin, Audit, Network, Security) Institute: [6] WASC. (2010, January 1). The WASC Threat Classification v2.0. Retrieved January 2010, from Web Application Security Consortium: [7] OWASP Testing Guide. (2008, December). OWASP Testing Guide. Retrieved August 2009, from The Open Web Application Security Project: [8] Binder, R. V. (1999). Testing Object-Oriented Systems: Models, Patterns, and Tools. Addison-Wesley Professional. [9] Patton, R. (2000). Software Testing. Sams. [10] Andreu, A. (2006). Professional Pen Testing for Web Applications. Wrox Press. [11] Palmer, S. (2007). Web Application Vulnerabilities: Detect, Exploit, Prevent. Syngress Publishing. [12] Arkin, B., Stender, S., & McGraw, G. (2005, Janunary-February). Software Penetration Testing. IEEE Security & Privacy, Volume 3 (Issue 1), pp [13] Bishop, M. (2007, November-December). About Penetration Testing. IEEE Security & Privacy, Volume 5 (Issue 6), pp [14] Potter, B., & McGraw, G. (2004, September-October). Software Security Testing. IEEE Security & Privacy, Volume 2 (Issue 5), pp [15] Thompson, H. (2005, January-February). Application Penetration Testing. IEEE Security & Privacy, Volume 3 (Issue 1), pp [16] OWASP WebGoat. (n.d.). OWASP WebGoat Project. Retrieved September 2009, from The Open Web Application Security Project: [17] Behnam, S. A., Amyot, D., Forster, A. J., Peyton, L., & Shamsaei, A. (May, 2009). Goal-Driven Development of a Patient Surveillance Application for Improving Patient Safety. 4th International MCeTech Conference on etechnologies. LNBIP Volume 26, pp. pp Ottawa, Canada: Springer. [18] OWASP WebScarab. (n.d.). OWASP WebScarab Project. Retrieved September 2009, from The Open Web Application Security Project: t 180