An Automated Vulnerability Scanner for Injection Attack Based on Injection Point

An Automated Vulnerability Scanner for Injection Attack Based on Injection Point Jan-Min Chen The Dept. of Information Management Yu Da University Miaoli, Taiwan E-Mail: ydjames@ydu.edu.tw Chia-Lun Wu The Dept. of Computer Sci. & Eng. Tatung University Taipei, Taiwan E-Mail: strmage115@gmail.com Abstract As the popularity of the web increases and web applications become tools of everyday use, the role of web security has been gaining importance as well. The last years have shown a significant increase in the number of web-based attacks. Too many nouns web application security vulnerabilities result from generic input validation problems. Examples of such vulnerabilities are and Cross- Site Scripting (XSS). Although the majority of web vulnerabilities are easy to understand and to avoid, many web developers are, unfortunately, not security-aware. As a result, there exist many web sites on the Internet that are vulnerable. This paper implemented an automated vulnerability scanner that for the attacks. To this end, we implemented a system that automated scanned the attack vulnerabilities. Our system was automatically analyses web sites with the aim of finding exploitable and XSS vulnerabilities. It was able to find many potentially vulnerable web sites. We picked 7 identified web sites with vulnerabilities from National Vulnerability Database [13] to verify our system. Keywords: -Injection, XSS; Complete Crawling; Security Scanner; Web Application Testing; Black-Box Testing I. INTRODUCTION Web applications are complex entities. Technically speaking, an application is the a program designed to perform a specific function directly for the user or for another application program. Web applications include code that resides on the Web servers, application servers, databases, and back end systems of an organization. In short, they are any application that will be accessed in some way, shape, or form through the Web. [1] Web application security can be enhanced through the increased enforcement of secure development practices. For instance, Scott and Sharp [2] have proposed a high-level input validation mechanism that blocks malicious input to Web applications. Such an approach offers protection through the enforcement of strictly defined policies, but fails to assess the code itself or to identify the actual weaknesses. In this paper, we developed a system that automated scanned the attack vulnerabilities. [4] This paper is structured as follows: Section 2 provides a brief introduction to attacks, black-box testing and crawling. Section 3 describes our approach for automated vulnerability detection. Section 4 presents the evaluation results with discusses. Section 5 discusses future work and concludes the paper. II. RELATIVE RESEARCHES A. Injection attacks The vulnerabilities occur whenever an application takes the user supplied data without first validating or encoding that content. The weakness induced by a programmer having no security sense may allow attackers to execute the script in the victim s browser which can hijack user sessions or to inject data as part of a command for tricking the interpreter into executing unintended commands. The hostile code, data or file may be included or executed if the filenames or files from the user can be accepted without properly validating. In addition, attackers can use this weakness to steal sensitive data or conduct more serious attacks. [10] 1) [11] Through a query, a program can add, modify, or retrieve data in a database. enables attackers to access, modify, or delete critical information in a database without proper authorization. Via, attackers can also execute arbitrary commands with high system privilege in the worst case. has recently been one of the top issues in software security. In many cases, queries are dynamically constructed via user input. A attack occurs when an input from a user includes keywords so that the dynamicallygenerated query changes the intended function of the query in the application. 2) Cross-Site Scripting(XSS) XSS allows attackers to execute script in the victim s browser with reflected, stored and DOM bases. Reflected XSS can be used if a page will reflect user supplied data directly back to user. Stored XSS takes hostile data, stores it in a file, a database, or other back end system, and then at a later stage, displays the data to the user, unfiltered. Besides the above classic XSS where the payload moves to the server and back, there is another form of user agent attacks, which does not depend on the payload to be embedded in the response, but rather on the payload in the Document Object Model (DOM). [10] B. Black-box testing [4] Many web application security vulnerabilities result from generic input validation problems. Examples of such vulnerabilities are and Cross-Site Scripting 113

(XSS). Although the majority of web vulnerabilities are easy to understand and to avoid, many web developers are, unfortunately, not security-aware. As a result, there exist a large number of vulnerable applications and web sites on the web. There are two main approaches to testing software applications for the presence of bugs and vulnerabilities: In white-box testing, the source code of the application is analyzed in an attempt to track down defective or vulnerable lines of code. This operation is often integrated into the development process by creating add-on tools for common development environments. In black-box testing, the source code is not examined directly. Instead, special input test cases are generated and sent to the application. Then, the results returned by the application are analyzed for unexpected behavior that indicates errors or vulnerabilities. So far, white-box testing has not experienced widespread use for finding security flaws in web applications. An important reason is the limited detection capability of whitebox analysis tools, in particular due to heterogeneous programming environments and the complexity of applications that incorporate database, business logic, and user interface components. In practice, black-box vulnerability scanners are used to discover security problems in web applications. These tools operate by launching attacks against an application and observing its response to these attacks. C. Crawling [7] Raghavan proposed a model of a hidden Web crawler consists of the four components described below. 1) Internal Form Representation. On receiving a form page, the internal representation of a form F includes the following pieces of information: F=({E 1,E 2,...,E n },S,M}), where {E 1,E 2,,E n } (1) F is the form, S is the submission information associated with the form (e.g., submission URL, internal identifiers for each form element, etc.), and M is meta-information about the form (e.g., URL of the formpage, web-site hosting the form, etc.). For example, Fig. 1 shows a form with three elements. 2) Matching function A crawler s matching algorithm, Match, takes as input, an internal form representation, and the current contents of the database D. It produces as output, a set of value assignments. Formally: Match(({E 1,..., E n }, S, M), D)={[E 1 v 1,..., E n v n ]} (2) A value assignment {[E 1 v 1,..., E n v n ]} associates value vi with form element E i. Figure 1. Crawler form interaction 3) Response Analysis The response to a form submission is received by a response analysis module that stores the page in the crawler s repository. III. DETECTING VULNERABILITY BASED ON INJECTION POINT A. System overview Our system is difference with other systems that we detect the vulnerabilities based on point, we consider, a web application is the a polymer for multiple point. We get the information of each points that to find where the vulnerability is. The system consists of two main components and is shown in Fig. 2: Spider: To crawling the web site and find points. This component consists of two components, Crawler and Injection point analyzer o Crawler: Setup the number of layers, then gets the entire page of web site and saving o as a list. Injection point analyzer: Download the pages from url list, then analysis the forms in each page that to find points. Finally, save the list of point to the database. Scanner: It starts the Injection test and response analysis. This component consists of two components, Response analyzer and Rule writer. o o Response analyzer: Load the point list and rule list from the database, then starts and receives the response from the server. After has done, analysis the response with rule, and save the result to the database. Rule writer: Crate a rule list by manual, input expected keyword for the response, that Rule writer would generate a rule list. B. Generate point list Let us discuss the subject from attacks point to view, a web application just as a Community of Numerous point, our purpose is found the which has 114

the vulnerability. We explain the relationship as: point form page web application. Firstly, we were crawling all of link U in web site W: W = {U 1, U 2,..., U n } (3) Secondly, following the (1), we parse the form F in each U. The element E in form F is the equivalent of point p, so we can follow the (2), and regard the list of p as P, that we get the following formula: P = ({p 1 v 1,, p n v n }, S,M ) (4) Our system saves the P into the database, as the scheme [Parent url, form url, element name, method, target]. Fig. 3 shows our algorithm for Injection point analysis. Some website processed with session control; In this case, presume the account and password were known, we use automated form feed to login, the algorithm showed as Fig. 4. C. Generated the vulnerability point list After get P, we continued to execute the test. In test, we discovered some web site process with multiple post value. In Fig. 5, if only the $_POST ['login'] is not null that the login statement could be processing. So we execute the test with single and multiple, as the Fig. 6 indicates. We use Nikto [16] and N-Stealth [18] to scan web site, and record their query string to use for our test. It seems reasonable to suppose that use the test pattern of the top scanner in the real world. The results are presented in Figure 3. A algorithm for Injection point analysis Figure 4. A algorithm for automated form feed Figure 5. A smaple of Web application code Figure 6. Single/Multiple Model Figure 2. System architecture 115

Table I & Table II, there are 143 data for -, 1060 data for XSS, 10 data for normal query and 2988 data for other attacks. If we used the pattern which shows in Table II to a web site, then the server would receive a response back, the response was difference to each web site. We use the pattern which shows in Table I & Table II for query string set Q={T 1,, T n }, follow (2), used T i as query string to to p, and we could receive the response R i. Here is a formula which presents test s flow: R = ({r 1 = p 1 Q,, r n = p n Q}, W) (5) After the test, we get the set of response R = {ri,..., r n }, before response analysis, we found an expected keyword to design analysis rule by manual, that show as follows: We compare e i with r i, if matched, we may say that p i has the vulnerability and saves it to vulnerability list P v : P v p i, if Match(r i, e i ), for I = 1 n (6) Fig. 7 shows our algorithm for Injection Test and Web- App Response analysis. Pattern # TABLE I. THE TESTING DATASET Pattern type # Queries attack 143 XSS attack 1060 Other attack 2988 Normal 10 Total 4201 TABLE II. THE SAMPLE OF DATASET Pattern Pattern type 1 OR username IS NOT NULL OR username = ' attack 2 ; and 1=1 and 1=2 attack 3 name=<script>alert('vulnerable')</script> XSS attack 4 name=<script>alert(document.cookie)</script> XSS attack 5 editor_insert_bottom=http://attack/nstalker Other attack 6 James@ttu.edu.tw Normal TABLE III. SAMPLE FOR THE RULE LIST OF INJECTION TESTING Rule # Site # Pattern # Threat type Expected response 1 1 1 Log In 2 1 2 Log In 3 1 3 Log In. 12 4 3 XSS error Figure 7. A algorithm for Injection Test and Web-App Response analysis IV. SYSTEM IMPLEMENTATION AND EVALUATION A. System Environment Our system was implementation in VMware work station ACE edition 6.0.0, we set two hosts to build our system, one for defense server, and another one for website server. Our system develops on PHP5+My, use curl [12] module to execute attacks. Test Cases We have chosen seven web application from National Vulnerability Database [13], NVD is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. NVD includes databases of security checklists, security related software flaws, misconfigurations, product names, and impact metrics. B. Tests explained To evaluate the reliability of our system, we designed a simple web application: Experimental Web site, it has message board and member authentication functionally and back-end system; Experimental Web site could dynamicallygenerated its page and point, and used session control to authentication member s login; To evaluate the test pattern which shows in Table I, Experimental Web site has many - and XSS vulnerabilities, as Table VI presented; We count the pages and points all of Experimental Web site is 13 pages and 47 points, and 36 point have the vulnerability, after counting, we compare the results between manual and automated testing, presented in Table VII. Table VIII summarizes the experimental result of the experimental Web site; the result included form s url, parent url, parameter name, transfer target, method and threat type. Those test cases of above, their page and point will be dynamically-generated with user s operation, but our WVS could complete crawling. The results are presented in Table V. We compared Table VI and Table VIII to extend the observation into Table IX; the False positive means that it 116

isn't vulnerable, but to detect; the False negative means that it s vulnerable, but not to detect. C. System Evaluation As mentioned above, we had chosen seven web sites that from NVD to execute test, after crawling, find point, test and response analysis, our system successfully detected vulnerabilities that match with NVD. The final results presented in and Table X. D. Compares Finally, we compared the effectiveness between our WVS with some WVSs, the results are presented in Table XI. These results prove clearly that our system is effectiveness, we can say with fair certainty that detecting vulnerability based on point could exactly find vulnerabilities. Table IV. The real exploits used in effectiveness evaluation Threat type: - CVE # Program Version 2010-0122 timeclock-software 0.99 2009-4669 RoomPHPlanning 1.6 2008-2488 RoomPHPlanning 1.5 2009-4595 PHP Inventory 1.2 2009-4456 Green Desktiny 2.3.1 2009-3716 MCshoutbox 1.1 Threat type: XSS 2010-1742 Scratcher N/A Table V. The detail description about the testing result of some CVE_exploits pages Injection Vulnerabil Vulnerable Program # points # ity point # page Experimen 13 47 36 bbs.php program 2010- add_user.ph 72 324 5 0122 p 2009-748 2947 2 Login.php 4669 2008- userform.ph 748 2947 4 2488 p 2009-30 22 2 index.php 4595 2010- projects.ph 13 15 1 1742 p 2009- news_detail 9 10 1 4456.php 2009- admin_logi 7 8 2 3716 n.php Table VI. An vulnerable point list for experimental Web site Vulnerable URL Parameter Threat type point # Flaw type # /XSS XSS 1 login.php acc 2 login.php pwd 3 login.php login 4 bbs.php name XSS 5 bbs.php title XSS 6 bbs.php body XSS 7 bbs.php post none 8 res.php name XSS 9 res.php title XSS 10 res.php body XSS 11 res.php res none Table VII. The comparison between manual and automated testing result for experimental program Detection pages Injection Vulnerability Vulnerable Flaw type # type # points # point # page # bbs.php, Manual 13 47 36 res.php, /XSS login.php Automated 13 47 36 bbs.php, res.php, login.php /XSS Table VIII. The experimental result of the experimental Web site Injection Parent Para Method Target Threat URL point # URL meter type 1 bbs.php login.php acc POST login.php 2 bbs.php login.php pwd POST login.php 3 bbs.php login.php login POST login.php 4 bbs.php bbs.php name POST bbs.php XSS 5 bbs.php bbs.php title POST bbs.php XSS 6 bbs.php bbs.php body POST bbs.php XSS 7 bbs.php bbs.php post POST bbs.php none 8 res.php res.php?rid=1 name POST bbs.php XSS 9 res.php res.php?rid=1 title POST bbs.php XSS 10 res.php res.php?rid=1 body POST bbs.php XSS......... 44 res.php res.php?rid=10 name POST bbs.php XSS 45 res.php res.php?rid=10 title POST bbs.php XSS 46 res.php res.php?rid=10 body POST bbs.php XSS 47 res.php res.php?rid=10 res POST bbs.php XSS Table IX. An point list for experimental Web site Injection Threat False False URL Parameter point # type positive negative 1 login.php acc 0 0 2 login.php pwd 0 0 3 login.php login 0 0 4 bbs.php name XSS 0 0 5 bbs.php title XSS 0 0 6 bbs.php body XSS 0 0 7 bbs.php post none 0 0 8 res.php name XSS 0 0 9 res.php title XSS 0 0 10 res.php body XSS 0 0 11 res.php res none 0 0 Table X. Summary of system training and detection experiment CVE # program Threat # False # False Detecti type positive negative on experimental / Web site XSS timeclocksoftware 2010-0122 RoomPHPlanning 2009-4669 RoomPHPlanning 2008-2488 PHP Inventory 2009-4595 2010-1742 Scratcher XSS Green Desktiny 2009-4456 MCshoutbox 2009-3716 117

Table XI. Summary of the effectiveness evaluation for some WVSs (Web vulnerability scanners) WVS_1 WVS_2 WVS_3 WVS_4 Our WVS 2010-0122 N N N N Y 2009-4669 N Y Y N Y 2008-2488 Y N N N Y 2009-4595 Y Y Y Y Y 2010-1742 N N N Y Y 2009-4456 Y N N N Y 2009-3716 N N N Y Y V. CONCLUSION Our proposed mechanisms for scanning Web application security were detecting vulnerability based on point, exactly obtain the information of point, and using black box testing to analysis what potential vulnerability, tackled vulnerable point. As we according to detect based on point, so we can clearly know where the bug is, reduce the debug time and increase efficiency. We prove that our method can achieve it and present the effectiveness of increasing detection accuracy. Here our proposed mechanisms were a focus on and XSS attack. In the future, we will try to implement more threat types. Our response analysis model was too impoverished, so we are keeping completing more analysis rules. ACKNOWLEDGEMENT This work was supported by the National Science Council of Taiwan under grants NSC 99-2221-E-412-003. REFERENCES [1] Izhar Bar-Gad and Amit Klein and Sanctum Inc., Developing Secure Web Applications, 2002 [2] D. Scott, R. Sharp, Abstracting Application-Level Web Security. in Proc. of the 11th International Conference on the World Wide Web (Honolulu, Hawaii, May 2002), 396-407. [3] Yao-Wen Huang and Shih-Kun Huang and Tsung-Po Lin, Web Application Security Assessment by Fault Injection and Behavior Monitoring in WWW2003 (May 20-24, 2003, Budapest, Hungary) [4] Stefan Kals and Engin Kirda and Christopher Kruegel and Nenad Jovanovic, SecuBat: A Web Vulnerability Scanner in WWW 2006 (May 23 26, 2006, Edinburgh, Scotland) [5] Yao-Wen Huang and Fang Yu andchristian Hang and Chung-Hung Tsai and Der-Tsai Lee and Sy-Yen Kuo, Securing web application code by static analysis and runtime protection in 13th ACM International World Wide Web Conference, 2004. [6] Paolo Tonella and Filippo Ricca, A 2-Layer Model for the White- Box Testing of Web Applications in IEEE International Workshop on Web Site Evolution (WSE), 2004. [7] Sriram Raghavan and Hector Garcia-Molina, Crawling the HiddenWeb in the 27th VLDB Conference, Roma, Italy, 2001 [8] David Scott and Richard Sharp, Abstracting Application Level Web Security in the 11th International Conference on the World Wide Web (Honolulu, Hawaii, May 2002), 396-407. [9] Yao-Wen Huang and Fang Yu and Christian Hang and Chung-Hung Tsai and D. T. Lee and Sy-Yen Kuo, Verifying Web Applications Using Bounded Model Checking, IEEE Computer Society Washington, DC, USA, 2004 [10] Jin-Cherng Lin, Jan-Min Chen, Cheng-Hsiung Liu, An Automatic Mechanism for Sanitizing Malicious Injection, Young Computer Scientists, 2008. ICYCS 2008. [11] MeiJunjin, An approach for vulnerability detection, Information Technology: New Generations, 2009. ITNG '09. Sixth International Conference on 27-29 April 2009 [12] curl Library, http://www.php.net/manual/en/book.curl.php, visit on Jun 2010. [13] National Vulnerability Database, http://nvd.nist.gov/, visit on Jun 2010. [14] Top 10 Web Vulnerability Scanners, http://sectools.org/webscanners.html visit on Jun 2010. [15] OWASP, A Guide to Building Secure Web Applications: The Open Web Application Security Project, 2002 [16] Nikto of CIRT, http://www.cirt.net/nikto2, visit on Jun 2010. [17] Nessus of Tenable, http://www.nessus.org/nessus/, visit on Jun 2010. [18] N-Stealth Security Scanner, http://www.nstalker.com/, visit on Jun 2010. [19] Paros of Chinotec Technologies Company., http://www.parosproxy.org/, visit on Jun 2010. [20] AppScan of IBM Software, http://www- 01.ibm.com/software/awdtools/appscan/, visit on Jun 2008. [21] Acunetix of Acunetix Ltd, http://www.acunetix.com/, visit on Jun 2009. 118