SQL Injection Attacks and Vulnerability Detection

TABLE OF CONTENTS

1.0 Introduction

2.0 SQL Injection Vulnerability Detection

3.0 SQL Injection Attacks

4.0 Experimental Set-Up

5.0 Conclusion

6.0 References

1.0 Introduction

Breaches in security occur as a result of the exploitation of vulnerabilities within applications. Thus, the identification of vulnerabilities and assurance of security functionality is an extensively implemented methodology used to assess and progress the security of software applications [1]. Databases are widely employed within modern day software applications. However, development environments are restricted in their understanding of concurrent database and application interactions. This exposes a myriad of security, accuracy and functionality concerns which remain latent throughout application development [2]. Structured Query Language (SQL) is a commonly deployed high-level query language utilized for the updating and querying of relational Database Management Systems (DBMS). Developed in the 1970’s SQL, is a declarative language, encompassing features such as expression, clauses, statements, queries, and predicates. SQL permits the user the capacity to insert, update, query and delete database stored data [3].

Vulnerabilities encapsulates any error, loophole, bug, flaw or weakness residing within a software application, that holds the prospective for exploitation by a malicious entity in order to ascertain the unauthorized access to either application and/or the application data. SQL injection vulnerabilities are generated by the inability of a software application to authorize and sanitize user provided data which originates from an untrusted source. Consequently, the data is used to construct malevolent SQL query statements, which are subsequently executed on the underlying application database [4].  SQL injection vulnerabilities can occur across any software application platform. However, the exploitation of SQL injection vulnerabilities is predominantly conducted by an attacker upon web application frameworks.

1.1 Web Application Architecture

Web-based applications are a multi-tiered deployment. Collectively web applications share one crucial characteristic, their interactive database-driven nature. Web applications are comprised of either software programs or web-pages that are retained within a web-server. User provided input is transmitted to the web-server in the form of a parameter statement. Each provided input is used to propagate an SQL query statement, which retrieves the specified information from the database. Authorized users are able to interact with the database over the Internet. A web-browser interface supports the interaction between web application and database as a mechanism of retrieving data as specified within the user input provided.  Each web application construction supports a three-tier architecture, in which, the operation of each tier is independent of both the machine running it and the remaining two tiers. The three-tiers within a web application architecture are [5];

Presentation Tier contains and generates the applications presentation logic. The presentation tier is the highest tier within an application and is responsible for the handling of user interaction; obtaining user provided input and delivering the conforming user comprehensible results.

Business Tier is the middle tier of an application architecture and resides between the presentation and database tiers. The business tier is a rule based logical layer, that is accountable for the comprehension of and processing of data between each tier. The business tier executes application procedural commands, which extract and transmit data to the presentation tier for user comprehension.

Database Tier is the physical database of the web application that stores all data. The database tier restricts access to the database, permitting authorized users and refusing malicious users. Stored data is housed, retrieved and transmitted via the database tier. Requested information is transmitted to the presentation tier via the business tier, for handling and subsequent user interaction.

2.0 SQL Injection Vulnerability Detection

An SQL injection vulnerability refers to an SQL query or subsection of SQL statements that are susceptible to exploitation. With regards to web applications, exposure to vulnerability exploitation is inherent given their publicly accessible nature. Web application security can be assessed through either analysis or penetration testing.

2.1 Analysis Methodologies

Vulnerability detection mechanisms establish the manifestation of exploitation vectors within an SQL query or application. Detection mechanisms endeavor to pinpoint the precise location of the vulnerability. Vulnerability examination frequently occurs offline; however, research has indicated the requirement for run-time analysis methodologies. Upon the discovery of an application vulnerability, source code modification must occur to eliminate the vulnerability [6].  The overall threat and consequences that the exploitation of an SQL injection vulnerability ensues that the detection of such vulnerabilities is paramount in enhancing the safety of web applications. Vulnerability detection methodologies can be classified as either static or dynamic analysis or a permutation of both.

Vulnerability Detection Methodology	Classification of Vulnerability Methodology
Static Analysis	White-box Testing
Dynamic Analysis	Black-box Testing
Static and Dynamic Analysis	Grey-box Testing

Table 1: Classification of Vulnerability Detection Methodologies

Static Analysis

Static code analysis is concerned with the identification of application vulnerabilities residing within the application source code. Static analysis is conducted with the assistance of automated static analysis tools. Automated static analysis tool function by analyzing and probing the application source code, endeavoring to pinpoint the location of concerns inclusive of, stylistic and semantic errors, security weaknesses, bugs, type checking and overall program comprehension [7]. With reference to SQL injection vulnerabilities, static analysis tools operation on the notion of preventing an attack rather than identifying an attack after it has transpired. Thus, static analysis tools parse SQL query statements, and user provided input, presented within a web application to isolate probable injection vectors as a means of preventing SQLIAs. However, a user entered SQL query that retains the correct syntactical and sematic structure, will execute irrespective of prevention mechanisms [8]. Static analysis is not restricted to the development and de-bugging phases, rather it can also be implemented as a mechanism for the protection of established applications. Though static analysis is a viable option in the detection of SQL injection vulnerabilities, it does not come without its limitations. Static analysis when implemented is solely operational prior to run time execution. As a result, vulnerabilities that occur during run-time are not identifiable by static analysis tools. Furthermore, static analysis often over detects the rate of vulnerabilities within application source code, resulting in the over reporting of false positives.

Dynamic Analysis

Dynamic analysis examines an application framework throughout run-time, to locate vulnerabilities that may transpire. Dynamic analysis occurs upon a deployed application; thus, the reporting rate of false positives is reduced. However, the deployment of dynamic analysis raises concerns regarding the reporting of false negative. Input data is introduced to the application one subsection at a time, thus, vulnerable execution paths may not be examined [9].

Static and Dynamic Analysis

A hybrid approach combines both static and dynamic analysis as a methodology to enhance the strengths and mitigate the limitations of each methodology. The preceding detection mechanisms are evident in their capabilities of identifying potential exploitation vectors. However, the application of a hybrid approach, enhances the detection of prospective SQL injection vectors form the initiation through to the distribution of an application.

2.2 Penetration Testing

There is no one single definition of penetration testing. However, it can be regarded as the lawful attempt to identify and exploit web and/or software applications with the intention of enhancing security [10]. It encapsulates the deployment of malevolent attack techniques that emulate those employed by an adversary. Penetration testing is considered an integral instrument in ensuring application security. Penetration testing is deployed as a mechanism to identify gaps within application security, which are subsequently exploited in order to obtain sensitive information [11]. Penetration testing is categorized in three distinct type; white-box testing, black-box-testing and grey-box testing, based upon information concerning the targeted application.

White-Box Testing is a comprehensive testing mechanism, where testers are provided with complete information regarding the target application. White-box penetration testing is valuable in the deployment of targeted tests aimed at revealing all vulnerabilities and attack vectors that are feasibly identifiable. Given access to the application source code, white-box testing, similar to static analysis, is capable of identifying design, semantic and syntax errors [11].

Black-Box Testing provides testers with no information regarding the application. Black-box penetration testing is employed as a mechanism to comprehend exploitations that an adversary is capable of achieving [11].

Grey-Box Testing attempts to apprehend the degree of access that an authorized application user may acquire at any given time [11].

Penetration testing can be applied in two distinctive approaches, manual or automated. Manual penetration testing requires the presence of a highly skilled team to oversee testing for the duration of the project. Individual exploitations must be handcrafted and applied via human interaction. Thus, manual penetration testing is no a viable option. Its complex and slow nature ensures that manual penetration testing is not an affordable option. Conversely, automated penetration testing is an efficient, uncomplex and secure alternative to manual penetration testing. Given that all processes are automated through the use of specialized tools, time and affordability concerns are diminished. Further distinctions between manual and automated penetration testing approaches are outlined in the tables below [12];

	Manal Penetration Testing	Automated Penetration Testing
Testing Process	Labor-intensive, erratic and fault prone with no explicit requirements.   Result disparities between tests. Operation and interpretation of testing requires highly skilled and paid teams.	Fast, efficient and secure.   Removes human-driven faults and labor-intensive manual tasks. Standardized procedure ensures consistent and reproducible results. Comprehension of tools is easy, with minimal training required for their operation. Actionable reports are generated in human-readable output.
Network Modification	Results in an abundance of system specific modifications.	System often does not require any modification and remains unaffected.
Exploit Development and Management	Creation and preservation of exploitation database is an expertise require time intensive task.	Tool developer creates and preserves and updates all exploitation tests.   Exploitation tests are developed by industry professionals with continued assurance regarding their effectiveness and security. Exploits are developed for operation on a variety of attack vectors and application platforms.
Clean Up	Team must ensure the removal of all adaptations and developed backdoors.	Clean-up is an automated process and backdoors into the application are never developed.
Reporting	Hand produced, requiring substantial effort towards the gathering and organization of results.	Automatic generation of customizable reports.
Logging and Auditing	Time-intensive and often inaccurate.	Automatic logging of activities.
Training	Difficult and cumbersome, no standardized training parameters.	Limited training and comprehension required to perform testing.

Table 2: Comparison of Manual and Automated Penetration Testing.

Neither manual or automated penetration testing is exhaustive in identifying all vulnerabilities within web applications. Each approach can be used for the identification of vulnerabilities residing within web applications. Manual and automated approaches both have their own strength and weaknesses.  Automated tools were never designed with the intention of replacing manual penetration testing. Rather, the correct application of automated penetration testing tools, are capable of identifying a wide range of vulnerabilities, saving labor-time and money when compared to manual penetration testing. Thus, the implementation of both manual and automated penetration testing methodologies should be considered in order to obtain the greatest coverage to the identification of vulnerabilities within web-based applications [13].

Penetration testing facilitates testers in viewing an application through an attacker’s perspective. Penetration testing can bring to light serious vulnerabilities, which may be remediated prior to an adversary’s exploitation attempts. Moreover, penetration testing enables the confirmation of either the applications effectiveness or ineffectiveness of implemented preventative security measures, by explicitly attempting to exploit potential security vulnerabilities. Penetration testing provides the capability of raising security concerns within a tested application, subsequently raising overall awareness towards application security. Despite its evident advantages, there are also several disadvantages of penetration testing that cannot be overlooked.  Penetration testing has the capability to cause adverse effects within the application, including but not limited to the disclosure of sensitive information and DoS attacks. Furthermore, the state of an application prior to testing versus the state of an application during testing may differentiate. Thus, new exploitation vulnerabilities may be introduced into the application [11].

3.0 SQL Injection Attacks

According to the Open Web Application Security Project (OWASP), injection attacks are the most critical risk threatening the security of web-based applications. Injection attacks categorize and encapsulate diverse manifestations. However, the underlying construction and objective of each remains constant. Injection attacks eventuate from the traversal of untrusted data to an interpreter as a subsection of either a command or query.  The untrusted data can manipulate an interpreter into executing malicious commands or permitting access to confidential data [14].

Consequently, SQL injection attacks (SQLIAs) are formidable in exploiting the vulnerabilities of database driven web applications. SQL Injection Attack are a subcategory of injection attacks. SQLIAs occur when hardcoded SQL strings are affixed with user provided input to generate dynamic queries, for execution on the underlying application database. If appropriate methods are not taken to validate and sanitize the user provided input, an attack vector is established. The adaptation of previously safe SQL input by an attacker can result in unauthorized access and unauthorized control of the application database [15]. The successful implementation of SQL injection attack can manifest detrimental consequences upon the underlying application database. Moreover, an effective execution of an SQL injection attack, warrants the reading of sensitive data, along with its modification and administrative operations. Thus, the principal consequences of SQLIAs are [16];

Confidentiality Damage to database confidentiality is a significant issue caused by SQLIA. Databases house confidential and sensitive information regarding both application and potential client information. Thus, as a consequence, the successful application of SQLIAs by a malicious entity, may lead to the unauthorized obtainment of such information, thus, compromising the confidentiality of the entire application.

Integrity external SQLIAs permit support a malicious entity in the modification or manipulation of database held information.

Authentication inadequately structure SQL queries result in the insufficient validation of user input in the form of usernames and passwords. This enables an unauthorized attacker to connect to a database via an authenticated user’s credentials, without prior knowledge of the user’s application login credentials.

Authorization the successful exploitation of an SQL injection vulnerability, enables a malicious entity to manipulate information, and elevate application privileges provided authorization information is contained within the exploited database.

Functionality parallel processing is archetypical of a database, permitting concurrent user access, data sharing and updating. An SQLIA may potentially either partially or entirely corrupt the functionality of a database.

A malicious attacker will often endeavor to exploit an attack vector which is both low in complexity, but high in severity. SQLIA are a pertinent example of this type of exploitation. SQL injection attacks are often difficult to identify. Individual sub-processes of an attack, when analyzed independently of any other sub-process are often determined to be legitimate. Thus, string analysis is a frequently implemented mechanism used to determine the complexity of an attack. In the instance of SQLIAs a higher complexity level is considered provided that at least one of three characteristics is present within the attack string composition [17];

1. Encoded single quotes
2. Encoded double quotes
3. Comment specifiers interrupting a keyword

If none of these specified characteristics are present than the SQLIA is determined to be a simple, low complexity attack. Research has indicated that the overall complexity of SQLIAs has not increased. However, the magnitude to which application development and expansion has surged, the exploitation vectors of SQL injection vulnerabilities has increased exponentially. The absence of user provided input authentication has triggered this growth. Ignorance and lack of developer understanding surrounding the insufficient validation of user provided input, ensues the implementation of insufficient countermeasures to thwart SQLIAs [18].

3.1 SQL Injection Mechanisms and Intent

The incorrect handling and sanitization of user-provided input can manifest detrimental security concerns for web-based applications. SQL queries are dynamically generated through low-level unstructured string manipulation.  This is considered unstructured as, databases deduce query strings to be structured and meaningful commands, whilst applications interpret query strings as a sequence of unregulated characters. Thus, the improper handling of user-provided input in conjunction with the sematic gap of SQL queries develops a significant basis for SQLIAs to occur [19]. The execution of SQLIAs occur as a result of the manifestation of two imperative characteristics, the selected injection mechanism and the attacker’s intent [20].

3.1.1 SQL Injection Mechanisms

Injection Through User Input

Injection attacks through user input transpire as a result of the malicious scripture of SQL statements being introduced into web applications. The adaptability of web application ensues that user provided input is capable of being read across numerous deployment environments. Commonly, SQLIAs upon web applications target and intend to infiltrate submission requests that are sent to the application via HTTP [20].

Injection Through Cookies

Cookies a minor file stored on a client’s web-browser, that houses state information produced by individual web applications. The return of a client to a web application will prompt the stored cookie to reload the state information. The storage of cookies is controlled by the client. Thus, a malevolent client retains the ability to manipulate the contents of a cookie to embed an attack into the predefined SQL statements [20].

Injection Through Server Variables

Server variables are a collection of variable instances that contain information such as HTTP, environmental variables and network headers. Web-based applications utilize server variables in numerous ways including, the identification of user browsing trends and the logging of usage statistics. If these variables are stored within the database without sanitization an attack vector is created in which the exploitation of SQLIA may occur. A malicious entity is capable of falsifying values that are place in both the network headers and HTTP. SQLIAs can occur as a result of a malicious entity placing these falsified values directly into these headers. Thus, when a query is issued to the database, the fabricated header triggers the SQLIA [20].

Second-Order Injection

Within a second-order injection a malicious entity positions malevolent inputs into a database to indirectly generate a SQLIA when the user defined input is executed at a later time. Second-order injection attacks do not aim to exploit a vulnerability when the malicious input initially enters the database. Rather, they are implemented as an attack that relies on the subsequent execution of the input once the input is called upon for execution. Given that the location of initial injection differentiates from the location of manifestation, the detection of second-order injection attacks is fleeting. Countermeasures implemented to sanitize, escape, filter and type-check user provided input may produce a safe result. However, the execution of this data at a later stage within a differing context and environment will often result in an SQLIA [20].

3.1.2 SQL Injection Intent

An SQL injection attack can be characterized based upon the intent of the malicious entity carrying out the attack. The goal and intent of the attack will differentiate drastically depending on the attacker, with intent unrestricted to one single objective [20].

SQL Injection Attack Intent Type	Intent Type Description
Identifying Injectable Parameters	A malicious entity, analyses a web application to uncover vulnerable user provided input fields and parameters capable of exploitation using an SQLIA.
Performing Database Finger-Printing	A malicious entity attempts to uncover both the type and version of the back-end database being used by a web application. Differing back-end databases respond to alternative malevolent attack methodologies and query structure. The information procured using database fingerprinting can assist an attacker in generating database specific SQL injection attacks.
Determining Database Schema	Procuring database schema information assists an attack in the accurate extraction of stored data. Thus, the knowledge of table and column names along with column data types abets both the extraction and injection of data.
Extracting Data	The extraction of data is the most commonly deployed methodology of SQLIA and will differentiate vastly depending on the nature of web application being exploited. The obtained data may be sensitive and highly sought after by the malicious entity.
Adding or Modifying Data	The intent of this attack is to inject or manipulate data housed within the database.
Performing Denial of Service	The intent of this attack is to shut down the operation of the web application database, in turn, denying the service of the web application to all legitimate users.
Evading Detection	Evading detection is a methodology employed by an attacker to elude detection by system implemented safeguard mechanisms.
Bypassing Authentication	An attacker will strive to evade detection by bypassing all application and database detection mechanisms implemented, permitting an attack to escalate their execution privileges.
Execute Remote Commands	The attempt to execute arbitrary commands upon the database, which may be encapsulated in either stored procedures or presently available database functions.
Execute Privilege Escalation	Exploit the implemented or logical errors within the database, as a means to escalate an attacker’s user privileges.

Table 3: SQL Injection Attack Intentions.

3.2 SQL Injection Attack Classification and Methodologies

The sheer number of SQLIA methodologies ensues that the execution of SQLIAs is indistinctive. Pertinence is placed on the intentions of the attacker to propel the attack, with implementation occurring rarely in isolation but rather incrementally or sequentially [20].

3.2.1 SQL Manipulation

SQL manipulation attacks encompass any attack that modifies the WHERE clause of an SQL query, in order to produce a differing result. SQL manipulation attacks are the simplest form of SQLIA and are commonly implemented by novice entities. The implementation of an SQLIA through the use of the SQL manipulation methodology also embodies any attack mechanism that modifies other set operators including INTERSECT and UNION [21].

Tautologies

Tautology-based attacks are used as a methodology to bypass authentication parameters and extract unauthorized data. Malicious SQL queries are inserted into one or more conditional statements to guarantee they are appraised to always be true. Tautology-based attacks revolve around the exploitation of an SQL queries WHERE condition. The transformation of a condition into a tautology exposes all targeted rows within the database. In order for a tautology-based attack to arise, consideration must be made regarding both the injectable parameters and coding constructs of the database. A tautology-based attack is considered successful if one or more targeted records is returned [20].

Union query

Within SQL the UNION operator is enlisted as a mechanism to join two independent queries together. A union query attack transpires when a malicious entity injects a malignant query into a safe query, as a method of extracting information stored within the application database. An attacker holds complete control over the second injected SQL query. Thus, forcing an application database to return data that was not predefined within the initial legitimate query. The resulting dataset from a union query attack is the union of the initial legitimate query, and the second injected query [20].

Piggy-Backed Queries

The attacker utilizes the delimitator ‘;’ in an attempt to insert numerous malicious queries into the initial defined query. Piggy-backed query attacks are incomparable to other SQLIA methodologies, in that, a malicious entity is not attempting to manipulate the initial query, but rather, include new queries which are subsequently executed along with the first query. Piggy-backed query attacks can be detrimental to an application database. They can permit an attacker to insert any SQL query, inclusive of stored procedures. Vulnerability to such an attack is determined by the configuration held by the database, more specifically if numerous SQL statements can be inserted and executed within a single string [20].

Inference

Inference attack occur as a result of a malicious entity injecting modified SQL quires as a mechanism to manipulate the behaviour of a database. The modified SQL query will result in an action response corresponding to either true or false values related to the data in question. This SQLIA methodology is commonly undertaken when a database has been hardened enough that is does not respond with error messages containing exploitable feedback. Thus, the execution of such an attack will supply a malicious entity with information regarding the changes to the functionality and the response of a web application. Careful investigation of these changes will provide an attacker with the ability to deduce vulnerable parameters and further information regarding data values held within the database. There are two well documented instances of inference attacks, which support the extraction of data and the detection of vulnerable parameters [20] [22].

Blind Injection database information is inferred from the applications behaviour in response to a question set containing only true or false questions. If the injected statement evaluates to a response of true than the application operates as normal. If the injected statement evaluates to false then the application produces a significantly different page to that or normal functioning, regardless of no presentation of a descriptive error message.

Timing Attacks allow a malicious entity to obtain information regarding the database by observing database response delay times. Though similar to a blind injection attack, timing attack utilize a different form of inference. Malicious SQL queries are constructed using if/then statements in conjunction with the WAITFOR parameter. The application of both the statements and parameters within one of the branches forces the database to withhold execution and adhere to a predefined response time.

3.1.2 Code Injection

A code injection depicts the corruption of a system vulnerability that is triggered by the handling of un-sanitized and invalid data. A code injection is used by a malicious entity as a mechanism to introduce malevolent code to adapt the process of execution. The consequences of a code injection can be detrimental to an application. SQL code injection operate by affixing new malignant database commands or SQL statements, to pre-identified vulnerable statements [21].

3.1.3 Function Call Injection

A function call injection operates through the insertion of malicious database function calls into susceptible SQL statements. Function call injections facilitates an attacker through the manipulation of stored data or executing operating system commands [21].

Stored Procedures

Predefined stored procedures are commonplace within the deployment of a new database, supporting the extension of both operating system interaction and overall functionality. The determination of the preset stored procedures by a malicious entity is detrimental both to the database and the operating system. The execution of predefined stored procedures will escalate a malicious entities privileges, allowing the execution of commands upon the operating system. Though stored procedures provide a vulnerable basis for the exploitations of SQLIAs, they can however, be pertinent in the prevention of SQLIAs if implemented correctly. Stored procedures are capable of limiting the parameters of SQL statements that can be executed. The restriction of SQL statement parameters cannot single handedly prevent the application of SQLIAs, as methodologies have been developed to bypass such parameters [20] [23].

3.1.4 Buffer Overflows

A buffer overflow is an irregularity wherein an application whilst writing data to a buffer, overwrites the buffer limitations and overruns into the adjoining memory. Buffer overflows are ordinarily initiated by user provided input that aims to execute arbitrary code or modify application operation. Consequently, applications execute unpredictable actions. Thus, buffer overflows provide a basis for considerable application vulnerabilities, and exploitations. Buffer overflows are implemented to corrupt the execution stack of an applications [21].

3.1.5 Alternative SQL Injection Methodologies

SQL injection attacks propose a myriad of different exploitation practices and potential attack vectors. The proceeding methodologies are commonly implemented SQLIA methodologies, irrespective of their failure to be categorized into an attack schema. However, these methodologies are still pertinent in their execution of malicious SQL code, and thus, are still viable options for SQLIAs.

Illegal/Logically Incorrect Queries

Preliminary support is provided for a malicious entity in obtaining critical information pertinent to the construction and semantics of back-end application databases. Illegal or logically incorrect query attacks are typically a precursor to other SQLIA methodologies. The mechanisms of this attack functions through the insertion of improper or incorrect SQL statements into the web application, forcing the return of a default error page. The default error page is frequently overly descriptive, exposing critical information that may be leveraged by an attacker to perform further attacks on the database with greater consequences. The execution of this attack usually occurs through the injection or malformed SQL queries that produced either syntax, logical or type conversion errors. Syntax errors are capable of exposing subsequent injectable parameters. Logical errors often reveal column and table names within the database, whilst type errors can assist an attacker in the extraction of data or deduction of column data type [20] [23].

Alternate Encodings

SQL queries are manipulated using alternative encodings such as ASCII, hexadecimal or Unicode, in an attempt to prevent detection from defensive coding practices. Alternate encoding is often employed in conjunction with other SQLIA methodologies. Unlike other approaches alternate encoding is not an attack mechanism, but rather, a mechanism that facilitates an attack by preventing the detection of malicious queries and exploiting vulnerabilities that may not have previously been exploitable. Commonly applied detection and scanning techniques do not account for adapted encoding, thus, permitting malicious string to enter undetected. There is no feasible defensive mechanism that can be implemented to prevent alternate encoding attacks. The ability to ensure that all possible alternative encodings for a single string have been identified is unrealistic. Thus, the deployment of alternate encoding on top of malicious strings has been successful in generating a new attack vector in which different SQL injection attack methodologies can be deployed [20].

4.0 Experimental Set-Up

The proceeding experimental set-up consists of two SQL exploitation examples. Each example consists of its own distinct approach. The initial experiment highlights the capabilities of manual penetration testing. More specifically its ability to extract critical information stored within an application database, through the use of un-sanitized and invalidated SQL queries. The second experiment indicated the capabilities of an automated SQL injection exploitation. Conducted using an automated tool on a notably larger application base, sensitive information was once again extracted and consequently utilized to obtain access to the application via another application user’s credentials.

4.1 Manual SQL injection exploit

Hackable

Hackable is a Python flask application, that is purposefully susceptible to both SQL injection and Cross Site Scripting (XSS) attacks. The Hackable application platform is vulnerable to SQL injection attacks at two distinct locations. The login page is vulnerable to SQL injections, permitting the easy traversal and bypassing of login. Further, the search page is vulnerable to SQL injection attacks, enabling the simple extraction of confidential data stored within the web application database [24].

A manual penetration testing approach was adhered to utilizing invalidated and un-sanitized user input queries. Each SQL statement was implemented using the UNION query operator. This enable the exploitation of SQL vulnerabilities within the Hackable web application framework. The insertion of a malevolent SQL query statements, forced the application database to return sensitive information that was not predefined within the initial legitimate SQL query. The output resulted in an amalgamation of the initial legitimate query and the second injected query. In the presented example, the initial query is the juice table, whilst the injected query is dependent on the sought-after data. The proceeding SQL queries were executed on the search page of the Hackable web application;

Hackable Manual Exploit 1

The sqlite_master is the default residing with the SQLite application database. The sqlite_master table houses data regarding each table with the database.  The first command examines whether the database itself is vulnerable and responsive to SQL injection exploits.

juice’ UNION SELECT 1,2,3 from sqlite_master WHERE type=”table”; —

Image 1: Return of Juice Table with Injected Values

The above image depicts the output and returned values of the first command when executed in the search page of the Hackable web application. It is evident that the application database is vulnerable to SQL exploitations, returning the juice table merged with the injected query. In this instance the union of the juice table and the inserted data values 1,2,3.

Hackable Manual Exploit 2

The second command returns the names of all tables that are extracted from the master table. Name and SQL are columns within the sqlite_master table. Name returns the name of the table, whilst SQL returns the column names and data type of each column within the table.

juice’ UNION SELECT name,sql,3 from sqlite_master WHERE type=”table”; —

Image 2: Return of Juice Table with Extracted Table Names, Data and Data Types

The execution of the second command, upon the Hackable application platform returns data pertaining to the name of both tables and columns within the specified tables, along with the data type of each column.

Hackable Manual Exploit 3

The final command acquires data concerning the first two specified columns username and password, from the employees table and proceeds to generate a third column.

juice’ UNION SELECT username,password,3 from employees; —

Image 3: Return of Juice Table with Extracted Usernames and Passwords

The execution of the final command returns both the username and password of each user within the master table. Moreover, the commands prompt the generation of a third in this instance price, which is prefilled with the defined value of three unless an alternative value is otherwise present within the database.

4.2 Automated SQL Injection Exploit

SQLMAP

Sqlmap is an open source python scripted automatic penetration testing tool. Sqlmap automates the procedure of identifying and exploiting SQL injection vulnerabilities and enables the overtaking of database servers. In addition to the mapping and identification of SQL injection vulnerabilities, sqlmap permits access to the database, more specifically the modification and deletion of data, along with the unauthorized access to confidential and sensitive information residing within the target database [25].

Damn Vulnerable Web Application

DVWA is an open source PHP/MySQL web-based application that is vulnerable to numerous exploitation attacks. DVWA was designed as an application framework to support the development of security specialist’s skills, and comprehension of application security measures with a legal environment. DVWA supports such development through the implementation of increasing security levels, which can be progressively increased [26].

4.2.1 DVWA Automated Exploitation with SQLMAP

DVWA supports the testing of both manual and automated SQL injection attacks. The following example of an SQL injection exploitation will be automated, with the assistance of the automated penetration testing tool sqlmap.

DVWA utilizes a PHP session cookie for the authentication of users. If the presented session cookie is not valid, then user attempting to obtain access to the application will be re-directed to the login page. However, this countermeasure prevents sqlmap from obtaining access to the exploitation location within the application. Thus, the session cookie is required for each exploitation phase. In this instance the session cookie was obtain by logging in to the DVWA and running the Mozilla Firefox add-on Tamper Data. Tamper Data enables users to view and manipulate both HTTP and HTTPS headers and web-page post parameters. Tamper Data when operating functions as an interception location between a web browser and data exchanged from a web application. Requests are sent via the Tamper Data add-on providing users with two options, submit the data as normal or cancel the request [27]. Within the proceeding example, Tamper Data was used as a mechanism to obtain the correct PHP session cookie to ensure granted access for sqlmap.

DVWA Information Gathering

In order to conducted meaningful exploitations of SQL injection vulnerabilities within the DVWA general information regarding the database must first be identified. The proceeding command was executed utilizing sqlmap to obtain meaningful information about the DVWA underlying database;

sqlmap -u http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit# –cookie=”PHPSESSID=mdbj31fk9vs455vupovi9pt5mp;security=low” –dbs

Where;

• -u specifies the host IP address and path to the vulnerable web page.
• –cookie specifies the cookie data for the login this will change for each subsequent session.
• –dbs returns the applications databases.

The execution of the previous command indicated four injection vulnerabilities located within the stored session of the DVWA. Each of these vulnerabilities occurred as a consequences of the id (GET) parameter. The GET method is a common HTTP parameter, which is enlisted as a mechanism to request data from a specified source. Moreover, the GET method accepts the dynamic generation of user provided input data. When compared to other HTTP methods GET is considered to be significantly less secure as information is transmitted as a subsection of the URL. Thus, the GET method should never be enlisted when transmitting confidential information or passwords. The four identified injection points within the id (GET) parameter were identified as;

• Boolean-Based Blind Injection Attack
• Error Based SQL Injection Attack
• AND/OR Time-Based Blind Injection Attack
• Union Query Injection Attack

Image 4: Return of Database Vulnerabilities

Image 5: Return of Application Databases

Returning Database Tables

In order to obtain information regarding the database tables of an individual database a decision must first be made about the target database. In this instance the dvwa database was selected. The following command was executed using sqlmap to return all tables residing within the dvwa database;

sqlmap -u http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit# –cookie=”PHPSESSID=mdbj31fk9vs455vupovi9pt5mp;security=low” -D dvwa –tables

Where;

• -u specifies the host IP address and path to the vulnerable web page.
• –cookie specifies the cookie data for the web page this will change for each subsequent session.
• -D specifies the selected database for examination.
• –tables enumerates the specified database tables.

The execution of the above command returns all tables housed within the dvwa database, in this instance the guestbook and users tables.

Image 6: Return of all Tables within the DVWA Database  

Returning Columns of Selected Database Tables

The identification of database tables permits further exploration of the returned tables, in particular, the users table. The identification of the tables columns names can expand the attack basis upon which potential exploitations may occur. The column names of the users table within the dvwa database were identified through the execution of the following command;

sqlmap -u http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit# –cookie=”PHPSESSID=mdbj31fk9vs455vupovi9pt5mp;security=low” -D dvwa -T users –columns

Where;

• -u specifies the host IP address and path to the vulnerable web page.
• –cookie specifies the cookie data for the web page this will change for each subsequent session.
• -D specifies the selected database for examination.
• -T identifies the selected table for examination.
• –columns enumerates the specified tables columns.

Image 7: Return of all Columns in the Users Table of DVWA Database

The output of the above command produced all columns residing within the users tables of the dvwa database. As depicted in the image above, two columns are present, with each row representing an individual set of data and its corresponding data type.

Returning Data of Identified Columns

The information presented during the identification of columns for the users tables provided an overview of critical information. In order to obtain access to this information the following command was executed;

sqlmap -u http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit# –cookie=”PHPSESSID=mdbj31fk9vs455vupovi9pt5mp;security=low” -D dvwa -T users -C user,password,first_name,last_name –dump

Where;

• -u specifies the host IP address and path to the vulnerable web page.
• –cookie specifies the cookie data for the web page this will change for each subsequent session.
• -D specifies the selected database for examination.
• -T identifies the selected table for examination.
• -C specifies the column names for investigation.
• –dump returns all database table entries

Image 8: Return of all Tables Specified Columns and Corresponding Data

Of the previously identified columns of the users table, the execution of the above command narrowed down the return result to be specific for database critical information. The results of this command highlight critical and sensitive information that may be leveraged in order to obtain the unauthorized access to the DVWA via another user’s authentication information. Furthermore, sqlmap unlike many other SQL injection penetration testing tools, supports the ability to brute force hash functions during the process of extracting and returning database specific data. Thus, the hashed passwords shown in Image 5, are able to be cracked, therefore providing an adversary access to the unencrypted password of each individual user. When used in conjunction with the corresponding username, a malicious entity is able to obtain access to the database that would have otherwise been rejected. The successful exploitation of the presented SQL vulnerability can be seen in the following two images, with login and successful access to the DVWA application framework through the use of the extracted username and password of the user Pablo.

Image 9: Login Page with Identified User Credentials

Image 10: Successful Access to DVWA Application using Alternative User Credentials.

5.0 Conclusion

The identification of SQL injection vulnerabilities is paramount in ensuring web application security. Web application SQL injection vulnerabilities have become inescapable in modern day society. Numerous identification methodologies have been presented, in an attempt to thwart the exploitation of these vulnerabilities. However, ignorance and insufficient understanding surrounding proposed combative mechanisms ensue the ever-occurring exploitation of SQL injection vulnerabilities. Thus, greater emphasis must be placed on prevention comprehension in order to combat the ever-prevailing exploitation of SQL injection vulnerabilities.

6.0 References

[1] M. Felderer, M. Buchler, M. Johns, A. D. Brucker, R. Breu and A. Pretschner, “Security testing: A Survey,” in Advances in Computers, 2016, pp. 1-13.

[2] A. Dasgupta, V. Narasayya and M. Syamala, “A Static Analysis Framework for Database Applications,” in IEEE 25th International Conference on Data Engineering, Shanghai, 2009.

[3] D. A. Kindy and A.-S. K. Pathan, “ A Detailed Survey on various aspects of SQL Injection in Web Applications: Vulnerabilities, Innovative Attacks and Remedies,” International Journal of Communication Networks and Information Security (IJCNIS), vol. 5, no. 2, pp. 80-92, 2013.

[4] C. Dougherty, Practical Identification of SQL Injection Vulnerabilities, Carnegie Mellon University, 2012.

[5] C. Sharma, S. C. Jain and A. K. Sharma, “Explorative Study of SQL Injection Attacks and Mechanisms to Secure Web Application Database- A Review,” (IJACSA) International Journal of Advanced Computer Science and Applications, vol. 7, no. 3, pp. 79-87, 2016.

[6] M. E. Ruse, Model checking techniques for vulnerability analysis of Web applications, Iowa: Iowa State University, 2013.

[7] P. Hellstorm, Tools for Static Code Analysis: A Survey, Linkoping: Linkopings Univeritet, 2009.

[8] S. Bangre and A. Jaiswal, “SQL Injection Detection and Prevention Using Input Filter Technique,” International Journal of Recent Technology and Engineering (IJRTE), vol. 1, no. 2, pp. 145-150, 2012.

[9] M. Cova, V. Felmetsger and G. Vigna, “Vulnerability Analysis of Web-based Applications,” in Test and Analysis of Web Services, Berlin, Springer, 2007, pp. 363-394.

[10] P. Engebretson, The Basics of Hacking and Penetration Testing, Syngress, 2013.

[11] C. T. Phong, A Study of Penetration Testing Tools, Auckland: Auckland Univerity of Technology, 2015.

[12] M. Mirjalili, A. Nowroozi and M. Alidoosti, “A Survey on Web Penetration Test,” ACSIJ Advances in Computer Science: and International Journal , vol. 3, no. 6, pp. 107-121, 2014.

[13] D. Allan, Web Applicaiton Secuirty: Automated Scanning vesurs Manual Penetration Testing, IBM, 2008.

[14] The OWASP Foundation, “OWASP Top 10 – 2017,” 2017. [Online]. Available: https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf.

[15] A. Orso, “SQL Injection Attacks,” in Encyclopedia of Cryptography and Security, Boston, Springer, 2011, pp. 1251-1252.

[16] S. A. Faker, M. A. Muslim and H. S. Dachlan, “A Systematic Literature Review on SQL Injection Attacks Techniques and Common Exploited Vulnerabilities,” International Journal of Computer Engineering and Information Technology, vol. 9, no. 12, pp. 284-291, 2017.

[17] G. Danezis, “Financial Cryptography and Data Security,” in 15th International Conference, St. Lucia, 2011.

[18] T. Scholte, D. Balzarotti and E. Kirda, “Quo Vadis? A Study of the Evolution of Input Validation Vulnerabilities in Web Applications,” in Financial Cryptography and Data Security, Berlin, Springer, 2011.

[19] Z. Su and G. Wassermann, “The essence of command injection attacks in web applications,” in ACM SIGPLAN-SIGACT symposium on Principles of programming languages, Charleston, 2006.

[20] W. G. Halfond, J. Viegas and A. Orso, A Classification of SQL Injection Attacks and Countermeasures, 2006.

[21] K. Rana, “Classification of SQL Injection Attacks and using Encryption as a Countermeasure.,” International Journal of Advanced Research in Computer Science, vol. 2, no. 1, pp. 628-630, 2011.

[22] N. Khochare, S. Chalurkar, S. Kakade and B. B. Meshramm, “Survey on SQL Injection Attacks and their Countermeasures,” IJCEM International Journal of Computational Engineering & Management, vol. 14, pp. 111-114, 2011.

[23] A. Sadeghian, M. Zamani and S. M. Abdullah, “A taxonomy of SQL Injection Attacks,” in International Conference on Informatics and Creative Multimedia, 2013.

[24] JasonHinds13, “Hackable,” Github, 2018. [Online]. Available: https://github.com/JasonHinds13/hackable. [Accessed 13 May 2018].

[25] B. A. G. Damele and M. Stampar, “sqlmap,” 2006-2018. [Online]. Available: http://sqlmap.org. [Accessed 13 May 2018].

[26] DVWA Team, “Damn Vulnerable Web Application,” [Online]. Available: http://dvwa.co.uk. [Accessed 13 May 2018].

[27] Download.com Staff, “Tamper Data,” 27 February 2009. [Online]. Available: http://download.cnet.com/Tamper-Data/3000-11745_4-10744095.html. [Accessed 13 May 2018].