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: [email protected]
Chia-Lun Wu
The Dept. of Computer Sci. & Eng. Tatung University
Taipei, Taiwan
E-Mail: [email protected] 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 SQL injection 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 injection attacks. To this end, we implemented a system that automated scanned the injection attack vulnerabilities. Our system was automatically analyses web sites with the aim of finding exploitable SQL injection 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: SQL-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 injection attack vulnerabilities. [4]
This paper is structured as follows: Section 2 provides a brief introduction to injection 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 injection 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) SQL injection [11]
Through a SQL query, a program can add, modify, or retrieve data in a database. SQL injection enables attackers to access, modify, or delete critical information in a database without proper authorization. Via SQL injection, attackers can also execute arbitrary commands with high system privilege in the worst case. SQL injection has recently been one of the top issues in software security.
In many cases, SQL queries are dynamically constructed via user input. A SQL injection attack occurs when an input from a user includes SQL keywords so that the dynamically-generated SQL query changes the intended function of the SQL 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 injection 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 injection 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 SQL injection 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 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 white-box 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=({E1,E2,...,En},S,M}), where {E1,E2,…,En} (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(({E1, ..., En}, S, M), D)={[E1 ← v1, ..., En ← vn]} (2)
A value assignment {[E1 ← v1, ..., En ← vn]} associates
value vi with form element Ei .
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 injection point, we consider, a web application is the “a polymer for multiple injection point”. We get the information of each injection 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 injection 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 as a list.
o Injection point analyzer: Download the pages from url list, then analysis the forms in each page that to find injection points. Finally, save the list of injection 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 Response analyzer: Load the injection point list and rule list from the database, then starts injection and receives the response from the server. After injection has done, analysis the response with rule, and save the result to the database.
o Rule writer: Crate a rule list by manual, input expected keyword for the response, that Rule writer would generate a rule list. B. Generate injection point list
Let us discuss the subject from injection attacks point to view, a web application just as a Community of Numerous injection point, our purpose is found the injection which has
the vulnerability. We explain the relationship as: injection point → form→page →web application.
Firstly, we were crawling all of link U in web site W: W = {U1, U2, ..., Un} (3)
Secondly, following the (1), we parse the form F in each U. The element E in form F is the equivalent of injection point p, so we can follow the (2), and regard the list of p as P, that we get the following formula:
P = ({p1 ← v1, … , pn ← vn}, 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 injection 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 injection test with single injection and multiple injection, 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 injection 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 2. System architecture
Figure 3. A algorithm for Injection point analysis
Figure 4. A algorithm for automated form feed
Figure 5. A smaple of Web application code
Table I & Table II, there are 143 data for SQL-injection, 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 injection 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={T1, …, Tn} , follow (2), used Ti as query
string to injection to p, and we could receive the response Ri.
Here is a formula which presents injection test’s flow: R = ({r1= p1← Q, …, rn= pn← Q}, W) (5)
After the injection test, we get the set of response R = {ri, ..., rn}, before response analysis, we found an expected
keyword to design analysis rule by manual, that show as follows:
We compare ei with ri , if matched, we may say that pi
has the vulnerability and saves it to vulnerability list Pv:
Pv ← pi , if Match(ri, ei), for I = 1 → n (6)
Fig. 7 shows our algorithm for Injection Test and Web-App Response analysis.
TABLE I. THE TESTING DATASET
Pattern type # Queries
SQL attack 143
XSS attack 1060
Other attack 2988
Normal 10
Total 4201
TABLE II. THE SAMPLE OF DATASET
Pattern
# Pattern
Pattern type
1 OR username IS NOT NULL OR username = ' SQL attack
2 ; and 1=1 and 1=2 SQL 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 [email protected] Normal
TABLE III. SAMPLE FOR THE RULE LIST OF INJECTION TESTING
Rule # Site # Pattern # Threat type Expected response
1 1 1 SQL injection Log In
2 1 2 SQL injection Log In
3 1 3 SQL injection 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+MySQL, use cURL [12] module to execute injection 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 dynamically-generated its page and injection 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 SQL-injection and XSS vulnerabilities, as Table VI presented; We count the pages and injection 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 injection 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
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 injection point, injection 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 injection point could exactly find vulnerabilities.
Table IV. The real exploits used in effectiveness evaluation
Threat type: SQL-injection
CVE # Program Version CVE-2010-0122 timeclock-software 0.99
CVE-2009-4669 RoomPHPlanning 1.6 CVE-2008-2488 RoomPHPlanning 1.5 CVE-2009-4595 PHP Inventory 1.2 CVE-2009-4456 Green Desktiny 2.3.1
CVE-2009-3716 MCshoutbox 1.1
Threat type: XSS
CVE-2010-1742 Scratcher N/A
Table VI. An vulnerable injection point list for experimental Web site
Vulnerable
injection point # URL Parameter Threat type
1 login.php acc SQL injection 2 login.php pwd SQL injection 3 login.php login SQL injection
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 type pages # Injection points # Vulnerability point # Vulnerable
page # Flaw type #
Manual 13 47 36 bbs.php, res.php, login.php SQL injection/XSS Automated 13 47 36 bbs.php, res.php, login.php SQL injection/XSS
Table VIII. The experimental result of the experimental Web site
Injection point # Parent URL URL Para meter
Method Target Threat type 1 bbs.php login.php acc POST login.php SQL 2 bbs.php login.php pwd POST login.php SQL 3 bbs.php login.php login POST login.php SQL 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 injection point list for experimental Web site Injection
point # URL Parameter
Threat type False positive False negative 1 login.php acc SQL 0 0 2 login.php pwd SQL 0 0 3 login.php login SQL 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 type # False positive # False negative Detecti on experimental
Web site SQL/ XSS 0 0 success
CVE-2010-0122 timeclock-software SQL injection 0 0 success CVE-2009-4669 RoomPHPlanning SQL injection 0 0 success CVE-2008-2488 RoomPHPlanning SQL injection 0 0 success
CVE-2009-4595 PHP Inventory SQL injection 0 0 success CVE-2010-1742 Scratcher XSS 0 0 success CVE-2009-4456 Green Desktiny SQL injection 0 0 success CVE-2009-3716 MCshoutbox SQL injection 0 0 success
Table V. The detail description about the testing result of some CVE_exploits
Program pages # Injection points # Vulnerabil ity point # Vulnerable page Flaw type # Experimen program 13 47 36 bbs.php SQL /XSS CVE-2010-0122 72 324 5 add_user.ph p SQL injection CVE-2009-4669 748 2947 2 Login.php SQL injection CVE-2008-2488 748 2947 4 userform.ph p SQL injection CVE-2009-4595 30 22 2 index.php SQL injection CVE-2010-1742 13 15 1 projects.ph p XSS CVE-2009-4456 9 10 1 news_detail.php SQL injection CVE-2009-3716 7 8 2 admin_login.php SQL injection
Table XI. Summary of the effectiveness evaluation for some WVSs (Web vulnerability scanners)
WVS_1 WVS_2 WVS_3 WVS_4 Our WVS CVE-2010-0122 N N N N Y CVE-2009-4669 N Y Y N Y CVE-2008-2488 Y N N N Y CVE-2009-4595 Y Y Y Y Y CVE-2010-1742 N N N Y Y CVE-2009-4456 Y N N N Y CVE-2009-3716 N N N Y Y V. CONCLUSION
Our proposed mechanisms for scanning Web application security were detecting vulnerability based on injection point, exactly obtain the information of injection point, and using black box testing to analysis what potential vulnerability, tackled vulnerable injection point. As we according to detect based on injection 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 SQL-injection 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 SQL injection 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/web-scanners.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.