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.2 Session Hijacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
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 Session Hijacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
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
2.2 Session Hijacking
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 $||$
Browser Major Version $||$ Browser Minor Version)
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 $||$
Browser Major Version $||$ Browser Minor Version)
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);
SecuredVerifyLogin verifyLogin = new SecuredVerifyLogin();
int result = verifyLogin.verifyLogin("test1", 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);
int result = verifyLogin.verifyLogin("test1", input);
Assert.assertEquals(result, -1);
}
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() {
UserRegistrationSecured userRegistration = new
UserRegistrationSecured();
int inserted = userRegistration.addUser("test", "test", "test",
Assert.assertEquals(1, inserted);
}
@Test(dependsOnMethods = { "testRegistration" }, groups = {
"securedregistration" })
public void testRegistrationSecondTime() {
UserRegistrationSecured userRegistration = new
UserRegistrationSecured();
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.
@Test(dependsOnGroups = { "securedregistraion" })
public void verifySecuredLoginwithTautologyAttack1() throws Exception {
String input = "’ OR 1 = 1-- ";
LogMessage.logMessage("Verfying login with tatutology attack with
input " + input);
SecuredVerifyLogin verifyLogin = new SecuredVerifyLogin();
int result = verifyLogin.verifyLogin("test1", input);
Assert.assertEquals(result, -1);
}
@Test(dependsOnGroups = { "securedregistraion" })
public void verifySecuredLoginwithTautologyAttack2() throws Exception {
String input = "’ OR 1 = 1 and 1-- ";
LogMessage.logMessage("Verifying login with tautology attack with
input " + input);
SecuredVerifyLogin verifyLogin = new SecuredVerifyLogin();
34
int result = verifyLogin.verifyLogin("test1", input);
Assert.assertEquals(result, -1);
}
@Test(dependsOnGroups = { "securedregistraion" })
public void verifySecuredLoginwithTautologyAttack3() throws Exception {
String input = "’ OR 1 || 1 and 1-- ";
LogMessage.logMessage("Verifying login with tautology attack with
input " + input);
SecuredVerifyLogin verifyLogin = new SecuredVerifyLogin();
int result = verifyLogin.verifyLogin("test1", input);
Assert.assertEquals(result, -1);
}
@Test(dependsOnGroups = { "securedregistraion" })
public void verifySecuredLoginwithTautologyAttack4() throws Exception {
String input = "’ OR 1 && 1 = 1-- ";
LogMessage.logMessage("Verifying login with tautology attack with
input " + input);
SecuredVerifyLogin verifyLogin = new SecuredVerifyLogin();
int result = verifyLogin.verifyLogin("test1", input);
Assert.assertEquals(result, -1);
}
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
4.5 Session Hijacking
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
username = ’test1’
Password = ”OR 10 between 1 and 100–’Login Allowed Same as expected Pass
3SQL Injection
Tautology Attack
username = ’test1’
Password = ”OR id between 1 and 100–’Login Allowed Same as expected Pass
4SQL Injection
Tautology Attack
username = ’test1’
Password = ”%00’ OR 10 between 1 and 100–’Login Allowed Same as expected Pass
5SQL Injection
Tautology Attack
username = ’test1’
Password = ” OR ASCII(SUBSTRING(’a’,1,1))=97–’Login Allowed Same as expected Pass
6SQL Injection
Tautology Attack
username = ’test1’
Password = ”OR ”=”’Login Allowed Same as expected Pass
7SQL Inejction
Tautology Attack
username = ’test1’
Password = ”OR 1=1 and 1–’Login Allowed Same as expected Pass
8SQL Inejction
Tautology Attack
username = ’test1’
Password = ”OR 1—— 1=1–’Login Allowed Same as expected Pass
9SQL Inejction
Tautology Attack
username = ’test1’
Password = ”OR 1 && 1 = 1–’Login Allowed Same as expected Pass
10SQL Inejction
Tautology Attack
username = ’test1’
Password = ”OR 2>1–’Login Allowed Same as expected Pass
11SQL Injection
Tautology Attack
username = ’test1’
Password = ’xx’ OR ’x’=’x’Login Allowed Same as expected Pass
12SQL Injection
Tautology Attack
username = ’test1’
Password = ”OR ’ABCD’=’ABC’+’d’ ’Login Allowed Same as expected Pass
13SQL Injection
Tautology Attack
username = ’test1’
Password = ”OR ’ABCD’>’A’– ’Login Allowed Same as expected Pass
14SQL Injection
Tautology Attack
username = ’test1’
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
username = ’test1’
Password = ”OR 1=1–’Attack Detected Same as expected Pass
2SQL Injection
Tautology Attack
username = ’test1’
Password = ”OR 10 between 1 and 100–’Attack Detected Same as expected Pass
3SQL Injection
Tautology Attack
username = ’test1’
Password = ”OR id between 1 and 100–’Attack Detected Same as expected Pass
4SQL Injection
Tautology Attack
username = ’test1’
Password = ”%00’ OR 10 between 1 and 100–’Attack Detected Same as expected Pass
5SQL Injection
Tautology Attack
username = ’test1’
Password = ” OR ASCII(SUBSTRING(’a’,1,1))=97–’Attack Detected Same as expected Pass
6SQL Injection
Tautology Attack
username = ’test1’
Password = ”OR ”=”’Attack Detected Same as expected Pass
7SQL Inejction
Tautology Attack
username = ’test1’
Password = ”OR 1=1 and 1–’Attack Detected Same as expected Pass
8SQL Inejction
Tautology Attack
username = ’test1’
Password = ”OR 1—— 1=1–’Attack Detected Same as expected Pass
9SQL Inejction
Tautology Attack
username = ’test1’
Password = ”OR 1 && 1 = 1–’Attack Detected Same as expected Pass
10SQL Inejction
Tautology Attack
username = ’test1’
Password = ”OR 2>1–’Attack Detected Same as expected Pass
11SQL Injection
Tautology Attack
username = ’test1’
Password = ’xx’ OR ’x’=’x’Attack Detected Same as expected Pass
12SQL Injection
Tautology Attack
username = ’test1’
Password = ”OR ’ABCD’=’ABC’+’d’ ’Attack Detected Same as expected Pass
13SQL Injection
Tautology Attack
username = ’test1’
Password = ”OR ’ABCD’>’A’– ’Attack Detected Same as expected Pass
14SQL Injection
Tautology Attack
username = ’test1’
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
username = ’test1’
Password = ”;drop table admin–’
User not found in database
Table in the database deletedSame as expected Pass
2SQL Injection
PiggyBack Attack
username = ’test1’
Password = ”; drop /* this is */ table /* sql injection */ admin – ’
User not found in database
Table in the database deletedSame as expected Pass
3SQL Injection
PiggyBack Attack
username = ’test1’
Password = ”; drop ’,, table admin – ’
User not found in database
Table in the database deletedSame as expected Pass
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
username = ’test1’
Password = ”;drop table admin–’
User not found in database
Table in the database is securedSame as expected Pass
2SQL Injection
PiggyBack Attack
username = ’test1’
Password = ”; drop /* this is */ table /* sql injection */ admin – ’
User not found in database
Table in the database is securedSame as expected Pass
3SQL Injection
PiggyBack Attack
username = ’test1’
Password = ”; drop ’,, table admin – ’
User not found in database
Table in the database is securedSame as expected Pass
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
username = ’test1’
Password = ” Union select * from login – ’User Found in Database Same as expected Pass
2SQL Injection
Union Attack
username = ’test1’
Password = ’ ’ UNION SELECT null,null,null,null from login – ’User found in Database Same as expected Pass
3SQL Injection
Union Attack
username = ’test1’
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
username = ’test1’
Password = ” Union select * from login – ’User not found in Database Same as expected Pass
2SQL Injection
Union Attack
username = ’test1’
Password = ’ ’ UNION SELECT null,null,null,null from login – ’User not found in Database Same as expected Pass
3SQL Injection
Union Attack
username = ’test1’
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
substring(@@version, 1, 3)=5.6
User Details not found.So hacker can confirm
that his guess about sql version is not corrrect.Same as expected Pass
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’
User Details not found.So hacker can confirm
that his guess about sql version is not corrrect.Same as expected Pass
9Blind SQL
Injection Attack
userid = 22 and
substring(DATABASE(), 1, 1)=’t’
User Details not found.So hacker can confirm
that his guess about sql version is not corrrect.Same as expected Pass
10Blind SQL
Injection Attackuserid = 75-SLEEP(10)
Execution time is long 30 seconds
So hacker can confirm that
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
So hacker can confirm that
sql util functions are executing
and the mySQL version is 5
Same as expected Pass
12Blind SQL
Injection Attack
userid = 22-
IF(substring(VERSION(),1,1) = ’1’, SLEEP(15), 0)
User details not found.
So the hacker can confirm that the
mySQL version isn’t 1
Same as expected Pass
13Blind SQL
Injection Attack
userid = 22-
IF(substring(DATABASE(),1,1) = ’s’, SLEEP(15), 0)
User details not found.
So the hacker can confirm that the
mySQL version isn’t s
Same as expected Pass
14Blind SQL
Injection Attack
userid = 22-
IF(substring(DATABASE(),1,1) = ’t’, SLEEP(15), 0)
User details not found.
So the hacker can confirm that the
mySQL version isn’t t
Same as expected Pass
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
substring(@@version, 1, 3)=5.1
User Details not found.
There is no chance of attackSame as expected Pass
6Blind SQL
Injection Attack
userid = 22 and
substring(@@version, 1, 3)=5.6
User Details not found.
There is no chance of attackSame as expected Pass
7Blind SQL
Injection Attack
userid = 22 and
substring(@@version, 1, 3)=10
User Details not found.
There is no chance of attackSame as expected Pass
8Blind SQL
Injection Attack
userid = 22 and
substring(DATABASE(), 1, 1)=’s’
User Details not found.
There is no chance of attackSame as expected Pass
9Blind SQL
Injection Attack
userid = 22 and
substring(DATABASE(), 1, 1)=’t’
User Details not found.
There is no chance of attackSame as expected Pass
10Blind SQL
Injection Attackuserid = 75-SLEEP(10)
User Details not found.
There is no chance of attackSame as expected Pass
11Blind SQL
Injection Attack
userid = 22-
IF(substring(VERSION(),1,1) = ’10’, SLEEP(15), 0)
User Details not found.
There is no chance of attackSame as expected Pass
12Blind SQL
Injection Attack
userid = 22-
IF(substring(VERSION(),1,1) = ’1’, SLEEP(15), 0)
User Details not found.
There is no chance of attackSame as expected Pass
13Blind SQL
Injection Attack
userid = 22-
IF(substring(DATABASE(),1,1) = ’s’, SLEEP(15), 0)
User Details not found.
There is no chance of attackSame as expected Pass
14Blind SQL
Injection Attack
userid = 22-
IF(substring(DATABASE(),1,1) = ’t’, SLEEP(15), 0)
User Details not found.
There is no chance of attackSame as expected Pass
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.