Keywords

1 Introduction

Computer Security is the biggest challenge of the current era [1–3]. Data and computer systems are key targets of attacks. As per IBM Data Breach Report, 12 % increase in security events year-to-year [4]. Top 10 web application risks remain same in the past few years [1]. Approx. 60 % of attacks are because of vulnerable application code [5].

Most common approaches used to manage web application attacks are defensive coding, hardening (filtering), static/dynamic code analysis or black box testing. Solutions based application adversely affect cost and developer’s efforts [6]. Testing is used for building secure applications. The major problem with testing is that it requires code and web server access [6].

The authors have proposed a security Model to mitigate security risks. Our focus is to develop Model which can be used for web application database health check and act as a utility. Model which neither require developer skills nor code.

The remainder of the paper is formed as follows: Sect. 2 explains the importance of Web application Security and SQL Injection attempts. Section 3 discuss the problem statement (issues), Sect. 4 describe the proposed model, examining results and comparison is provided in Sects. 5 and 6 respectively. The conclusion is provided in Sect. 7.

2 Literature Survey

Injection attack is one of the top three attacks since 2010 [1, 7–15]. SQL Injection and Blind SQL Injection are key attacks under Injection attacks. Most commonly SQL Injection attacks are executed from application using user inputs or URLs [5, 9, 10]. The key impacts of SQLI attacks are data loss, application downtime, brand damage, and customer turnover [7, 11, 16, 17]. Blind SQL Injection attacks are used to List database information and dump data [1]. Both attack use Structure query language for execution of attacks.

Most common approaches used to manage SQLI attacks are defensive coding, hardening (filtering), static/dynamic code analysis, Intrusion detection system and black box testing [8, 6].

Web application communities have developed various approaches for detection and prevention of SQLI [11, 16–19]. Observations of various techniques (existing and proposed) are summarized in Table 1 with reference to efforts, resource requirements (Code and web server) [6, 16, 17, 20–27].

Table 1 Comparison of web application attack solution categories
Full size table

It is observed that most of the solutions require Developer Skills, developer efforts and web server/code access (refer to Table 1).

Gap: A systematic, dynamic and effective solution is required to detect and prevent SQLI [20, 21].

3 Problem Statement

The authors have found that model with following functionalities is required.

  1. (1)

    Any beginner can run model i.e. no or little technical knowledge is required to execute the model [6, 17, 20–22].

  2. (2)

    Model work as remote penetration testing i.e. access for source code is not required [6, 17, 20–22].

  3. (3)

    Web server access is not required i.e. model can be executed from remote PC without installing it on server [6, 17, 20–22].

  4. (4)

    Model can work as utility [6, 17, 20–22].

4 Proposed Model: Model for Remote Database Health Check

In this research paper, the authors have proposed a novice approach for performing remote database health check (web vulnerability checks).

4.1 Objectives of Model

The objectives of model are to develop model which can work as a utility with minimum technical skills, companies of any size can perform investigations, developers can develop highly secure web applications and organizations can mitigate with web vulnerabilities.

4.2 Overview

Prototype model is developed using python and will focus on top 2 vulnerabilities (SQL Injection and Blind SQL attacks). Model diagram is described in Fig. 1.

Fig. 1
figure 1

Remote database health check model diagram

Full size image

Following subsections describe each phase of the proposed model.

  1. (i)

    Analyse Web Application This step will verify the existence of user entered web application host name.

  2. (ii)

    Information Gathering This step describes the process of investigating, examining and analyzing the target website in order to gather information. System Information (like Operating system name, Version etc.), Database Information (like Database Name, Version, table/column Names etc.) and Links (like number of static links, database links mailing and other links) are gathered.

  3. (iii)

    Vulnerability Assessment In this step model will check the vulnerability of web application using data gathered and rule database (payloads) for SQLI and Blind SQL Injection attacks turn by turn. This task is divided into two sub tasks. First, attacks are build using payload i.e. create injection strings using payloads. Then using identified entry points, it will execute attacks. During vulnerability check, Model will check for all types (attack vectors) of attacks. The model is using payload database. Various payloads are used for building and exploiting attacks like Login, Table and column names, attack payload, rule and words. These payloads provide scalability for any new attacks which may found in future.

The authors have prepared a prototype for implementing and testing this model.

5 Testing

5.1 Testing Environment

Figure 2 shows the test environment created for proposed model testing.

Fig. 2
figure 2

Test environment

Full size image

Two virtual machines named VICTIM and HACKER are created on testing machine. PHPEchoCMS web application is deployed on VICTIM machine and proposed model is installed on HACKER Machine. For testing HACKER machine is used.

5.2 Test Scenarios

For proof of concept verification, three test scenarios were considered.

  1. (A)

    Test Scenarios 1 PHPEchoCMS

    A Deliberately vulnerable web site is created for testing model using PHPEcho CMS. The first test scenario ran with PHPEchoCMS, a deliberately insecure J2EE web application developed. The purpose of this test campaign to verify and test the proposed model.

  2. (B)

    Test Scenario 2

    Custom web applications (developed and hosted on local host). The web site is developed using PHP and database as MySQL. The authors considered two types of websites (static and dynamic) under this scenario.

  3. (C)

    Test Scenario 3

    Purpose of this scenario is to execute unit testing of developed screen. Under this category one single login page is developed and testing is performed.

6 Results

6.1 Results

Testing results of above scenarios are summarized in Table 2.

Table 2 Testing results—vulnerability assessment
Full size table

6.2 Performance

Table 3 summarize performance data of all testing scenarios. Performance data shows that proposed model is quick in assessment.

Table 3 Testing results—performance
Full size table

6.3 Comparison

Four parameters used for comparison are Vulnerability coverage (SQLI and Blind SQL), Feature (is solution GUI based), Developer Skill required and developer efforts required. The comparison between proposed model and top 10 open source tools is presented in Table 4.

Table 4 Comparison—top 10 open source solutions
Full size table

It is found that

  • Only eight out of top ten open source solution provide vulnerability assessment for SQLI and Blind SQL Injection, while proposed model can do for both.

  • Six out of top ten open source model do not provide Graphical interface, while proposed model is menu driven

  • Due to command line interface, technical knowledge is required in most of the open source solution. While proposed model does not require developer efforts for execution.

6.4 Comparison of Proposed Model with Top 3 Vulnerability Scanners

Table 5 describes comparison between proposed mode and top 3 vulnerability scanners.

Table 5 Comparison—top 3 vulnerability scanners
Full size table

Table 6 represents resource requirement comparison between Net Sparker and proposed model.

Table 6 Comparison—resource requirement
Full size table

From Tables 5 and 6, we can conclude that proposed model can works with little resource i.e. works as a utility. It do not require developer efforts, skills and configuration. It is easy to use.

7 Conclusion and Future Work

Some investigation challenges for web vulnerabilities are exemplified in the proposed model. It provides bases for utility. The model emphasizes on the requirements of changes needed in Vulnerability risk mitigation using a light weight utility. To address challenges of multi tenancy of web application, Authors have proposed a logging mechanism, which can be useful to address known as well as unknown threats.

One of the key characteristic of Model is that it does not try to obtain sensitive data. However, it extracts weaknesses to prepare attacks and evaluate web application for vulnerability. The attack results are collected which can be used for further analysis and code fix. As mentioned Model neither need code nor server access to determine. Authors can run from any PC by giving an URL to the health check.

Authors can conclude that they have successfully tested web applications using proof of concept. The performance found was excellent. Model correctly identified vulnerability in web applications.