1 Introduction

Technology and networks enable organizations to have adopted web-based applications as a backbone to conduct their day to day activities. Different domains like Intelligent Transportation Systems [1], Healthcare Systems [2], Industrial Technologies [3], E-commerce [4], social activities are all now available on web-based databases driving applications and where the security of web applications is, in general, quite poor and demanding [5, 6]. These applications process the data and store the result in a back-end database server where the organization’s related data are stored. Depending on the specific purpose of the application, most of the communication with customers and users use the services offered by the organization. The fact that these applications can be invoked by anyone worldwide drew the attention of attackers who wish to benefit from these vulnerabilities. One of the techniques to exploit these applications (web-based driving database applications) is called SQLIA (SQL injection attack). SQLIA is a situation whereby attack modifies programmer intended queries to have access to restricted data or perform unauthorized data manipulations. SQLIA comes in a variety of types depending on what attacker wants to accomplish, but the main cause of SQLIA is improper validation of input by user which programmer should take care of while developing the application [5,6,7]. To tackle the problem of SQLIA, researchers have been proposed different techniques to handle SQLIA. These techniques have limitations starting from research scope to address particular type of SQLIA, deployment capability to the approach, tool or technique.

Most of the researches regarding the evaluation of SQLI prevention measure have focused on evaluation ability to address the particular type of attacks. Similarly, the need to evaluate such SQIAs and taken prevention measures or develop a new approach in various injection parameters is also important. Because the SQLI prevention measures can affect the effectiveness of the tool to address the SQIAs types. If the tool cannot be deployed in a particular injection parameter, it implies that attack injected through that injection parameters would be carried out successfully without any detection or prevention by tool or technique. Thus, the focus of this review is to assess the effectiveness of current SQL injection prevention (SQLIP) tools and techniques based on their ability to address SQLIAs with respect to development approach and ability to be deployed in different injection parameters and also determine the new trend of the research in the field of SQLIA. The results of our evaluation will help new researchers who want to improve the current trends in SQLIAs prevention measures.

2 Research Material and Review Method

Systematic Literature Review (SLR) is a type of review that follows a sequence of precise methodological steps for reducing bias in research. This SLR on SQLIA prevention measures is based on well-established and evaluated review protocols to extract, analyze, and report the results as shown in Fig. 1. We adopted the guidelines provided by [8] with a three-step review process that includes planning, conducting and documenting.

Fig. 1
figure 1

Research methodology steps

Full size image

Figure 1 summarizes the steps of the review process; planning, conducting and documenting the methodology adopted in this SLR. The results of the analysis are documented in terms of a data summary in Sect. 2.3, and findings and research implications in Sect. 2.4.

2.1 Planning Phase

In this SLR of SQL injection detection and prevention measures, the planning phase begins with an identifying need for SLR, identification of the research questions and describing the review process. Having these parameters defined, we can formulate a review protocol.

2.1.1 Identifying Need for SLR

There are several studies on SQLIAs detection and prevention tools and methods such as [5, 9,10,11,12,13,14]. None of these methods provide a systematic way of conducting a literature review on tools and methods. This gives us the motivation to conduct SLR on SQLIAs detection and prevention tools based on research questions (Table 1).

Table 1 Research questions and motivation
Full size table

2.1.2 Specifying Research Questions

This study is mainly based on four (4) research questions (RQs). Most of the proposed approaches have focused on evaluating the effectiveness of existing SQLIAs detection and prevention tools which are based on SQIAs types where each tool or method can detect or prevent. In addition, this study tries to investigate further by considering the effectiveness of tools and methods which are based on tool or method ability to be deployed on particular injection parameters (Sect. 2.3.2). Based on development requirements, proposed a method or tool (i.e. anomaly-based that are prone to false positive and false negative alarm). Concerning the aforementioned motivation, we defined four research questions that represent the foundation for deriving the search strategy for literature extraction (See Table 1).

2.1.3 Review Process

After identifying the need for SLR, RQs are the next step to refine the review process. This begins with related studies retrieval from different databases, studies selection, extracting the result from data in the selected studies and information synthesis. Figure 2 shows the follow of processes followed in the review process.

Fig. 2
figure 2

Study selection process

Full size image

Searching Related studies query retrieval covered six different databases (Table 2). The search terms and guidelines adopted from which a composition of 453 different search strings have used (Fig. 3).

Table 2 Search query result from different databases
Full size table
Fig. 3
figure 3

Used search strings

Full size image

Based on the above strings (search term used), we retrieved 1261 peer-reviewed literatures, methods and techniques from the years 2006 to 2019 (inclusive) from six sources (Table 2).

Initial Selection This activity is carried out by screening the titles and abstracts of potential primary studies performed by the researchers against inclusion/exclusion criteria in Table 3. For almost 30% of studies, no decision could be made. In such cases, exclusion or proceeding for final selection is involved in examining the full text.

Table 3 Inclusion and exclusion criteria
Full size table

Inclusion and Exclusion Criteria Table 3 provides the summary of inclusion and exclusion criteria adopted in this study.

Final Selection After scanning the result from initial selection validation ware made on studies based on proposed SQL methods, techniques, and firewall/tool and SQL types to support the evaluation approach. By considering inclusion criteria we selected 46 studies based on selection criteria adopted from Guidelines [8] snowballing which is based on data and result presented in the considered study (Quality assessment criteria). Out of these 83 studies, one is guideline is not related to the field of the study, therefore, the total number of studies considered is 83 as shows in Table 4.

Table 4 Search material
Full size table

2.2 Conducting Study

Section 2 describes the procedure followed in SLR planning on SQLIAs detection and prevention measures using guidelines in [8] and describes the procedure in conducting the SLR of SQLIAs study. This phase begins with conducting quality assessment criteria.

2.2.1 Conduct Quality Assessment (QA)

We used the Center for Reviewer and Dissemination (CRD) and Database of Abstract of Reviews of Effect (DARE) criteria to evaluate each technique. The following four questions are asked for quality assessment and the answers to these questions are summarized in Table 5.

Table 5 Quality assessment procedure
Full size table

Based on above questions and answers in Table 5, where we evaluated selected studies as summarized in Table 6.

Table 6 Quality evaluation using DARE scale
Full size table

Table 6 shows the list of selected studies, Eighty-three (83) studies are selected out of 1261 studies. This SLR indicated that more journal articles are published than conference proceedings. Out of these studies, Sixty-nine (69) proposed tools and methods ([S2-23, S36-S83]) Twelve (12) are survey (seven analytical analyses [S24-S30] while five are experimental analysis [S31-S35]) related to SQLIAs detection and prevention measures and one [S1] is not related to this study. This analysis shows that the researchers are more focusing on solution for the detection and prevention of SQLIAs than evaluating efficiency and accuracy of existing tools and methods (See Figs. 4, 5, 6) which show demand for evaluating the current SQLIAs detection and prevention tools.

Fig. 4
figure 4

SQLIA types

Full size image
Fig. 5
figure 5

Users database records

Full size image
Fig. 6
figure 6

User input credential form to use the system with valid credential

Full size image

Because we used DARE criteria for evaluating the quality of study as described (See Sect. 2.2.1 Table 5) therefore, information in Table 6 shows that Nineteen (19) out of Eighty three (83) related studies [S4, S5, S6, S7, S8, 10, S11, S12, S13, S17, S19, S20, S21, S22, S24, S24, S497, S49, S60] satisfied the quality assessment using DARE scale by scoring 4/4, while Thirty two (32) related studies [S2, S3, S9, S14, S15, S18, S25, S36, S38, S39, S41, S42, S44, S45, S48, S52, S58, S59, S62-69, S74-S77, S79, S80] score 3.5/4, likewise Twenty four (24) [S16, S26, S27, S28, S29, S37, S43, S46, S50, S51, S53-S57, S61, S70-S73, S78, S81-S83] out of Eighty three (83) score 3/4, while One (1) [S35] study score value 2.5/4 and also Six (6) [S30, S31, S32, S33, S34, S40] studies score value of 2/4, One study S1 score 0/4 as is not related to this study which is used as a guideline. In summary, the information in Table 6 shows that the maximum number of related studies considered are satisfied with quality assessment questions.

2.2.2 Data Extraction and Synthesis

We carefully extracted and synthesized the data from each study for collecting the following information:

  1. 1.

    Classification of study and its topic domain.

  2. 2.

    Types of SQLIAs

  3. 3.

    Injection parameters

  4. 4.

    Assessment of the proposed technique’s effectiveness, if available

Having extracted data from the considered studies, we analytically evaluate them, without any experimental proof (using experience), based on the classification of the study domain and with respect to attack the injection parameters. Basically, during the evaluation, we combine the classification for domain types of SQLIAs and tools effectiveness which is one of the evaluation strategy entitled “evaluation with respect to attack types” which enable us to answer research question four (RQ4).

2.3 Documenting

The aforementioned sections described the procedure followed in planning of this SLR using guideline in [8]. This phase begins with conducting quality assessment criteria.

2.3.1 Types of SQLIAs Used for Attacks

In view of RQ1 (See Table 1), the study explored Eighty-two (82) studies. Out of the 82 reviewed studies, 44 fully presented the data on different techniques by which attackers use SQLIAs for attacking the web application database (See Table 6). Attackers use SQLIA to attack web applications and these attacks are fall in different types, depending on what attackers want to achieve. Moreover, these attacks are classified into Seven (7) types [5, 9,10,11,12,13,14] as represented in Fig. 4.

2.3.1.1 Tautology Attack

This is a type of attack that takes advantage of “WHERE” clause in SQL statement to evaluate the results returned by Query in a relational database which is always true. Attackers use this type of attack to achieve authentication bypassing in web applications or perform unauthorized database extraction [5, 9, 10, 56] Authentication bypassing: all relational database management system with no exception evaluate SQL query with “OR 1 = 1” where clause is always true. Also, in a relational database management system, anything followed by comment (–) will not be processed. For example, consider the Fig. 5 database records presenting users credential and personal details and Fig. 6 shows the client sides that takes input credential from user for authentication to use system (Table 7).

Table 7 Logical output of successful authentication of scott credential
Full size table

Upon pressing the login button as shown in Fig. 6, the scott details would be submitted and passed to admin.php script ($ucredential=$_POST [‘ ucredential’]; $pcredential=$_POST[‘pucredential’]; $Query=”select * from user_ ucredential where userid=’$u ucredential’ and password=’$p ucredential’ “; $result=mySQL_query($SQL);) where it would be validating against scott credential details stored in fig. if the input from Fig. 44 matched with one stored in the scott would be grand access to the system and logical record output presented in Table and if the details did not match, invalid user name or password would be received.

In the above Fig. 7, the input username credential contains malicious SQL injection attack codes; input by malicious user and password could be anything. When this code is passed to $ucredential and $pcredential and executed by the database server, this might result in a serious threat. This means that the interpreter is fetched all the records which exist from the users_details table and returned them into $result which will be presented by a malicious user. The above code can be interpreted as $SQL = ”select * from user_details where ucredential = ’select * from user_details where userid = ’onyone’ and password = ’anything’ or ‘1=1;’ and password = ’anything’ or ‘x’=‘x’ “;

Fig. 7
figure 7

User input credential form to use the system with tautology SQL injection attack

Full size image

With the help of WHERE clause the statement of 1=1 or x=x is always returning to true for every row, therefore the query will return all the records. In this way, an attacker able to view all the personal information of the users for example of output presented in Table 8.

Table 8 Logical output of successful tautology SQL injection attacks on user authentication form
Full size table
2.3.1.2 Illegal or Incorrect Logical Query

Knowing the server, schema, table, and column names make it easy for attackers to gain unauthorized access to the system [5, 9, 10]. For example, consider the Fig. 8 below with URL input as http://localhost/ticketreservation/reserved.php/ select * from user_details where userid = ’onyone’ and password = ’anything’ or ‘1=1;’.

Fig. 8
figure 8

Example of illegal or incorrect logical query

Full size image

If you notice at the end of the ULR http://localhost/ticketreservation/reserved.php/ a malicious code is introduced. This is local host website, where we test the malicious node activity. This disturbs the database engine because when you type something within the quote it is used to tell the database that this is a query and to process it. So after processing makes the database engine returns the error message in Fig. 9.

Fig. 9
figure 9

Output of illegal or incorrect logical query

Full size image

As can be seen information in Fig. 9, it indicates database server, version, platform and other vital information which helps the malicious users to gather the required information to lunch devastating attacks to the target system.

2.3.1.3 Inference Attack

This attack can be classified into Blind and Timing SQLIA [5].

  1. A.

    Blind SQL Injection Attack

This is another method of doing database fingerprinting. Sometimes database engines can be configured to hide database error messages and return a generic error to the user when there is an SQL syntax error in the user’s SQL statement. This can serve as a method to prevent attackers from database fingerprinting by using illegal or incorrect query methods. However, this does not mean the database is secure; it only conceals the return default error message which will be difficult for attackers who rely on database fingerprinting as a first step in carrying out an attack. Thus blind SQL injection attack can be used to deduce if there is a security mechanism implemented in the web application or not. Blind SQL injection attacks can be achieved by asking a series of true or false queries in the database. In this case, the attacker tries to inject the following statements:

  • SELECT * FROM emp_name, emp_address, gender, from employee where 1=0; drop employee//-----------Statement (1)

  • SELECT * FROM emp_name, emp_address, gender, from employee where1=1; drop employee//------------------------Statement (2)

After executing the above Boolean malicious SQL query, an attacker knows about the database is secure or not. If the same response is delivered (return a generic error message) there is protection mechanism that has detected an attack and blocked the query from executing and returned an error message to the user because all of the statement contains malicious words. A different response means that the query has reached inside the database engine and has been executed. Therefore, the first query returns an error message because it is an incorrect query while the second mayor may not return any error message because it is a correct query.

  1. B.

    Timing Attacks

In this type of attack, the response time which the database takes to respond to the user’s query is noticed which helps to know some information from a database. This method uses an if–then statement for injecting queries. WAITFOR is a keyword along the branches, which causes the database to delay its response by a specified time. For example, an attacker can extract information from a database using a vulnerable parameter.

  • declare @ varchar (8000) select @s = db_name () if (ascii

  • (substring(@s, 1, 1)) & (power (2, 0))) > 0 waitfor delay ‘0:0:8

2.3.1.4 Union Attack

This is the most common type of attack used by attackers in gaining access to restricted data in other tables. The malicious SQL query can be appended by an attacker to combine with valid SQL queries to gain unauthorized access to extra data [5, 9, 10]. For an example of a malicious attack, consider the following example where online human resources in a particular company allow employees to view only their details online. A malicious user can access extra information such as employee salary and phone number from Fig. 10.

Fig. 10
figure 10

Employee details database records

Full size image

The information on fig can be interpreted as

SELECT * FROM user_details WHERE userid=‘‘ UNION SELECT * FROM EMP_DETAILS – ‘ and password=‘admin’

This means that after successful authentication, the malicious user has access to Emp_details table with the help of two dashes (–) comments.

This feature creates an opportunity for an attacker to perform dangerous action in the database. In this case, a valid query is terminated by (;) and a malicious query is added. After processing the valid query, a malicious query is then executed, unlike in piggy backend query where a malicious query has joined with a valid query and processed as a single joined query (Fig. 11).

Fig. 11
figure 11

Example of union SQL injection attack

Full size image
2.3.1.5 Alternate Encoding

Most of the SQL injection mechanisms that use filters prohibit the use of quote (‘) in the SQL statement which can be used in constructing different kinds of malicious query requests to the database. In this case for an attacker to bypass such a filter and has to convert SQL query into alternatives encodings such as hexadecimal, ASCII or Unicode. Converting SQL query into alternate encode enables them to carry out their attacks. For example

“0; exec (0x73587574 64 5f177 6e), “ and the result query is: SELECT accounts FROM login WHERE username=“ AND password=0; exec (char (0x73687574646j776e))

The above example uses the char () function and ASCII hexadecimal encoding. The char () function takes hexadecimal encoding of character(s) and returns the actual character(s). The stream of numbers in the second part of the injection is ASCII hexadecimal encoding of the attack string. This encoded string is translated into the shutdown command by the database when it is executed.

2.3.1.6 Piggery-Backend Query Attack

Some of the database engines support stacked queries by default. This feature creates an opportunity for an attacker to perform dangerous actions in the database. In this case, a valid query is terminated by (;) and a malicious query is added. After processing the valid query, a malicious query is then executed, unlike in a union query where a malicious query is joined with a valid query and processed as a single joined query. For example: consider in Fig. 12 below.

Fig. 12
figure 12

Example of Piggy Backend query SQL injection attack

Full size image

The information on Figure can be interpreted as

  • select * from user_details where userid=‘admin’ and password=‘admin’; drop table user_details – ‘.

Once the first query executed then, the database server would use the query delimiter(“;”) and process the injected second query. The result of executing the second query would be to drop table users_details table, which would destroy valuable information.

2.3.1.7 Stored Procedure

A stored procedure is a part of the database where programmers could set an extra abstract layer on the database as security to prevent SQL injection attack. As the stored procedure could be coded by the programmer, so, this part is known as an injectable web application. Depending on specific database storage procedure there are different ways to attack [5, 9].

2.3.2 Injection Parameters

In view of RQ2 (See Table 1), this section provides a detailed description of the injection parameter (HTTP GET, HTTP POST, Cookies, etc.) where attackers craft malicious queries to the application databases through a client application. Two (2) [5, 9] out of 83 studies explored in this study have fully presented different injection parameters by which attackers inject malicious queries in web-based driving database applications as discussed in Sects. 2.3.2.1 to 2.3.2.4 below.

2.3.2.1 Injection Through User Input Field

User input fields are provided in web applications to enable web application users to request information from the backed databases to the user with the help of HTTP POST and GET (See Fig. 6). These inputs are connected with the backend database using SQL statements to retrieve and render the requested information for users or to allow users to connect to the system. User input fields are vulnerable to SQL injection attacks if input provided by the user is not sanitized before sending it to the database server for processing, which enables attackers to modify intended queries to perform malicious action in the system.

2.3.2.2 Injection Through Cookies

Cookies are structures that maintain the persistence of web applications by storing state information on the client machine. When a client returns to a Web application, cookies can be used to restore the client’s state information. If a Web application uses the cookie’s contents to build SQL queries, then an attacker can take this opportunity to modify cookies and submit to the database server.

2.3.2.3 Injection Through Server Variables

Server variables are a collection of variables that contain HTTP, network headers, and environmental variables. Web applications use these server variables in different ways, such as session usage statistics and identifying browsing trends. If these variables are logged to a database without sanitization, this could create SQL injection vulnerability because attackers can forge the values that are placed in HTTP and network headers by entering malicious input into the client-end of the application or by crafting their request to the server.

2.3.2.4 Second Order Injection

In second-order injections, attackers plant malicious inputs into a system or database to indirectly trigger an SQLIA. When that input is called at a later time when an attack occurs, the input that modifies the query to construe an attack does not come from the user, but from within the system itself.

3 SQLIAs Detection and Prevention Approaches

In view of RQ3 (See Table 1), the study provides the trend of current SQLIAs detection and prevention tools and methods proposed by various researchers to handle problems of SQL injection attacks. These methods start from the development of best practices to automatic tools for detecting and preventing SQL injection attacks. We also considered considering studies that evaluate the effectiveness of these proposed tools and methods (both experimentally and analytically) as to be summarized in Fig. 13 below.

Fig. 13
figure 13

Trend of the study

Full size image

Result of analysis in Fig. 14, presents that there is a side by side effort by different researchers in trying to evaluate the effectiveness of existing SQLIAs detection and prevention tools and methods from 2006 to 2009 where the experimental evaluation goes high in the year 2010–2011 and again goes down in the year 2013–2015 compared to analytical evaluation (review analysis). While in case of propose tools and methods it shows are searchers are putting more effort into finding the way of combating with the problem of SQLIAs, which shows a significantly increasing number of the proposed method each year unless the year 2011 and 2015 with 2018 with highest proposed methods and tools.

Fig. 14
figure 14

Percentage selected studies with respect to Focus

Full size image

Figure 13 shows the trends of the studies related to SQLIAs detection and prevention measures; similarly, the Fig. 6 shows the percentage (%) number of studies extracted and selected from six different databases related to SQLIAs detection and prevention measures in this study with proposed solution with 70 studies or 85.4%, review analysis 5 studies or 6.1% and experimental evaluation 7 or 8.5%. In summary, the study shows that researchers focus more on proposing a solution to tackle the problem of SQLIAs rather than evaluating the efficiency and accuracy of existing tools and methods (Figs. 13 and 14).

3.1 Discussion of Reviewed SQLIAs Detection and Prevention Approaches

In view of RQ4 (See Table 1), we assess the effectiveness of current SQLIA detection and prevention measures with respect to development approach and the ability to be deployed in various injection parameters considered (Sect. 2.3.2).

To achieve that, the following questions were asked:

  • What are the scopes of current techniques to address particular attack type?

  • How effective is this technique is with respect to deployment requirements?

  • Do current techniques be deployed in each injection parameters?

  • Does techniques required code modification when new web page is added?

3.2 Discussion on SQLIAs Prevention Tools Based with Respect to Attack Types

We analyzed and evaluated each proposed method as shown in Tables 9 and 10. To ensure a particular tool or method is capable of addressing a particular attack type described (Sect. 2.3.1); we used analytical evaluation based on experience. We have not assessed any of the tools or methods in real-time practice for the reason that most tools or method’s implementation codes are not available or some methods are not implemented. Table 9 presents evaluations of SQLIAs detection tools and methods considered in this study.

Table 9 Evaluation of prevention tools and methods based on attack types
Full size table
Table 10 Evaluation of detection tools and methods based on attack types
Full size table

As indicated in Table 9 out of the tools and methods considered, only Three (3) of them, [S4], [S6] and [S7] focus on addressing all types of SQLIAs considered the rest of proposed tools and method focusing on addressing a subset of SQLIAs. However, the effectiveness of these tools and methods considered for addressing particular types of SQLIAs varies depending on the approach used, in developing tools or method, and its ability to be deployed in various injection described parameters, (See Sect. 2.3.2 for injection parameters consider in this study). For example, we used four different symbols “•”, “×”,“◦” and “–” to describe the effectiveness of the tool or method considered in Table 8, with “•” indicates that a method can successfully stop all attacks of that type, “×” indicates that a method is not able to stop all attacks of that type and “◦” indicates that a method can address the attack type considered, but cannot provide any guarantee of completeness.“–” indicates that a method can partially address the attack type considered, but cannot provide a guarantee of completeness.

For example, tick dot symbol (“•”) as can be seen in Table 8 is used for [S3], [S5], [S12], [S13], [S14], [S19], [S20], [S21], [S22], [S23] which indicates this method or tool can guarantee protection of particular SQLIAs type which they are developed to addressed (but cannot prevent out of their scope). However, out of these tools and methods, none of the tools can successfully be deployed to prevent all injection parameters considered (See Table 9). The (“◦”) and (“–”) symbols are used in Table 9 to indicate that method or tool can partially detect and prevent SQLIAs type considered without guaranteeing that a given method prevents the future attack of similar addressed type. We used (“◦”) for methods that implement anomaly or machine learning-based approach to detect and prevent SQLIAs for example [S6], [S7], [S8], [S9], [S10], [S11], and [S16], this is because these approaches use sets of typical application queries as input data set to train the protection model, thus any query that goes against the model might result in false positive or false negative. Therefore, the effectiveness of these tools and methods is highly dependent on the quality of training data set used and how good the model trained, as poor training data set and model result in false-positive and negative. Thus, the effectiveness of methods and tools implementing these approaches is considered partial using circle (“◦”) symbol as shown in Table 9. Other methods considered as partial are [S4], [S15], [S17] and [S18] methods that use SQL query related errors (first-order SQLI vulnerability) to detect prevent SQLIAs as SQL query related errors is only one of the many possible ways to prevent of SQLIAs. We used (“–”) to represents tools and methods implementing such an approach (Table 9).

Diglossia is tool that is able to partially adress all type of SQL injection attack considered in this study (Table 9). Diglossia consist of two major conponet (Fig. 15) that intecept user queries (valid and malacious) break it into SQL keyword. This enable the tool look for malicious keyword or character in the user request to database.

Fig. 15
figure 15

Component of the solutions proposed in studies S4

Full size image

Alternate encoding and stored procedure are the most important case of SQL injection attacks that are hard to defend by many of the proposed tools and methods considered. However, S4 provides a partial solution with a filter that detects and prevent the use of quote (‘) in the user input, to avoid malicious request that is being constructed with (‘). While in the case of the stored procedure, S4 can examine code that generates the query when stored is executed on the database unlike most of the methods considered focus on preventing an attack on queries that are generated with applications.

3.3 Discussion on SQIAs Detection Tools Based with Respect to Attack Types

Table 9 above represents an evaluation of SQLIAs prevention tools and method while Table 10 below represents an evaluation of SQLIAs detection tools. In Table 10 we described effectiveness of each tools and method considered using Four different symbols while in Table 8 we used only Two different symbols (and X) this is because in detection approach considered in different researchers uses similar approach (dynamic approach or penetration testing) in trying to resolve problem of SQLIAs while in prevention approach different researchers employed different approaches (i.e. anomaly-based, machine learning-based blacklisting and white listening, etc.) in developing these tools and methods and some of these methods are problematic in nature i.e. anomaly-based (prone to false and negative alarm) some cannot be deployed in every injection parameters considered in this study i.e. whitelisting and blacklisting approaches.

Table 10 shows that most of the detection tools and method considered in this study are able to resolve” tautology, illegal or incorrect query, union query and alternate encoding SQLIAs” while inference and stored procedure attack seems to be a difficult attack to be addressed by many of the tools and methods considered this because the code that generates the query is stored and executed on the database and most of the methods considered focus on preventing attack on queries that are generated with applications. However, it is important to note that we did not take precision into account for evaluation, that is to say, many methods and tools considered are based on conservative analysis that may result in false positive.

3.4 Evaluation of SQLIAs Detection and Preventions Tools and Methods with Respect to Injection Parameters

In this section we combine evaluation of SQLIAs detection and prevention tools and methods together (Table 11), this is because every attacker who wants to perform SQLIAs against web-database driving applications has to use one or more injection parameters considered in this study, therefore, there is no need of separation of evaluation since this injection parameter are same to any web-database driving application. In this regard, we analyzed each tool and method considered with respect to their handling of the various injection mechanisms described (Sect. 2.3.2). We used “Yes” to indicate a tool or method that can be deployed to that injection parameter and “No” to indicate that the tool cannot be deployed that parameter injection parameter (Table 11).

Table 11 Evaluation of detection and prevention tools and methods based on injection parameters
Full size table

Table 11 shows only [S2, S3, S4, S6, S7, S8, S9, S42, S47, S63, S64, S66, S75, S78, S79] can be deployed in “URL login, search, and cookies input fields, while [S5, S10, S11, S16, S17, S19, S20, S21, S37, S38, S40, S41, S43, S45, S46, S47-S49, S54, S55, S57-S59, S65, S81, S82] can be deployed in “URL, login and search input fields and [S12, S13, S14, S15, S18, S22, S23, S36, S39, S44, S50-53, S56, S60-S62] can only be deployed in “URL and login” input fields. This shows that none of the studies (tool or method) considered can be deployed to detect or prevent an attack that exploits the server-side vulnerability. This is due to the fact that server-side is vulnerable to second-order SQLIV which is not a problem of sanitizing sensitive function but is intentionally created by attackers through vulnerable parts of the application (not necessarily through Login. Add user page or ULR attacker may also use file inclusion attack to exploit dynamic file include) and reside in application database. In summary, it is important to know that all of the tools and method considered can address attacks through URL and login input fields, halve of the tools and method considered can examine queries in search input field, average number of the tools and methods considered can examine queries in cookie fields, and none of the tools or method considered can detect or prevent attacks that take advantage of server-side SQLI vulnerability (See Table 11).

4 Conclusion

This SLR on SQLIAs detection and prevention measures adopt guideline in [8] on conducting a systematic literature review on software, our study explores different studies from six different studies published the database, we carefully selected Eighty-two (82) studies out of initial 1261 based on inclusion and exclusion criteria defined in a study. Out of these eighty-two (82) studies, our study shows that seventy 70 or 85.4% are methods and tools proposed by different researchers to mitigate the problem of SQLIAs, while 7 or 8.5% are proposed experimental evaluation 5 or 6.1% are analytical analysis.

The evaluation result showed that a few of these proposed SQLIAs detection and prevention tools and methods are developed to address all types of SQLIAs while others focused on addressing a subset of particular SQLIAs type considered. Similarly, the result showed that a few of these tools can examine malicious SQL queries injected through cookies with no tool or method considered be able to detect or prevent attacks from server-side vulnerability.

In conclusion, one of the reasons why researchers have not been able to find the ultimate solution for the problem of SQLIAs is that each proposed methods and tools have a limitation on how it addresses a particular attack, starting from scope of the proposed method to its weakness in the development approach. For example, as can be seen in Fig. 16, almost each of the proposed SQLIAs prevention tools and methods reviewed in this study provides the guarantee of protection tautology, illegal/incorrect query, and union query SQLIA by 62.2%, alternate encoding attack by 42.2%, piggy-backend query attack by 22.2%, inference, and stored procedure attack by 11.1%. Likewise, SQLIAs detection tools and methods considered in this study provides the guarantee of protection tautology, illegal/incorrect query, and union query SQLIA by 20%, alternate encoding and piggy-backend query attack by 17.7%, inference attack by 11.1% and stored procedure attack by 2.2%. On the other hand, the study shows that the number of studies that proposed an evaluation of existing SQLIAs detection and prevention tools and methods is quite low, which is around 26.7%, 15.6% for analytical evaluation, and 11.1% for experimental evaluation. Lastly, this study highlights the major challenges that required immediate response by developer and researchers in order to prevent the risk of being hacked through SQLIAs lack of capability to detect attacks that can exploit server-side SQLI vulnerability, poor prevention of inference and stored procedure attacks lack of ability to be deployed in various SQL injection parameter used in target applications.

Fig. 16
figure 16

Research contributions regarding SQLIAs

Full size image

5 Future Work

The study provides a comprehensive overview of SQL injection detection and defensive tools and method to combat unauthorized access and data modification on web-based database-driven applications. However, these tools and methods have weaknesses ranging from development practice to deployments capabilities. Our study reveals that none of the tools can fully detect or prevent all SQL injection attacks types. Tools [S4, S6, and S7] attempts to stops SQL injection attacks of all type, however, their accuracy highly dependent on the quality of training data set used and how good the model was trained, as poor training data set and model result in false-positive and negative. Therefore, these tools can only partially depend against a subset of SQL injection attacks considered as a result of common development errors and attackers are continually inventing ways of bypassing anomaly-based approach detection and prevention mechanism. Therefore, the effectiveness of these tools and methods is highly dependent on the quality of training data set used and how good the model was trained, as poor training data set and model result in false positive and negative.

Furthermore, the study recommends S47 for future improvements as a tool can be deployed in various injection parameters to detect SQL injection attack types except for stored procedure and time SQL injection attacks type. S47 is designed with the concept of components based software engineering practice as described in Fig. 17 below, which allows easier and efficient future improvement, maintenance and reuse much complexity as the system becomes complex. The proposed tool has four major components, namely: crawling, attacking analysis and reporting in addition to this, each component has sub-components indicating activities performed by the component. In the attack component, the tool claimed to detect SQL injection attack type considered except stored procedure SQL injection attack.

Fig. 17
figure 17

Components of the solutions proposed in studies S47

Full size image

Finally, the study recommends designing of hybrid SQL injection attack tool that detects and block SQL injection attacks using the static and dynamic approach to have a more accurate result with high efficiency. In future, our focus on most recent studies of internet of vehicles, vehicular ad hoc networks and wireless sensor networks security analysis [86,87,88].