a technique for preventing sql injection attack and ...sci.tamucc.edu/~cams/projects/533.pdf · 1.3...

A Technique for Preventing SQLInjection Attack and Session Hijacking

using Hashing

GRADUATE PROJECT REPORT

Submitted to the Faculty ofthe Department of Computing SciencesTexas A&M University-Corpus Christi

Corpus Christi, Texas

In Partial Fulfillment of the Requirements for the Degree ofMaster of Science in Computer Science

By

Raviteja RayaproluSpring 2018

Committee Members

Dr. Mario A. GarciaCommittee Chairperson

Dr. Ajay KatangurCommittee Member

ii

ABSTRACT

These days the world is very much dependent on web applications. It may be for

different kinds of transactions. These web applications are used by wide range of users

and they are also vulnerable to various security threats. Hence providing security

to these applications is of great importance. In these applications the customer

information stored is of utmost importance. In most applications it is stored in

back-end databases. Structured Query Language injection attack is one among the

vulnerabilities. These days there are many tools to retrieve session/HTTP cookies.

Hence Session Hijacking is another vulnerability in which the attacker gets hold of

session id. There are quite a number of techniques to avoid these attacks. This

work discusses the flaws in few of these techniques that handle these attacks and

implement an efficient hashing technique to prevent these attacks

iii

TABLE OF CONTENTS

CHAPTER Page

ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

TABLE OF CONTENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Importance of the Project . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 SQL Injection Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3.1 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.1.1 Attack Intention . . . . . . . . . . . . . . . . . . . . . . 3

1.3.1.2 Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1.3 Attack Techniques . . . . . . . . . . . . . . . . . . . . . 5

1.3.1.4 Evasion Techniques . . . . . . . . . . . . . . . . . . . . . 6

1.3.1.5 Counter Measures . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Session Hijacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5 General Attack Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 8

1.6 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.7 Objective of the Project . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.8 Proposed solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 SYSTEM DESIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 SQL Injection Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . 14


2.3 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 IMPLEMENTATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Calculating the Hash value using SHA-1 algorithm . . . . . . . . . . 25

iv

CHAPTER Page

3.3 Browser Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4 Parameterized Queries . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5 Check for a Valid Session . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.6 Securing Application Piggy Back Attack . . . . . . . . . . . . . . . . 30

3.7 Secured Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.8 Secured login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 TESTING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1 Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3 SQL Injection Tautology Attacks . . . . . . . . . . . . . . . . . . . . 35

4.3.1 Testing Tautology attack with Password = ’OR 1=1’ . . . . . 36

4.3.2 Testing Tautology attack with OR ’ABCD’ = ’ABC’+’d’ . . . 37

4.3.3 Testing Piggy Backing Attack . . . . . . . . . . . . . . . . . . 37

4.3.4 Testing Union Attack . . . . . . . . . . . . . . . . . . . . . . . 37

4.4 Blind SQL Injection Attacks . . . . . . . . . . . . . . . . . . . . . . . 37

4.4.1 Performing a Check for the Blind SQL Injection Attack . . . . 38

4.4.2 Re-check the Query Manipulation . . . . . . . . . . . . . . . . 39

4.4.3 Deny access using Parameterized Queries . . . . . . . . . . . . 39


4.5.1 Establishing a session . . . . . . . . . . . . . . . . . . . . . . . 40

4.5.2 Check for Session Hijacking in Browser (Unsecured) . . . . . . 40

4.5.3 Check for Session Hijacking in Curl (Unsecured) . . . . . . . . 40

4.5.4 Check for Session Hijacking in Curl (Secured) . . . . . . . . . . 42

4.5.5 Check for Session Hijacking in Browser(Secured) . . . . . . . . 42

4.6 Summary of Test Cases for SQL Injection Tautology Attack . . . . . 43

4.7 Summary of Test Cases for SQL Injection Piggy Backing Attack . . . 43

4.8 Summary of Test Cases for SQL Injection Union Attack . . . . . . . . 43

4.9 Summary of Test Cases for Blind SQL Injection Attacks . . . . . . . 43

5 CONCLUSION AND FUTURE WORK . . . . . . . . . . . . . . . . . . . 50

REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

v

LIST OF TABLES

TABLE Page

1 Summary of test cases for Tautology Attack (General LogIn) . . . . . 45

2 Summary of test cases for Tautology Attack (Secured LogIn) . . . . . 46

3 Summary of Test cases for SQL Injection Piggy Backing Attack

(General Login) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4 Summary of Test cases for SQL Injection Piggy Backing Attack

(Secured Login) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 Summary of Test cases for SQL Injection Union Attack (General

Login) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 Summary of Test cases for SQL Injection Union Attack (Secured

Login) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7 Summary of Test cases for Blind SQL Injection Attack (Without

parameterized Queries) . . . . . . . . . . . . . . . . . . . . . . . . . . 48

8 Summary of Test cases for Blind SQL Injection Attack (With

parameterized Queries) . . . . . . . . . . . . . . . . . . . . . . . . . . 49

vi

LIST OF FIGURES

FIGURE Page

1 Process flow of SQL Injection prevention Technique . . . . . . . . . . 16

2 Sequence diagram of Session Hijacking Attack . . . . . . . . . . . . . 20

3 Flow Chart for prevention of Session Hijacking Attack . . . . . . . . 23

4 Use Case Testing - Tautology Attack . . . . . . . . . . . . . . . . . . 36

5 Use Case Testing - Blind SQL Injection Attack . . . . . . . . . . . . 38

6 Use Case Testing - Blind SQL Injection Attack(Secured) . . . . . . . 39

7 Details of user being displayed in curl for unsecured login . . . . . . 41

8 Curl showing the error message . . . . . . . . . . . . . . . . . . . . . 42

1

CHAPTER 1

INTRODUCTION

1.1 Background

Most of the day to day transactions these days happen online through web

applications.For example e-shopping, online bank transactions, reservations etc., are

few among them. All the user information and all the transaction information that

is provided in these sites is retrieved and stored in the database. The database

where this information is stored is highly prone to SQL injection attacks. Increase

in usage of web based applications has made it mandatory to secure them from a

plethora of attacks. Web application layer is one of the main layer targeted by these

attacks. The most important reason for these kind of attacks is because of flaws

in the existing technologies and lack of understanding about security among web

application developers. [1]

1.2 Importance of the Project

From the recent studies, it can be seen that more than 70% percent of attacks

happen in payment card industry and also, more than 50% of authentic data is

exposed to attackers from the organizations who use shared credentials . Based on

this figures, web security should be the most important thing to be considered while

developing a web application.

Here are few examples of the disasters that have occurred as a result in lack

of proper web security.[5]

• In 2007, Albert Gonzalez uploaded a packet-sniffing malware into ATM sys-

2

tems, and captured between 130 and 160 million credit card and debit card

numbers.[13]

• In 2008 a sweep of attacks began exploiting the SQL injection vulnerabilities

of Microsoft’s IIS web server and SQL database server. Over 500,000 sites were

exploited.[13]

• Hackers breached the Illinois State Board of Elections voter registration database

last summer, one chapter in the currently unfolding story of Russian cyber-

attacks on U.S. election related systems in 2016.[13]

• In 2017, Yahoo saw over 1.5 billion records stolen in two separate reported

attacks– the largest breach of records in history, eclipsing AdultFriendFinder’s

412 million accounts and Myspace’s 427 million passwords.[13]

Since security has been an important aspect to be considered while developing

a web application, this work assists developers with an additional layer of security

to their database while development of the application.

1.3 SQL Injection Attack

SQL injection Attack (SQLIA) is one type of web application security indebt-

edness in which an attacker submits a database SQL command that is carried out

by a web application, which may expose all the information of a back-end database.

SQL injection attack can occur when user use the SQL command and queries without

validation and encoding. Data tricks made by user allows the application to execute

unintended commands or data change or intercept the data. An SQL injection al-

lows an attacker to create, read, update, change or delete data stored in the back-end

database.[9]

3

The risks of attacks are increasing due to a large number of web applications,

web application users and sloppy security mechanisms. SQL injection attacks can be

performed in many ways like modifying the data, query manipulation, data extraction

etc. The SQL attacker can inject a where condition in the SQL query that always

evaluates to true. This can be used to bypass authentication, extract information

etc. This type of attack is called a tautology. If the attacker tries to execute remote

commands on the database to perform denial of services then its called a stored

procedure attack. The attacker can also use piggy backing in which he tries to append

the original query with addition SQL queries to extract information or bypass access

controls.

Blind SQL Injection(BSQLI) attacks are subtler. Sometimes the result of the

query is not directly visible but it is yet possible to observe whether an injected

logical statement evaluates to true or false. Typically, in one case the site continues

to function normally and in the other the web application behaves differently.[4]

1.3.1 Classification

Based on different aspects and different properties of SQL Injection attacks,

they are classified into different categories

1.3.1.1 Attack Intention

When a threat utilizes a crafted malicious SQLI input to begin an attack, the

attack intention is the goal that the threat need to achieve whenever the attack has

been successfully performed.

1. Identifying Inject-able Parameters

Inject-able parameters are the parameters or the user input fields of the web

4

applications directly used by server-side program to create SQL statements,

which are vulnerable to SQLIA. In order to launch a successful injection attack,

a threat agent must first discover the parameters that are vulnerable to SQLIA.

2. Determining database schema

Schema is the structure of the system for the database. It defines the tables,

the relationships between fields and tables, and the fields in each table. The

schema is used by threat agents to form a correct subsequent attack to extract

or modify data from the database.

3. Bypassing Authentication

A mechanism employed by web application is to confirm user’s identity. Match-

ing the user name and the credentials stored in the database is the most general

authentication mechanism for web applications. Bypassing authentication en-

ables an intruder to impersonate another user to take unauthorized access.[8]

1.3.1.2 Vulnerabilities

Based on the kind of vulnerabilities the attacker focuses on performing the

SQL Injection attack, they can be divided into the 3 types

1. Insufficient Input Validation

The process of Input validation is an attempt to check or filter any given input

for malignant behavior. Insufficient input validation will allow the code to be

executed without suitable verification of its goal. Intruders taking advantage

of insufficient input validation can exploit malicious code to manage attacks.

2. Privileged Account

5

The privileged account has a high degree of rights to do what regular accounts

can not. Its actions may also be avoided from auditing and validation. This

is a very important vulnerability since a menace-privileged account, such as

an admin account, can compromise an attack much more than what a regular

account can.

3. Extra Functionality

Extra functionalities meant to give a broader range of usage may be a vulner-

ability since a mixture of these functionalities may lead to unintended actions.

For example, XP cmdshell supplies users with a way of executing operating

system commands, but intruder can commonly use it to add unauthorized

users.[8]

1.3.1.3 Attack Techniques

Attack techniques are the specific means by which a threat execute attacks

using bad code. Threats may use many methods to gain their goals, often mixing

several of these sequentially or using them in different varieties

1. Tautology

This attack relies on executing statements that are always true. The queries

always rely upon evaluation of a WHERE conditional. i.e injecting a” OR 2=2

” statement into the ” login ” parameter.

2. End of Line Comment

After injecting code into a particular field, valid code that follows are skipped

through usage of end of line comments. i.e would be to add ”- -” after inputs so

6

that remaining queries would not be treated as executable code, but comments.

This is useful since threat agents may not know the syntax or fields in the server.

3. Piggy-backed Query

The threat agent may add more queries other than the intended query, effec-

tively ”piggy-backing” the attack on top of a legitimate request. This technique

depends on server configurations, which allows several different queries within

a single piece of code. i.e, the threat agent may add a query delimiter such as

’;’, and then continue with a command, such as ”SELECT table name”, which

effectively selects the table specified.

1.3.1.4 Evasion Techniques

Evasion techniques are dimness techniques employed in an attack to prevent

detection by signature-based detection systems. In the context of SQLI detection, a

signature is the pattern of known attack strings. SQLIA occurs when an input string

alter the prepared syntactical structure of structured query language statement.

1. Sophisticated Matches

One of the major signatures used by such mechanisms is some sort of variant

on the famous OR 2=2 attack. Sophisticated matches evasion technique uses

other expression of OR 2=2. For example: OR ’SQLI’ = ’SQLI’ , OR ’Complex’

= ’Si’+’mple’, OR 3 ¿ 2 and OR ’Complex’ BETWEEN ’R’ AND ’T’ all have

the same effect as ”OR 1=1”.

2. Hex Encoding

Hex encoding technique uses hexadecimal encoding to represent a string. For

7

example, the string DROP can be represented by the hexadecimal number ,

which most likely will not be detected by a signature protection system

3. In-line Comment

In-line comment technique obscures input strings by inserting in-line comments

between SQL keywords. For example, /**/OR/**/DROP/**/name can escape

detection from signatures that expects white space between SQL keywords.

1.3.1.5 Counter Measures

There are a number of ways a system administrator and developer can dismiss

or counter injection attacks made on their systems.

1. Parameterized Query

A parameterized query is a query in which placeholders are used for parameters

and the parameter values are supplied at execution time. The most important

reason to use parameterized queries is to avoid SQL injection attacks.

2. Least Privilege

The account that an application uses to access the database should be given

only the minimum permissions needed to access the objects that it needs to

use.

3. Customized Error Message

Threats may gain access to knowledge through excessive informative error mes-

sages, yet fully removing error messages makes debugging a difficult task. Cus-

tomized error messages hinder the searching progress of threat, particularly in

concluding specific details such as SQLI injectable parameters etc., [8]

8

1.4 Session Hijacking

One more vulnerability in the web application is session hijacking. A session

by definition is a dialogue or an interactive information interchange, a conversation or

a meeting, between two or more communicating devices, or between a computer and

user. Establishing a connection is required in a connection-oriented communication.

The web server requires some way to remember every users connection, so the web

server uses a token for every authenticated client session. In session hijacking, a

valid user session is exploited to gain unauthorized access to the users session and

hence the users information stored in the session. This can be achieved by stealing

or obtaining the users session key by some means.[1]

1.5 General Attack Behaviour

General attack behavior of a web application when an attack occurs is listed

as follows

• When attackers attack a web application, large number of requests will be sent.

So an attack can be sensed when the number of requests is higher than usual.

• Sometimes the attackers inserts large amount of SQL characters into URL.

These cannot be executed normally and they result in system degradation.

• When attackers attack web application, their IP, port, accessed URL, request

and parameters can be obtained. This will be helpful in analysis of SQL Injec-

tion attacks.[13]

9

1.6 Related Work

The web applications these days are vulnerable to SQLIAs. Most of the users

data from the web are extracted and stored in the databases. Hence SQLIAs may

cause a lot of threat to this data, like loss of customer confidentiality, theft of users

identity, breach of customer data security etc. Sometimes the attacker can also make

use of a corrupt system and take control of a host. According to a study by Garter

group about 300 internet websites are prone to SQLIAs.

Injection attack occurs when an attacker or an intruder inserts some extra

fields or statements in the SQL query which would let them gain unauthorized access

to some confidential data or obtain some data which could breach the security of the

database. There can be many possible mechanisms through which SQL attacks may

occur. In one case, the attacker tries to inject the SQL queries by suitably modified

SQL inputs. This type of attack is known as injection through user input. Another

type of SQL attack would be injecting the server variables. If these variables are

logged into the database without checking, then it would cause a possible SQLIA.

In a second order SQLIA the attacker may seed malicious input into a system which

would later trigger the SQLIA. In these type of attacks the results of the injected

query is directly visible. There is another type of SQLIA where the result of the

SQL query would not be directly visible, but it is possible to observe if an injected

logical statement evaluates to true or false. This type of attack is called blind SQL

injection attack (BSQLIA), which is a more subtle form of SQLIA.

Many of the web applications are prone to SQLIAs. According to White

Hat security web applications security statistics report 2016, SQLIAs have lowest

remediation rates of less than 10% . Hence SQLIAs can be one of the vulnerabilities

of web application that needs to be prevented.

10

R.Dubey et al. proposes a technique with combination of two security services.

The authors propose a model for web application security which includes generating

hash esteem against the user name and secret word and storing this in the database.

The hash esteem is generated by adding a constant value floor to the user name

and password. This technique uses hash value as the hash functions have a unique

property to convert arbitrary length data to a fixed size digest. The hash value

and hash value table is used by the data structure for faster lookup of values. The

second technique proposed is to include a proxy server between the client server

model. This proxy server will check each query string for infection before it is passed

to the server.[9]

Rathod Mahesh Pandurang and Deepak C. kariat [10] proposed a mapping

model which establishes a mapping set of URL and SQL. If the request is dynamic,

it is compared with the previous request that is authenticated and processed. If the

request doesnt match, then the malicious input data from SQL query is removed and

checked to be passed or blocked.

R.Ludinard et al.[7] proposed a model for Ruby on Rails web application.

This model uses data in the web applications to detect attacks. He believes that the

state of the web application changes during the attack. This model is effective but

it doesnt detect cross site scripting.

Ouarda et al.[6] proposed a method which is based on web page similarity

analysis. This method detects attack based on response from the web application.

It is based on a concept that the response from web application is different after

the attack and in normal situations. The disadvantage of this method is that if the

content change in the response is bigger the detection rate is low.

Kabir Umar et al[12] proposed a new method which is based on evolutionary

11

programming. This establishes a competitive relationship between web application

set and attack test set. After a series of evolutions, a more secure web application

set and test attack set are obtained. This method can detect and even repair the

vulnerability.

1.7 Objective of the Project

The developer should to have an idea about web security and techniques

that would enable them to provide an additional layer of security for their web

applications. The main objective of this work is to provide a technique that will

enable the developers to provide an additional layer of security, right during the

development phase of the web application.

1.8 Proposed solution

The hashing technique is used to prevent the SQLIA and session hijacking

web-based attacks. Successful prevention of these attacks makes the web applications

more secure from the outside attackers. The hashing algorithm used here is SHA1.

A hash digest is generated using SHA1 which is similar to digital fingerprint. This

hash digest is stored against the user records. Access is only provided if the hash

digest matches there by avoiding attacks. Whenever the user tries to attack, the hash

digest created would be different from the one stored. Through this implementation

model, the following SQLIAs and session hijacking are prevented.

• Tautology Attack

• Piggy Backing Attack

• Union attack

12

• Blind SQL Injection Attack

In order to handle the session hijacking attack, hashing is used to hash the

parameters of the session like host IP address, browser name, browser platform etc.,

13

CHAPTER 2

SYSTEM DESIGN

This technique proposed serves as an effective method for preventing the

SQLIA and session hijacking attack. The method involves the use of hashing tech-

nique, here the hashing algorithm used is SHA1.

The SHA i.e. Secure Hash Algorithm is based on the concept of hash function.

The basic idea of a hash function is that it takes a variable length message as input

and produces a fixed length message as output which can also be called as hash or

message-digest. The technique behind building a good, secured cryptographic hash

function is to devise a good compression function in which each input bit affects as

many output bits as possible . It is used with the Digital Signature Standard (DSA)

for digital signature so it has a particular importance.[3]

SHA-1 has a set of cryptographic hash functions very similar to the MD family

of hash functions. But MD family uses more bits in hash function. This is the main

difference between MD and SHA-1. Because of this difference SHA-1 is more secure.

SHA-1 differs from SHA-0 only by a single bitwise rotation in the message schedule

of its compression function. SHA-1 appears to provide greater resistance to attacks.

In SHA-1 input data is called message and the hash value is called message digest.

Hash function takes a variable length message as an input and as an output produces

a fixed length message which can also be called hash or message digests. SHA-1 has

a message size of 264 bits and a message digest of 160 bits. SHA-1 is designed so

that it is practically infeasible to find output of the two input messages to be the

same. It is also impossible to get back the input message from the obtained message

digest.[11]

14

2.1 SQL Injection Attack

The technique uses an authentication query to check for registered users of the

application. The authentication query matches the user entered credentials to the

credentials stored in the database during user registration. In this implementation,

for each user authentication query to access the database, a unique fingerprint is

generated using a hashing algorithm, based on the authentication credentials of the

user, provided during the user registration. This unique fingerprint of the user is

stored along with the access credentials in the database.[2]

When the user logs into the application providing the access credentials a hash

digest is dynamically calculated from the user provided credentials. This dynamically

calculated hash digest is then matched to the hash digest already stored in the

database which is calculated during the user registration. The user is permitted

access to the application only if the two hash digest match. This can be considered

similar to storing a unique digital fingerprint of the user during the registration

and checking this digital fingerprint upon every user login. When the attacker tries

to perform an SQLIA the hash digest generated dynamically will not match hence

preventing the attacker from performing the SQLIAs.[8]

For Example: When the SQL query

" Select * from TableName where username = UserName and password = Password"

is passed through the SHA1 hash algorithm it generates a message digest,

which is unique. When the user logs in with his login credentials, the hash digest of

the user authentication query is dynamically calculated and compare it against the

already stored hash digest. If the hash digest matches then there is no SQLIA. This

methodology works because SQL has a fixed syntax for authentication query and if

15

the adversary tries to perform a SQLIA then the syntax of the query would be dif-

ferent. Thus the hash digest computed is different and the user is not authenticated.

The hash function is used for authentication as it is collision resistant. Also hash

functions have avalanche property i.e. if even a character of input query changes,

the output hash digest varies by more than half the output characters. The process

flow for this implementation is shown in figure 1.

Pseudo Code for prevention of SQLIA:

1. On user registration, generate hash of the select query

HashDigest = SHA1( Select from TableName where username = UserName and password = Password ")

2. Store HashDigest as an attribute in the database against the user information.

3. On user login, during authentication calculate dynamically the hash value of

the query against the user name and password entered using SHA1.

4. Compare the dynamically calculated hash against HashDigest.

5. User is authenticated only if the two hash digests match

6. Else, either the user authentication provided is invalid or it is a session hijacking

attack.

Through the implementation model, the following SQLIAs are prevented.

1. Tautology Attack: In this attack the adversary tries to bypass the user authen-

tication fields required to access the application. The authentication query for

providing access to the user, checks the database for registered users. This

authentication query usually has a WHERE condition. The attacker takes

16

Figure 1. Process flow of SQL Injection prevention Technique

17

advantage of this condition to perform a SQLIA. The attacker can insert the

condition which would always evaluate to true.

’ or 1=1--

With this the attacker will close the actual authentication query, insert an

OR condition which will always evaluate to true and comment out any other

authentication conditions present in the query.

2. Piggy Backing Attack: The main aim of this attack is to modify or add data,

data extraction, dropping or deleting user or database tables, remote execu-

tion of commands and performing service denials. The attacker can use the

statement ” ’or 1=1;drop table AdminTable:– ” to perform this attack.

Here the attacker closes the current authentication statement and then piggy

backs another SQL query which can extract information, delete or drop any

other table from the database. Using this attack the attacker can delete the

permissions table and gain access to any database tables.

3. Union Attacks: The attacker uses the SQL UNION operator to retrieve records

from another table. An attacker can use the SQL statement

” ’UNION select * from AllTables; ” for Union attack.

The attacker here tries to get information from the other database tables by

using union operator.

4. Blind SQL Injection attack: A way of evaluating if a system is vulnerable to

attacks is by considering the query obtained from string

Select ∗ from users WHERE username =′ user′

18

and suppose it is used to display public user information on a Web page. In

particular, data from the first returned record are shown. To see if this can be

exploited in a blind injection it is enough to inject the following two usernames:

luccio AND 1 = 0

luccio AND 0 = 0

If the system is not vulnerable to attacks, e.g., by filtering user input, it will

behave in the same way in the two cases. If it is vulnerable, instead, the results

of the query will be empty in the first case (1=0 is not true), and the same

as for luccio in second case (given that 0=0 is always true). What will be

displayed in case of an empty query depends on how the application handles

that case: it could be either an error message or a broken Web page. In any

case, the ability of distinguishing true and false answers is enough to mount a

BSQLi attack.

The attack proceeds by

(a) Injecting a query

(b) Comparing the result with the previous pages to check if the resulting

query is true or false. Items 4a and 4b are run again as many times as

necessary


Hypertext Transfer Protocol (HTTP) uses session based communication to

keep a user/browser state; hence an HTTP session is prone to the session injection

attack. An HTTP session cookie is stored in a users browser to preserve the tem-

19

porary state of a users session. Like for example, once the user is authenticated by

the web application, the session state is saved so that querying the database is not

required again and again for authentication. Also session cookies can be used to

save the intermediate state of users session between navigation of pages. It can be

thought of as a volatile quick accessible memory assigned to a user who is accessing

the web application.

The session cookies are usually stored in the clients browser; these cookies are

usually transmitted over an insecure channel. If this session cookie is obtained by

a passive attack then the user’s session can be compromised. This type of attack is

known as session sidejacking, here attacker can use packet sniffing tools to capture

the network traffic between two principals and to steal their session cookies.

Another type of session hijacking attack is Session fixation, here the attacker

can set the users session id to any session id know to him. This could be done by

the attacker by sending an email to the user with a link that opens a session whose

session id is known to the attacker. Alternatively, another type of session hijacking

attack can be done by cross-site scripting, where the adversary tricks the user to run

a code which is treated as trustworthy as it appears to belong to the server. This

allows the attacker to obtain the session cookie and perform session hijacking.

Any legitimate user of an application can be the victim of session hijacking

attack. Initially the legitimate user sends the application request to the application

server. The server then asks for user authentication, for which the user responds with

his credentials (here it is considered a user is already registered with the application).

The server now authenticates the user and establishes a user session with a unique

session ID to keep track of the user session. The attacker can sniff this session ID or

HTTP cookie. Using this session ID or HTTP cookie, the attacker can bypass the

20

authentication and get control over the legitimate users session. The attack scenario

is shown in Figure 2.

Figure 2. Sequence diagram of Session Hijacking Attack

For preventing session hijacking attack, when a legitimate user sends an ap-

plication request to the application server, application server requests for the users

login credentials to authenticate the user. The user then furnishes his credentials to

the application server. The application server will generate a unique hash digest by

concatenating the following parameters of the legitimate user:

• Host IP address

• Browser name

• Browser Platform

• Major Browser Version

21

• Minor Browser Version.

If an attacker intercepts the session ID or the HTTP cookie and tries to hijack the

legitimate user session. Before he can gain access to the legitimate users session,

the application server will first calculate the hash digest of the attackers browser

details and system parameters and check it against the hash digest generated for the

legitimate users session ID. The hash digest calculated for the attackers application

request will not match the hash calculated for the legitimate users application request

because the parameter values given as input to the hash function are different. Figure

3 shows the flowchart of the implementation of prevention of session hijacking attack.

HashDigest = SHA1(HostIP $||$ BrowserName $||$ Browser Platform $||$

Browser Major Version $||$ Browser Minor Version)

Pseudo code for Prevention of Session Hijacking attack

1. On user login, Server generates a hash digest for a legitimate user session using

system and browser parameters.

HashDigest1 = SHA1(HostIP $||$ BrowserName $||$ Browser Platform $||$


HashDigest2 = SHA1(Unique Session Parameter)

SessionID = HashDigest1 $||$ HashDigest2

2. Application server establishes a legitimate user session with uniqueSessionID.

3. If attacker sends application request using sniffed of legitimate user, then Ap-

plication server calculates the following equations

22

HashDigest1’ = SHA1(HostIP $||$ BrowserName $||$ Browser Platform $||$


4. Compare HashDigest1 & HashDigest1’

5. if (!HashDigest1 & HashDigest1’) then deny access to application.

2.3 System Overview

The implementation of web application was done using java on Eclipse IDE.

The web application was deployed in tomcat for testing the prevention methods.

The tools required for implementation:Eclipse, mySQL server, Intel(R) Core(TM)

i5-6200U CPU @ 2.30GHz, 2400 Mhz, 2 Core(s), 4 Logical Processor(s) or similar

configurations, Microsoft Windows operating system.

The implementation included, a simple ASP.net web application inculcating

the general properties of a regular web application was used. This implementation

included user registration, storing the user registered information in mySQL server,

access controls for authentication (using user name and password) and producing

random session cookies for each login. This web application was deployed in tomcat,

hence this machine where the web application was deployed served as the server and

any system in the network could be the client and access this web application.

23

Figure 3. Flow Chart for prevention of Session Hijacking Attack

24

CHAPTER 3

IMPLEMENTATION

3.1 Login

In this application the registered users are allowed to login to the system. If

the user is not a registered one or they do not enter their valid credentials they are

not allowed to login to the system.

public class VerifyLogin

{

public int verifyLogin(String username,

String password) throws Exception

{

Connection con=DBConnection.getDBConnection();

Statement statement=con.createStatement();

String SQL="selct * from login where username=’"+username+"’and password=’"+password+"’"; LogMessage.logMessage("Executing"+SQL);

ResultSet resultSet=statement.executeQuery(SQL);

int result=-1;

if(resultSet.next())

{

result=resultSet.getInt("id");

LogMessage.logMessage("User found in database,login

success");

LogMessage.logMessage("User Details:");

LogMessage.logMessage("Id:"+resultSet.getInt("id")+

25

"Username"+resultSet.getString("username")+

"Password"+resultSet.getString("password"));

}

else

{

LogMessage.logMessage("User not found in database,

login failed");

result=-1;

}

con.close();

return result;

}

3.2 Calculating the Hash value using SHA-1 algorithm

The main purpose of this work is to secure a web application against SQL

Injection and session hijacking attacks with the help of a hash function. The query

which will be passed to authenticate the user during the login is hashed and stored

in the database. This class is useful in calculating the hash value.

public static String calculateHash(String password)

{

LogMessage.logMessage("Calculating hash value for"+password+"Using SHA-256");

MessageDigest md=null;

try {

md=MessageDigest.getInstance("SHA-256");

26

} catch(NoSuchAlgorithmException e) {

//TODO Auto-generated catch block

e.printStackTrace();

}

md.update(password.getBytes());

byte byteData[]=md.digest();

//convert the byte to hex format method 1

StringBuffer sb=new StringBuffer();

for(int i=0;i<byteData.length;i++)

{

sb.append(Integer.toString((byteData[i]&0xff)+0x100, 16).substring(1));

}

LogMessage.logMessage("Her format:"+sb.toString());

//convert the byte to hex format method 2

StringBuffer hexString=new StringBuffer();

for(int i=0;i<byteData.length;i++)

{

String hex=Integer.toHexString(0xff & byteData[i]);

if(hex.length()==1)

hexString.append(’0’);

hexString.append(hex);

}

LogMessage.logMessage("Hex format:" +hexString.toString());

return hexString.toString();

}

27

}

3.3 Browser Details

In order to prevent session hijacking in this work, a hash value has to be

calculated using the browser details of the user. This helps in preventing the attacker

from using the session cookies to gain access of the user session. This class is helpful

in user browser details

public UserAgent(OperatingSystem operatingSystem, Browser browser)

{

this.operatingSystem=operatingSystem;

this.browser=browser;

this.id=((operatingSystem.getId()<<16)+browser.getId());

}

public UserAgent(String userAgentString)

{

String userAgentLowercaseString=userAgentString==null

null:userAgentString.toLowerCase();

Browser

browser=Browser.parseUserAgentLowercaseString(userAgentLowercaseString);

OperatingSystem operatingSystem=OperatingSystem.UNKNOWN;

if(browser!=Browser.BOT)

operatingSystem=OperatingSystem.parseUserAgentLowercaseString

(userAgentLowercaseString);

28

this.operatingSystem=operatingSystem;

this.browser=browser;

this.id=((operatingSystem.getId()<<16)+browser.getId());

this.userAgentString=userAgentString;

}

3.4 Parameterized Queries

In order to perform the attacks the attacker should be aware of few details of

the users database. So in order to gain these details the attacker goes with some trial

and error methods. These trials doesn’t yield any visible results but gradually with

the outcomes the attacker gets to know about the details that he wants. In order to

avoid this kind of trials the user information is retrieved using parameterized queries.

It shows the usage of parameterized queries for secured retrieval of user information.

public UserINformation selectProfile(String userid) {

UserInformation profile = null;

try {

Connection con = SecuredDBConnection.getDBConnection();

String SQL = "select

userdetails.id,gender,address,college,dateofbirth,name,username

from userdetails,login where userid=?";

PreparedStatement preparedStatement = con.prepareStatement(SQL);

preparedStatement.setString(1, userid);

System.out.println(preparedStatement);

ResultSet resultSet = preparedStatement.executeQuery();

29

if (resultset.next()){

profile = new UserInformation();

profile.setId(resultSet.getInt("id"));

profile.setGender("" + resultSet.getstring("gender"));

profile.setAddress(resultSet.getString("address"));

profile.setCollege("" + resultSet.getString("colege"));

profile.setDateofbirth(resultSet.getString("dateofbirth"));

profile.setName(resultSet.getString("name"));

profile.setUSername(resultSet.getString("username"));

}

3.5 Check for a Valid Session

In order to check for a valid session, the code in userdetailsservice class is

used. Here getsession(false) method is used. The difference between getsession(true)

and getsession(false) is that getsession(true) checks for a valid session and creates

one if it doesn’t exist. But getsession(false) checks for the user session and doesn’t

create one if it doesn’t exist.

public class UserdetailsService {

public UserInformation getUserInformation(HttpServletRequest request)

{

HttpSession session = request.getSession(false);

if (session == null || session.getAttribute("userid") == null) {

return null;

30

} else {

String userid = (String) session.getAttribute("userid");

UserInformationDB userInformationDB = new UserInformationDB();

return userInformationDB.selectProfile(userid);

}

}

}

3.6 Securing Application Piggy Back Attack

Piggy Back is a kind of SQL Injection attack in which the attacker adds a

small script to the authentication query which results in the back-end database table

being deleted. In order to avoid this code snippet secured registration is helpful.

@Test (dependsOnGroups = { "securedregistration" })

public void verifyLoginwithPiggybackattack1 () throws Exception {

String input = "’; drop table admin -- ";

LogMessage.logMessage("Verifying login with piggy back attack with

input " + input);

SecuredVerifyLogin verifyLogin = new SecuredVerifyLogin();

int result = verifyLogin.verifyLogin("test1", input);

Assert.assertEquals(result, -1) ;

}

@Test (dependsOnGroups = { ’securedregistraion" })

public void verifyLoginwithPiggybackattack2() throws Exception {

31

String input = "’; drop /* this is */ table /* sql injection */

admin --";

LogMessage.logMessage("Verfying login with piggy back attack with

input " + input);



Assert.assertEquals(result, -1);

}

@Test(dependsOnGroups = { "securedregistraion" })

public void verifyLoginwithPiggybackattack3() throws Exception {

String input = "’ drop ’,, table admin --";

LogMessage.logMessage("Verifying login with piggy back attack with

input " + input);



}

3.7 Secured Registration

In this work the user will be able to register with his details. The difference

with the normal registration and the registration is that in additional to the users

details which they enter, an additional hash value will be stored which will be helpful

for avoiding SQL injection attack.

package com.hijacking.dao.unsecure;

32

import org.testing.Assert;

public class UserRegistrationSecuredTest {

@BeforeClass

public void beforeSuite() {

UserRegistrationSecured userRegistration = new

UserRegistrationSecured();

userRegistration.deleteUsers();

}

@Test(groups = { "securedregistration" })

public void testRegistration() {



int inserted = userRegistration.addUser("test", "test", "test",

"[email protected]");

Assert.assertEquals(1, inserted);

}

@Test(dependsOnMethods = { "testRegistration" }, groups = {

"securedregistration" })

public void testRegistrationSecondTime() {



int inserted = userregistration.addUser("test", "test",

"test", "[email protected]");

Assert.assertEquals(-1, inserted);

}

33

}

3.8 Secured login

Since a hash value is stored against every user’s details in the database, when-

ever a user is trying to login to the system the authentication query will be hashed

and it is matched against the one stored in the database. If the hash value doesn’t

match, the suer details are not retrieved.


public void verifySecuredLoginwithTautologyAttack1() throws Exception {

String input = "’ OR 1 = 1-- ";

LogMessage.logMessage("Verfying login with tatutology attack with

input " + input);




}



String input = "’ OR 1 = 1 and 1-- ";

LogMessage.logMessage("Verifying login with tautology attack with

input " + input);


34



}



String input = "’ OR 1 || 1 and 1-- ";


input " + input);




}



String input = "’ OR 1 && 1 = 1-- ";


input " + input);




}

35

CHAPTER 4

TESTING

Testing is performed to find if the application has all the functionalities and

also to find any bugs that are present. Testing the final web application makes

sure that the application functions without any errors. During testing, behavior of

the application is analyzed by giving different inputs to it. Testing is done manually

using web user interface. Automated Automated testing is also carried out by writing

some scripts.The output of all the test-cases is listed in a report

4.1 Registration

This application consists of a Registration page for the user The user is allowed

to enter his details and register as a valid user. The registration page for the user

has the basic details of the user. The user isn’t allowed to register with the same

details twice.

4.2 Login

Once the user is registered he/she is allowed to login using the credentials

they’ve provided during the registration. Here two different kinds of logins are pro-

vided. They are available in order to differentiate between the login without the

hashing technique and also the login which is secured using the hashing technique.

4.3 SQL Injection Tautology Attacks

Tautology attack is a kind of SQL injection in which the attacker adds state-

ments that tend to true. In testing the tautology attack first the check is done for

36

the application without the attack. The actual user-name and password is used to

login first. Later the test cases are implemented.

Figure 4. Use Case Testing - Tautology Attack

4.3.1 Testing Tautology attack with Password = ’OR 1=1’

First a user-name of one of the users is chosen. In the password field the

tautology ’ OR 1=1 ’ is added. If the attack is not handled the attacker will be able

to login to the application. But if the hashing technique is implemented then the

attacker is not allowed to login.

37

4.3.2 Testing Tautology attack with OR ’ABCD’ = ’ABC’+’d’

A similar test is done with different tautology statements. It is to make sure

that the technique is working fine for different tautology attacks. The application

proved to be working with different kinds of statements.

4.3.3 Testing Piggy Backing Attack

In piggy backing attack, drop table statement are added with ’;’. This will

help attacker in adding statements for performing operations on database. The

hashing technique implemented can also handle union attack. The application is first

checked without implementing the hashing technique. The database operations are

being performed if the technique isn’t implemented. If the technique is implemented

the attacker cannot login to the application or perform drop table operation.

4.3.4 Testing Union Attack

In Union attack, drop table statement are added with ’;’. This will help at-

tacker in adding statements for performing operations on database. The hashing

technique implemented can also handle piggy backing attack. The application is

first checked without implementing the hashing technique. The database operations

are being performed if the technique isn’t implemented. If the technique is imple-

mented the attacker cannot login to the application or perform additional database

operations.

4.4 Blind SQL Injection Attacks

Blind SQL Injection is a kind of attack in which the user doesn’t actually

modify the credentials but adds some url additional to the existing URL. This will

38

result in the attacker being able to know the details about the database and the

system of the user. This will facilitate him in performing further attacks.

Figure 5. Use Case Testing - Blind SQL Injection Attack

4.4.1 Performing a Check for the Blind SQL Injection Attack

The attacker checks if the user’s information is displayed if the credentials are

passed. The user-id is shown in URL. The attacker checks if the id can be changed

to obtain information about a different user. If this is working then the attacker

can try adding additional statements. This acts like a trial and error method for

obtaining data.

39

4.4.2 Re-check the Query Manipulation

If the application is not secured, then event though if the attacker manipulates

the URL and adds some malicious content, the user details are retrieved.

Figure 6. Use Case Testing - Blind SQL Injection Attack(Secured)

4.4.3 Deny access using Parameterized Queries

But for handling the attacks this applciation has used parameterized queries.

So though the user has added some malicious URL the user details are not retrieved.

40


In session Hijacking the attacker gets hold of session of the user by means of

HTTP cookies. But in this work the attacker won’t be able to gain access to the user

session by using cookies. This is because a hash is calculated based on the user’s

browser details and system details. Unless the hash matches the user’s session can’t

be accessed.

4.5.1 Establishing a session

The user details are retrieved when he logs in. It is showed in figure . This

is just a general login i.e., initial login for the user. The session cookies are grabbed

after this general login of the user. In order to perform session hijacking attack, the

cookies are obtained only after the user is logged in to the application.

4.5.2 Check for Session Hijacking in Browser (Unsecured)

For an unsecured login, the user will be able to login to view his details. But

the user’s details can be retrieved for unsecured login. Here the session’s HTTP

cookies are used to retrieve the user’s details on a different browser.

4.5.3 Check for Session Hijacking in Curl (Unsecured)

The user details are being retrieved for unsecured login. This can be observed

by using curl also. It is shown in figure 7 that the user details are being retrieved in

curl.

41

Figure 7. Details of user being displayed in curl for unsecured login

42

4.5.4 Check for Session Hijacking in Curl (Secured)

The user’s cookies are being used in curl to retrieve the details of the user

but the details are not being displayed and it is shown in figure 8. It’s asking for the

user to login.

Figure 8. Curl showing the error message

4.5.5 Check for Session Hijacking in Browser(Secured)

Once a legitimate session is established by the user, the cookies are attained

from the user’s browser. These cookies can be used in a different browser or an

incognito window of the same browser.If the same cookies are being used to establish

a session since the hash values doesn’t match, the user session is not attained and in

return the user will be asked to login again.

43

4.6 Summary of Test Cases for SQL Injection Tautology Attack

Using automated testing a total of 14 tautology attacks have been run. A

summary of all the test cases showing the difference in the output for secured and

unsecured login . A total of 14 kinds of tautology attacks have been handled. The

test-cases are summarized in table 1 and table 2

4.7 Summary of Test Cases for SQL Injection Piggy Backing Attack

Using automated testing a total of 3 piggy backing attacks have been run. A

summary of all the test cases showing the difference in the output for secured and

unsecured login . A total of 3 kinds of piggy backing attacks have been handled.

The test-cases are summarized in table 3 and table 4

4.8 Summary of Test Cases for SQL Injection Union Attack

Using automated testing a total of 3 union attacks have been run. A summary

of all the test cases showing the difference in the output for secured and unsecured

login . A total of 3 kinds of union attacks have been handled. The test-cases are

summarized in table 5 and 6

4.9 Summary of Test Cases for Blind SQL Injection Attacks

In testing the blind SQL Injection attacks first we check if the user details can

be retrieved with a change of the id in URL. Later some true statements are added

so that it can be checked if the details can be retrieved.

If this is working, statements that are required for retrieving the details which

the attacker requires are added. These details might include obtaining the database

44

version, database schema, database tables etc.,

The most important detail related to the database is the version of the

database used. In the Testing, it is checked if the database version is obtained

without the hashing technique being implemented. Later the hashing technique is

checked. The statements for obtaining database version is added. But the details

are not obtained since the browser details are hashed.

A total of 75 test cases have been run which includes 28 test-cases for Tautol-

ogy attacks, 6 test-cases for piggy back attack, 6 test-cases for union attacks, 7 test

cases for general login and 28 test-cases for Blind SQL Injection attacks.

Hashing technique is checked against session hijacking attack in incognito

window of the same browser in which the user’s session has been established. It

also tested in curl, a tool which can be used to establish session and perform URL

manipulations. Both the tests proved hashing technique to be effective.

A summary of all the test cases with their time complexities is also available

as a report. This report shows the details of each and every test case with its

output. The test-report is obtained with the automated testing. Manual testing is

also worked on with a simple web-page where the password field can be tested with

different kinds of inputs.

45

Table 1. Summary of test cases for Tautology Attack (General LogIn)S.no Type of Attack Input Expected Result Actual Result Status

1SQL Injection

Tautology Attack

username = ’test1’

Password = ”OR 1=1–’Login Allowed Same as expected Pass

2SQL Injection

Tautology Attack


Password = ”OR 10 between 1 and 100–’Login Allowed Same as expected Pass

3SQL Injection

Tautology Attack


Password = ”OR id between 1 and 100–’Login Allowed Same as expected Pass

4SQL Injection

Tautology Attack


Password = ”%00’ OR 10 between 1 and 100–’Login Allowed Same as expected Pass

5SQL Injection

Tautology Attack


Password = ” OR ASCII(SUBSTRING(’a’,1,1))=97–’Login Allowed Same as expected Pass

6SQL Injection

Tautology Attack


Password = ”OR ”=”’Login Allowed Same as expected Pass

7SQL Inejction

Tautology Attack


Password = ”OR 1=1 and 1–’Login Allowed Same as expected Pass

8SQL Inejction

Tautology Attack


Password = ”OR 1—— 1=1–’Login Allowed Same as expected Pass

9SQL Inejction

Tautology Attack


Password = ”OR 1 && 1 = 1–’Login Allowed Same as expected Pass

10SQL Inejction

Tautology Attack


Password = ”OR 2>1–’Login Allowed Same as expected Pass

11SQL Injection

Tautology Attack


Password = ’xx’ OR ’x’=’x’Login Allowed Same as expected Pass

12SQL Injection

Tautology Attack


Password = ”OR ’ABCD’=’ABC’+’d’ ’Login Allowed Same as expected Pass

13SQL Injection

Tautology Attack


Password = ”OR ’ABCD’>’A’– ’Login Allowed Same as expected Pass

14SQL Injection

Tautology Attack


Password = ”OR ’ABC’=N’ABC’– ’Login Allowed Same as expected Pass

46

Table 2. Summary of test cases for Tautology Attack (Secured LogIn)S.no Type of Attack Input Expected Result Actual Result Status

1SQL Injection

Tautology Attack


Password = ”OR 1=1–’Attack Detected Same as expected Pass

2SQL Injection

Tautology Attack


Password = ”OR 10 between 1 and 100–’Attack Detected Same as expected Pass

3SQL Injection

Tautology Attack


Password = ”OR id between 1 and 100–’Attack Detected Same as expected Pass

4SQL Injection

Tautology Attack


Password = ”%00’ OR 10 between 1 and 100–’Attack Detected Same as expected Pass

5SQL Injection

Tautology Attack


Password = ” OR ASCII(SUBSTRING(’a’,1,1))=97–’Attack Detected Same as expected Pass

6SQL Injection

Tautology Attack


Password = ”OR ”=”’Attack Detected Same as expected Pass

7SQL Inejction

Tautology Attack


Password = ”OR 1=1 and 1–’Attack Detected Same as expected Pass

8SQL Inejction

Tautology Attack


Password = ”OR 1—— 1=1–’Attack Detected Same as expected Pass

9SQL Inejction

Tautology Attack


Password = ”OR 1 && 1 = 1–’Attack Detected Same as expected Pass

10SQL Inejction

Tautology Attack


Password = ”OR 2>1–’Attack Detected Same as expected Pass

11SQL Injection

Tautology Attack


Password = ’xx’ OR ’x’=’x’Attack Detected Same as expected Pass

12SQL Injection

Tautology Attack


Password = ”OR ’ABCD’=’ABC’+’d’ ’Attack Detected Same as expected Pass

13SQL Injection

Tautology Attack


Password = ”OR ’ABCD’>’A’– ’Attack Detected Same as expected Pass

14SQL Injection

Tautology Attack


Password = ”OR ’ABC’=N’ABC’– ’Attack Detected Same as expected Pass

Table 3. Summary of Test cases for SQL Injection Piggy Backing Attack (General

Login)S.no Type of Attack Input Expected Result Actual Result Status

1SQL Injection

PiggyBack Attack


Password = ”;drop table admin–’

User not found in database

Table in the database deletedSame as expected Pass

2SQL Injection

PiggyBack Attack


Password = ”; drop /* this is */ table /* sql injection */ admin – ’



3SQL Injection

PiggyBack Attack


Password = ”; drop ’,, table admin – ’



47

Table 4. Summary of Test cases for SQL Injection Piggy Backing Attack (Secured

Login)S.no Type of Attack Input Expected Result Actual Result Status

1SQL Injection

PiggyBack Attack


Password = ”;drop table admin–’


Table in the database is securedSame as expected Pass

2SQL Injection

PiggyBack Attack


Password = ”; drop /* this is */ table /* sql injection */ admin – ’



3SQL Injection

PiggyBack Attack


Password = ”; drop ’,, table admin – ’



Table 5. Summary of Test cases for SQL Injection Union Attack (General Login)S.no Type of Attack Input Expected Result Actual Result Status

1SQL Injection

Union Attack


Password = ” Union select * from login – ’User Found in Database Same as expected Pass

2SQL Injection

Union Attack


Password = ’ ’ UNION SELECT null,null,null,null from login – ’User found in Database Same as expected Pass

3SQL Injection

Union Attack


Password = ” Union /* this is */ select * /* sql injection */ from login – ’User found in Database Same as expected Pass

Table 6. Summary of Test cases for SQL Injection Union Attack (Secured Login)S.no Type of Attack Input Expected Result Actual Result Status

1SQL Injection

Union Attack


Password = ” Union select * from login – ’User not found in Database Same as expected Pass

2SQL Injection

Union Attack


Password = ’ ’ UNION SELECT null,null,null,null from login – ’User not found in Database Same as expected Pass

3SQL Injection

Union Attack


Password = ” Union /* this is */ select * /* sql injection */ from login – ’User not found in Database Same as expected Pass

48

Table 7. Summary of Test cases for Blind SQL Injection Attack (Without parameter-

ized Queries)S.no Type of Attack Input Expected Result Actual Result Status

1 Blind SQL Injection attack Verifying Profile with invalid userid User details not found Same as expected Pass

2 Blind SQL Injection attack Verifying profile with valid userid User details found and displayed Same as expected Pass

3Blind SQL

Injection Attackuser id = 75 and 1=2

User Details Not found

So there is a chance of attackSame as expected Pass

4Blind SQL

Injection Attackuserid=75 and 1=1

So hacker can confirm that

attack has happenedSame as expected Pass

5Blind SQL

Injection Attack

userid=75 and

substring(@@version, 1, 3)=5.1

User Details not found.So hacker can confirm

that his guess about sql version is not corrrect.Same as expected Pass

6Blind SQL

Injection Attack

userid = 22 and




7Blind SQL

Injection Attack

userid = 22 and

substring(@@version, 1, 3)=10

User Details displayed

So the SQL version predicted is correctSame as expected Pass

8Blind SQL

Injection Attack

userid = 22 and

substring(DATABASE(), 1, 1)=’s’



9Blind SQL

Injection Attack

userid = 22 and

substring(DATABASE(), 1, 1)=’t’



10Blind SQL

Injection Attackuserid = 75-SLEEP(10)

Execution time is long 30 seconds


sql util functions are executing

Same as expected Pass

11Blind SQL

Injection Attack

userid = 22-

IF(substring(VERSION(),1,1) = ’10’, SLEEP(15), 0)

Execution time is long 15 seconds


sql util functions are executing

and the mySQL version is 5


12Blind SQL

Injection Attack

userid = 22-


User details not found.

So the hacker can confirm that the

mySQL version isn’t 1


13Blind SQL

Injection Attack

userid = 22-

IF(substring(DATABASE(),1,1) = ’s’, SLEEP(15), 0)



mySQL version isn’t s


14Blind SQL

Injection Attack

userid = 22-

IF(substring(DATABASE(),1,1) = ’t’, SLEEP(15), 0)



mySQL version isn’t t


49

Table 8. Summary of Test cases for Blind SQL Injection Attack (With parameterized

Queries)S.no Type of Attack Input Expected Result Actual Result Status

1 Blind SQL Injection attack Verifying Profile with invalid userid User details not found Same as expected Pass

2 Blind SQL Injection attack Verifying profile with valid userid User details found and displayed Same as expected Pass

3Blind SQL

Injection Attackuser id = 75 and 1=2

User Details Not found

So there is a chance of attackSame as expected Pass

4Blind SQL

Injection Attackuserid=75 and 1=1

User Details not found.

There is no chance of attackSame as expected Pass

5Blind SQL

Injection Attack

userid=75 and




6Blind SQL

Injection Attack

userid = 22 and




7Blind SQL

Injection Attack

userid = 22 and

substring(@@version, 1, 3)=10



8Blind SQL

Injection Attack

userid = 22 and

substring(DATABASE(), 1, 1)=’s’



9Blind SQL

Injection Attack

userid = 22 and

substring(DATABASE(), 1, 1)=’t’



10Blind SQL

Injection Attackuserid = 75-SLEEP(10)



11Blind SQL

Injection Attack

userid = 22-




12Blind SQL

Injection Attack

userid = 22-




13Blind SQL

Injection Attack

userid = 22-

IF(substring(DATABASE(),1,1) = ’s’, SLEEP(15), 0)



14Blind SQL

Injection Attack

userid = 22-

IF(substring(DATABASE(),1,1) = ’t’, SLEEP(15), 0)



50

CHAPTER 5

CONCLUSION AND FUTURE WORK

This work implements an efficient technique to prevent SQLIAs and session

hijacking attack. The implementation uses hashing technique which is computation-

ally light. The proposed technique effectively prevents SQLIAs and session hijacking

attack without much over head on the application. In this work parameterized

queries are used to avoid blind SQLIAs. The hashing technique and the parame-

terized queries have been tested against 75 test cases. The application behaved as

predicted against all these test cases.

Session Hijacking attack is handled by hashing the details of the browser

in which the session has been established. When the cookies have been used in a

different browser, the session isn’t established.

In future the proposed technique can be further improved to avoid IP spoofing

attack, as the prevention technique for session hijacking includes the use of IP address

of the host as a parameter input to the hash digest generation. This host IP address

can be spoofed. Since the hash digest that is stored in the database is same for the

authentication query at any point of time, it can be updated from time to time by

using a time-out. This helps in avoiding the attacker from guessing the hash value.

51

REFERENCES

[1] Alabrah, A., and Bassiouni, M. Preventing session hijacking in collabo-

rative applications with hybrid cache-supported one-way hash chains. In 10th

IEEE International Conference on Collaborative Computing: Networking, Ap-

plications and Worksharing (Oct 2014), pp. 27–34.

[2] Appiah, B., Opoku-Mensah, E., and Qin, Z. Sql injection attack detection

using fingerprints and pattern matching technique. In 2017 8th IEEE Interna-

tional Conference on Software Engineering and Service Science (ICSESS) (Nov

2017), pp. 583–587.

[3] B.SHAH, C., and PANCHAL, D. R. Secured hash algorithm-1:review pa-

per. In International Journal for advance research in engineering and technology

(Oct 2014), pp. 1–6.

[4] Focardi, R., Luccio, F. L., and Squarcina, M. Fast sql blind injections

in high latency networks. In 2012 IEEE First AESS European Conference on

Satellite Telecommunications (ESTEL) (Oct 2012), pp. 1–6.

[5] Ghafarian, A. A hybrid method for detection and prevention of sql injection

attacks. In 2017 Computing Conference (July 2017), pp. 833–838.

[6] Lounis, O., Guermeche, S. E. B., Saoudi, L., and Benaicha, S. E.

A new algorithm for detecting sql injection attack in web application. In 2014

Science and Information Conference (Aug 2014), pp. 589–594.

[7] Ludinard, R., Totel, ., Tronel, F., Nicomette, V., Kaniche, M.,

Alata, ., Akrout, R., and Bachy, Y. Detecting attacks against data in

52

web applications. In 2012 7th International Conference on Risks and Security

of Internet and Systems (CRiSIS) (Oct 2012), pp. 1–8.

[8] Maraj, A., Rogova, E., Jakupi, G., and Grajqevci, X. Testing tech-

niques and analysis of sql injection attacks. In 2017 2nd International Confer-

ence on Knowledge Engineering and Applications (ICKEA) (Oct 2017), pp. 55–

59.

[9] Mavromoustakos, S., Patel, A., Chaudhary, K., Chokshi, P., and

Patel, S. Causes and prevention of sql injection attacks in web applications.

In Proceedings of the 4th International Conference on Information and Network

Security (New York, NY, USA, 2016), ICINS ’16, ACM, pp. 55–59.

[10] Pandurang, R. M., and Karia, D. C. A mapping-based podel for pre-

venting cross site scripting and sql injection attacks on web application and

its impact analysis. In 2015 1st International Conference on Next Generation

Computing Technologies (NGCT) (Sept 2015), pp. 414–418.

[11] Temeiza, Q., Temeiza, M., and Itmazi, J. A novel method for prevent-

ing sql injection using sha-1 algorithm and syntax-awareness. In 2017 Joint

International Conference on Information and Communication Technologies for

Education and Training and International Conference on Computing in Arabic

(ICCA-TICET) (Aug 2017), pp. 1–4.

[12] Umar, K., Sultan, A. B., Zulzalil, H., Admodisastro, N., and Ab-

dullah, M. T. Prevention of attack on islamic websites by fixing sql injection

vulnerabilities using co-evolutionary search approach. In The 5th International

Conference on Information and Communication Technology for The Muslim

53

World (ICT4M) (Nov 2014), pp. 1–6.

[13] Xiao, Z., Zhou, Z., Yang, W., and Deng, C. An approach for sql in-

jection detection based on behavior and response analysis. In 2017 IEEE 9th

International Conference on Communication Software and Networks (ICCSN)

(May 2017), pp. 1437–1442.

a technique for preventing sql injection attack and ...sci.tamucc.edu/~cams/projects/533.pdf · 1.3...

Documents