Keywords

Introduction

Web application systems are one of the most ubiquitous software systems in use today. Since they appeared they have grown quickly and have evolved faster than other software systems. More than one billion people worldwide using the Internet and web applications as their daily routine activities for a variety of reasons, such as communicating with others, conduct research, shopping, banking and electronic commerce [1]. The web application is consider both, as a communication and a source of information [2]. It offers a collection of various services and resources such as customer support services, online banking and data transactions [2]. Most of the organizations use the web applications to make more profit and at the same time to increase the efficiency of their activities. The growth of these applications gave a high impact and business opportunity to the organization. As web applications become adopted by more and more organizations, they have become more complex and sophisticated. In many cases their success is crucial for the success of the organizations. Thus ensuring security of the Web application systems is a big concern for organizations.

Web application vulnerabilities represent huge problems for companies and organizations. These vulnerabilities leave organizations’ web applications exposed to attack and majority of all security problems in web application is caused by string based injection through web form such as SQL injection and cross site scripting. SQL injection vulnerabilities have been described as one of the most serious attacks for Web applications [3, 4]. SQL injection vulnerabilities are based on injection strings input into database to construct SQL queries and may allow an attacker to extract data from database. A web application is consider vulnerable to an SQL injection attack if an attacker is able to insert SQL statements into an existing SQL query of the application and extract sensitive and confidential data from database. This SQL injection vulnerability usually occurs when web application does not properly sanitize the user input.

With the majority of vulnerability exists in web applications today, it is important to evaluate and detect the vulnerability of web application before it is sent to production [5]. Detecting and preventing vulnerabilities in web application has become an important concern for organizations. Many organizations are starting to take initiatives to prevent these types of attacks. To minimize the probability of vulnerabilities exist in web applications, organizations need some methodologies or approaches to increase efforts to protect against web-based application attack [5, 6]. Therefore, organizations have a big task to implement security testing methodologies into the software development life cycle. The purpose of security testing is to find any security weaknesses or vulnerabilities within an application and document all the vulnerabilities to help developer to fix them. In this paper we develop a framework for testing and detection SQL injection vulnerabilities in web applications. We automate the process of security testing based on input injection attack pattern. We separated the framework into three stages. (i) Develop Test Cases Generator which is used to generate test cases. In the first stage, we apply permutation technique in order to generate test cases automatically; (ii). Develop Attack Generator. This generator will be used to automate the injection attack process based on input generated in the first stage. (iii). Response Generator. The goal of response generator is to analyze and determine whether an attempted attack has been successful or not. Some manual work is still required before automating the testing process. The process of modeling test case generation may not be very time consuming if the tester has knowledge about the internal structure of the application and type of SQL injection vulnerabilities.

This idea is using penetration testing framework adapted from Open Web Application Security Project (OWASP) and security testing lifecycle as shown in Fig. 1 [68]. On the middle of Fig. 1, by selecting and combining some components in penetration testing framework and security testing lifecycle, we proposed the new framework to automate the security testing in web application. In this paper, we are focusing on SQLIA due to the common vulnerabilities that have evolved in the last decade. The rest of the paper, we follow the idea of developing our framework. Our framework closely related to [7, 9, 10].

Fig. 1.
figure 1

Transition to new framework

The structure of this paper is as follows. Section 2 briefly describes the background of SQL injection attack. Section 3 discusses the proposed framework, Sect. 4 presents test result and Sect. 5 presents the conclusion.

Background of SQL Injection Attack (SQLIA)

SQL injection attacks are one of the topmost threats for applications written for the Web. In OWASP listing, SQLIA is always appear in top ten list. These attacks are launched through specially crafted user input on web applications that use input string operations to construct SQL queries [11]. These attacks used by attackers to steal data from back-end database of web application. It takes the advantage of dynamic input of web applications that allow users to insert data such as login form and registration page. This type of attack usually takes place when attackers insert some special code into web form. Online forms such as login prompts, search enquiries, guest book and registration forms are always the main target of SQL injection vulnerabilities. The simple test to check for SQLIA is to append ‘OR 1 = 1’ [12] or just single quote (‘) to any input of any form and wait for the data response returned. The response could be error message or any information that may give some clue to the attackers to conducting next step of attack. In the rest of this section, we discuss three important characteristics of SQLIAs that we use for describing SQLIA: how SQL works, injection based on attack input, injection based on attack intend and injection based on SQL types.

How SQL Works

SQL is stand for Structure Query Language and originally developed in the early 1970’s by Edgar. SQL is used for accessing database servers including MySQL, Oracle and SQL server. Web programming language such as Java, ASP.NET and PHP provide various methods for constructing and executing SQL statements. In addition, SQL language is a communication way between users and database in order to allow the user to interact with database. SQL statement can modify the structure of databases and manipulate the contents of databases [16].

SQL Injection Attack Based on Input Source

Malicious SQL statements can be introduced into a vulnerable application using many different input mechanisms. In this section, we explain the most common mechanisms. Table 1 explains the most common input that usually used by attackers [1215].

Table 1. SQLIA based on input source

SQL Injection Attack Based on Attack Intend

SQLIA can also be characterized based on the goal, or intent, of the attacker. Attacks have been characterized by their intent are summarized in Table 2 [9, 1214].

Table 2. SQLIA based on attack intend

SQL Injection Attack Based on Attack Techniques

There are a variety of techniques that attackers can use to perform these attacks [9, 1214]. The most common SQLIA based on the attack type are summarized in Table 3. The different techniques of attacks are generally not performed in isolation. Attackers may use and combine these techniques in order to achieve several attack types based on attackers’ goal. In this paper, we just summarize all possible attack without writing detail. These types of attacks will be used in the next section to generate test case generation.

Table 3. SQLIA based on attack technique

Our Proposed Framework

As shown in Fig. 1, our proposed framework adapted from penetration model and security testing lifecycle model. In our framework, we develop three main components and Fig. 2 shows our proposed framework.

Fig. 2.
figure 2

Overview of proposed framework

  1. 1.

    Input Generator - input generator component is used to generate test cases based on injection attack pattern. We apply permutation technique in order to generate test cases automatically [17].

  2. 2.

    Attack Generator - this generator will be used to automate the injection attack process based on input or test cases generated in the first phase.

  3. 3.

    Response Generator - The goal of response generator is to analyze and determine the response and output send by web server in order to detect vulnerabilities.

Input Generator

In this section, we discuss our approach in generating test cases automatically based on attack techniques. Based on input string in attack technique as shown in Fig. 3, we formulate and design the attack grammar and divide into six different patterns templates as listed below:

Fig. 3.
figure 3

Formulation of attack file to generate test cases

  • #numeric = all numeric characters [0-9]

  • #alphabet = all alphabet characters [A-z]

  • #non_alphanumeric = not alphanumeric but printable (e.g.: punctuation)

  • #sql = sql syntax (sql.txt)

  • #operator = the operators used in various programming language (operators.txt)

  • #inline_comment = various type of comments (inline_comments.txt)

Using permutation algorithm [17] this pattern generates different variations of test cases based on SQL injection attack as shown in Fig. 4. For example, from the tautology technique, the simple input string to inject to input field is ‘OR 1 = 1. There are a lot of combination of tautology’s input string in order to detect vulnerability such as ‘OR 1 = 1–, ‘OR 1 = 1#, etc. Testers are allowed to modify and insert new data in pattern template.

Fig. 4.
figure 4

Input generator component

In this section, we follow closely related paper for test case generation. [1820]. The main important in this phase is master_template file. Master_template file will be executed after tester run the generator. The master template contains list of template for the application to perform permutation to generate more test cases. To form the template we introduce a syntax which started with ‘#’ symbol to represent the data that needs to be replaced. The generator then generate the dictionary files that contains all pattern files (sql.txt, operators.txt, inline_comments.txt, etc.) to form list of string tokens for test cases. Each test case is generated automatically by using permutation algorithm based on the input line in the master_template file. Refer to Fig. 4.

Based on a sample in Fig. 4, we can see in master_template file, there are two lines listed and attack generator will generate the test cases separated and saved in a different file. By applying the permutation technique algorithm, we shall get the following results as stated in Table 4.

Table 4. Test Case Generation

Attack Generator

The fundamental objective of this section is the design of the framework that covers all steps to automate the injection attack process. After the generation of test cases have completed, Attack generator starts processing a set of target URL and target parameter. As mentioned before, some manual work is still required before automating the attack generator process. Tester is needed to identify target URL and target parameter. The test cases that have been generated in phase1 will be used as an input in this phase. In order to extract HTTP response and injecting to the target system automatically, we develop our framework with Apache HTTP Client API. We present an efficient algorithm to send many attacks and handle many HTTP response page as shown in Fig. 5. Attack generator component will use input.xml file to attack to target system by using POST or GET method and also identify which parameter is chosen to inject the input generated test cases from previous phase [2124].

Fig. 5.
figure 5

Attack generator component

Sample of Input.xml file

Response Generator

After an attack has been launched, the analysis of response page will be send to the response generator. The response generator component uses attack specific response criteria to decide if the attack was successful. If the web application does not handle exceptions or server errors, the result for SQL error description will be included in the response page.

Result

This section presents the testing results that we have carried out to assess our framework. For the testing of our framework, two different vulnerable web applications were deployed locally and tested against SQLIA. This testing applications are namely as Mutillidae and WackoPicko website. Mutillidae website has an authentication bypass vulnerability, which allows the attacker to directly access the administrative functionalities. WackoPicko is an online photo sharing website that allows users to upload, comment and purchase pictures It is designed with a number of vulnerabilities, such as cross-site scripting and SQL injection [11]. Our framework was deployed by setting up Eclipse development environment with Java Program. Apache HTTP Client API library has been installed in our machine to extract HTTP header from response page. In test case generation phase, we generate 124 attack injection for SQL injection attack. Each parameter will be tested with 124 test cases. In this paper, we focus on the SQL injection vulnerability through input field such as login, search and registration field.

We test the framework with injecting attack test cases, and the results are summarized in Table 5. The response results will consider vulnerable if error messages and bypass authentication result are appeared in HTML document header. Based on testing results, we can conclude that all input forms are vulnerable to website. Response generator will analyze which input test cases have been generated to produce vulnerabilities.

Table 5. Vulnerability detection result

Conclusion

In this paper, we have proposed a method to generate test cases by using attack technique pattern with applying permutation algorithm to generate it automatically. This framework has been successfully tested and including several type of SQL injection vulnerabilities. Our framework is able to addresses the vulnerabilities based on results in Table 5. Future work will also be focused on extending our approach to cover other types of vulnerabilities such as Cross Site Scripting vulnerabilities.