MADONNA
UNIVERSITY, ELELE CAMPUS
RIVERS
STATE
A
SEMINAR REPORT ON
CODE
INJECTION ATTACK
(SQL
INJECTION)
BY
OMAIYE BENJAMIN OHEPO
CS/12/006
SUBMITTED TO THE
DEPARTMENT OF
COMPUTER SCIENCE
FALCULTY OF SCIENCE
IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE
AWARD OF BARCHELOR OF SCIENCE (B.Sc.)
DEGREE IN COMPUTER SCIENCE
DECEMBER,
2015.
SUPERVISED
BY: MRS ADANMA CELIA EBERENDU
DECLARATION
This is to certify
that this Seminar research on “Code Injection Attack (SQL Injection)” by CS/12/006
Omaiye Benjamin Ohepo has met the conditions for the award of Bachelor of Science
(BSc.) degree in Computer Science, Madonna University Okija, Elele Campus. It
is hereby approved for its contribution to knowledge.
OMAIYE
BENJAMIN OHEPO
DATE
(Name of Student)
MRS. EBERENDU ADAMMA
.C.
DATE
(Supervisor)
DATE
(Head
of Department)
DEDICATION
I dedicate this report
firstly, to God Almighty for his infinite mercies that he has granted me throughout
my stay in Madonna University, also to my family members and many
friends. A special feeling of gratitude to my loving parents, Mr & Mrs
Bernard Omaiye, my wonderful supervisor Mrs Adamma Celia Eberendu whose words
of encouragement and push for tenacity ring in my ears. Finally I will like to
also dedicate my seminar to Madonna University, my learned lecturers, wonderful
course mates, and well-wishers for been there for me.
ACKNOWLEDGEMENT
First and foremost I want
to thank God Almighty for his infinite mercies and grace that kept me going
throughout my studies. With high gratitude to my parents, Mr and Mrs Bernard
Omaiye for their financial and moral support to ensure that my academic pursuit
is a successful one. A special thanks to my supervisor Mrs Adamma Ace Eberendu with
whom my seminar report was a success. Finally, I want to thank all the staffs
and lecturers of Computer Science Department Madonna University, my course
mates, friends and well-wishers that have contributed massively towards my
academic pursuit.
Table of Contents
Chapter 1....................................................................................................................................6
Introduction................................................................................................................................6
1.1 Background of the Study......................................................................................................6
1.1.1 Application of Code Injection Attack...............................................................................7
1.1.2 Some Preventive Measures of Code injection Attacks.....................................................7
1.2 Problem Statement...............................................................................................................8
1.3 Aims & Objective................................................................................................................8
1.4 Significance of the Study.....................................................................................................8
1.5 Scope of Study.....................................................................................................................8
1.6 Limitations...........................................................................................................................9
1.7 Glossary.............................................................................................................................. 9
1.7 Glossary.............................................................................................................................. 9
1.8 Organisation of the Chapters...............................................................................................10
Chapter 2...................................................................................................................................11
Literature Review..................................................................................................................... 11
Chapter 3...................................................................................................................................12
Findings.....................................................................................................................................12
3.1 Brief Understanding on SQL Injection Attack....................................................................12
3.2 Main Types of SQL Injection Mechanism..........................................................................12
3.3 Mode of Operation..............................................................................................................13
3.4 Preventive Measures of SQL injection Attacks..................................................................14
Chapter 4...................................................................................................................................16
Conclusion................................................................................................................................16
Reference
Abstract
Code
Injection Attacks pose a serious security threat to operating system, web and
database applications, they allow attackers to obtain unrestricted access to
the databases underlying the applications and to the potentially sensitive
information these databases contain. Although researchers and practitioners
have proposed various methods to address this issue. Many researchers and
practitioners are familiar with only a subset of the wide range of techniques
available to attackers who are trying to take advantage of code injection attack
vulnerabilities. As a consequence, the solutions proposed in the literature
address only some of the issues related to code injection attack. To address
this problem, a presentation of an extensive review of the different types of
code injection attacks will be carried out. For each type of attack, a
provision, descriptions and examples of how attacks of that type could be
performed. More also presentation and analysis on existing prevention
techniques against code injection attacks. This literature mainly contains an
extensive review of the different types of code injection attacks known to date
and having in mind Structured Query Language injection as a case study.
Chapter 1Introduction
1.1 Background of the Study
Code
Injection Attack is a type of exploitation caused by processing invalid data
input. The concept of Code Injection Attack is to introduce malicious code into
a program so as to change the course of execution. Such an attack may be performed
by adding strings of malicious characters into data values in the form or
argument values in the URL. Code Injection Attack generally take advantages of inadequate
validation over input/output data, for example:
·
Lack
of defining a class of allowed characters (such as standard regular expressions
or custom classes).
·
Lack
of restricting the data format (such as date format dd/mm/yyyy).
·
Lack
of checking the amount of expected data (such as maximum length restriction).
·
Lack
of restricting the data type (such as numerical input only).
Code
Injection Attack is the general name for various types of attacks which inject improper
code into the script interpreter. This can be achieved through different dimensions
which included:
·
Web
Level
·
Application/Database
Level
·
Operating
System (OS) Level
However, with the
dimensions of code injection attack clearly listed above, the main types of
code injection attack can easily be classified under one or more of the
dimensions listed above. The four (4) main types of code injection
attacks are as listed below:-
·
SQL injection: SQL injection is a code injection
technique, used to attack data-driven applications, in which malicious SQL statements are inserted into an
entry field for execution (e.g. to dump the database contents to the attacker).
·
Script injection: Various types of code injection
attacks which allow an attacker to supply code to the server side
scripting engine.
·
Shell injection: Shell
injection (or Command Injection) is named after UNIX shells, but applies
to most systems which allow software to programmatically execute a command
line. This class of attacks exploits applications which use input to formulate
commands that are executed by the OS.
·
Dynamic evaluation: Here in dynamic evaluation,
arbitrary code is
inserted in place of standard input, resulting in that code being executed as
part of the application. Example, Php's
eval(); command will execute PHP code passed to it as a parameter. Also, watch
out for dynamic function and variable evaluation.
1.1.1 Application of Code Injection Attack
Despite the fact that
code injection attack has been seen from a negative aspect of hackers or
malicious user using the means of code injection attack to obtain resources to
which on a normal circumstances they are not allow to access, or using the
means of code injection attack to carry out a prohibited or unwanted act over
the internet or on a user’s computer, code injection still go a long way to
prove some positive usage of it, and they are as follows:
·
Code injection can be used to change or
tweak the behaviour of a program or system that is to "trick" the
system or program into behaving in a certain way without any malicious
intent.
·
Introduce a useful new column that did not appear in the original design
of a search results page.
·
Offer a new way to filter, order, or group data by using a field not
exposed in the default functions of the original design.
·
Code injection attack can be use with programs like Dropbox,
to add special parts that could be used to connect to online resources in an
offline program.
1.1.2 Some Preventive Measures of Code injection Attacks
To prevent code injection problems, utilize
secure input and output handling, such as:
- Using
API which if used properly are secure against all input characters.
Parameterized queries (also known as "Compiled queries",
"prepared statements", "bound variables") allows for
moving user data out of string to be interpreted. Additionally Criteria
API and similar API's move away from the concept of command strings to be
created and interpreted.
- Enforcing
language separation via a static type system.
- Input
validation, such as Whitelisting only accepting known good values
- Input
encoding, e.g. escaping dangerous characters. For instance, in PHP, using
the
htmlspecialchars()
function (converts HTML tags to their ISO-8859-1 equivalents) and/orstrip_tags()
function (completely removes HTML tags) for safe output of text in HTML, andmysql_real_escape_string()
to isolate data which will be included in an SQL request, to protect against SQL Injection. - Output
encoding, i.e. preventing HTML Injection (XSS) attacks against web site
visitors
- Modular
shell disassociation from kernel
The solutions listed above deal primarily with
web-based injection of HTML or script code into a server-side application.
Other approaches must be taken, however, when dealing with injection of user
code on the user machine, resulting in privilege elevation attacks.
1.2 Problem Statement
The
problem statement on SQL injection is as clearly shown below:
·
SQL injection attack been a sophisticated
affair, young programmers and enthusiast who do not know about SQL injection
attacks always have tight corners in implementing preventive measures against
SQL injection in their products.
·
With the influences of new platforms and
systems springing up, malicious attackers always come up with new ideas and
ways in carrying out and implementing their attacks, thus making young
programmers and system designers work extra mile to meet up covering the latest
vulnerabilities.
·
With SQL injection attacks also being a
high security affair, developers who have good knowledge of SQL injection
attack find it very uncomfortable to teach or novice programmers and system designers
what SQL injection attacks is all about due to the fear of being seen as an
attacker.
1.3 Aims & Objective
The main aim of studying
this topic is to create the awareness and also the notion of code injection
attack on several platforms in our modern time to the public, ranging from operating
systems to web base application as the case may be. Taking into consideration
SQL injection which is the highest means of code injection attack.
1.4 Significance of the Study
At the end of this
report one should have been familiar to code injection attack as a whole, how attackers
use it on different platforms, especially SQL injection, dimensions of code
injection attack, types of code injection attacks as well as types of SQL
injection attack, then applications of code injection and several measures that
one can use to reduce or minimize code injection attack.
1.5 Scope of Study
Due
to the diversified nature of code injection attack, the scope of my study will
strictly cover on SQL Injection Attack. However on SQL injection I will cut
across the list given below:-
·
Brief understanding to SQL injection attack.
·
Main Types of SQL Injection Mechanism.
·
Mode of Operation (based on Injection Through User Input).
·
Preventive Measures of SQL injection
Attacks
1.6 Limitations
On the course of my
research on code injection attack, there were limitation which I experienced
that really made the task a little bit difficult for me. Below are some of the
limitation which I came across:-
· Difficulties
with getting access to the internet. Due to the poor internet infrastructure
around in our locality, it’s a tedious task whenever one wants to access the
web, even if you have the best devices in hand, you still can’t access the web
due to poor internet infrastructure
· With
code injection attack been a sophisticated affair, detailed materials are not
much deposited on the internet, thus hindering me on getting on a much more
detailed study.
· Poor
electricity supply was also a crucial issue I faced during my research, it
really hindered me in such a way that the device I used mainly for the research
which is my laptop is an electronic device, thus with poor electricity supply,
I mostly had an idle time.
1.7 Glossary
XSS
(Cross Site Scripting): Is a type of computer security
vulnerability typically found in web applications, it basically enable
malicious attackers to inject client-side script into web pages viewed by other
users.
HTML (Hypertext Markup Language):
Is a language used to specifically encode the content and format of a document
and to also link documents on the worldwide web.
Query: A specific set of
instructions for extracting particular data, or extracting data from a database
and present it for use.
URL (Uniform Resource Locator): An
address for a resource on the Internet. URLs are used by Web browsers to locate
Internet resources on the web.
OSI (Open System Interconnection): is
a conceptual model that characterizes and standardizes the communication
functions of a telecommunication or computing system without regards to their
underlying internal structure and technology.
API (Application Programming
Interface): Is a set of routine, protocols, and tools
for building software applications, it also expresses a software component in
terms of its operation, inputs, outputs, and underlying types.
1.8 Organisation of the Chapters
Here
this part of the literature clearly state the general overview arrangement of
this material, also the contents in which the various segment of the material
contain. Below is the provided organisation of chapters:
In chapter 2, the main content
here is the Literature Review. The literature review basically contain the
interest of what other researchers also feel about SQL injection attack as a
whole. Still on this chapter, basic introductory knowledge about SQL injection
attack was also deposited here. More also, in chapter 3, this is where the main
body of the literature lies, i.e. the Findings. The findings encompasses the
detailed introduction of SQL injection attack, i.e. what SQL injection attack
is. More also, paying attention to the various SQL injection attack mechanism,
the mechanism are basically ways or technique in which SQL injection attack
could be carried out by malicious attackers on victims. Furthermore the mode of
operation of SQL injection attack was also discussed here, and this is just how
SQL injection attack works. With all this in place, the last phase of this
chapter contains the preventive measures of SQL injection attacks, and this is
nothing but ways or things that can be done to prevent SQL injection attacks
from malicious attackers. Furthermore, in chapter 4, this is the last phase of
the document, and it contains mainly the Conclusion of the whole literature.
The conclusion is just simply the summary wrap up, the benefits attached in
carrying out the research study of the topic as given.
Chapter 2Literature Review
I
reviewed a number of documents and gathered some information from web sites to
gain sufficient knowledge about SQL Injection attacks. Following are the materials
from which I covered different important contents on code injection attack SQL
injection attacks:
From the work of
William and his colleagues a detailed introduction and a basic general
understanding of SQL injection attack (William, Jeremy, & Alessandro, 2002) . SQL injection
vulnerabilities have been described as one of the most serious threats for Web
applications, the fact is that it remains the truth. We are aware of how the internet
is growing bigger by the day, it will be on a safer side for every developer to
have this in mind, and also implement preventive measure on the course of
development. The same material still covered types of SQL Injection Mechanism,
the mechanisms provided in the materials are those that are the most frequently
used, also a highlight on cases or circumstances such injection mechanism could
be used.
Also in “Code Injection” by (Joint
Universities Computer Centre Limited, 2012) , here a background
of code injection was generally treated in a brief, and it pin pointed some
inadequate validations that code injection can easily take advantage of, and
the cause of these inadequate validations can be seen from the developers end e.g.
lack of restricting datatypes, with a little neglect of such, a malicious user
or attacker can easily take advantage of that, and the end product will be a
devastating one, so on the long run developer should be careful of such flaws. More
also, the material still went forward to break down code injection attack into
three main dimension (i.e. Web Level,
Application/Database Level and Operating System (OS) Level) with this in place,
what it simply means is that, any form of code injection attack can easily be
classified under one or more of the dimension as listed above, thus making it
possible to easily tell which dimension a code injection attack belongs to.
Furthermore,
according to (Aaron, 2012)
a publication on his website clearly pointed out key preventive measures one
should consider in order to keep away malicious users or attackers who intend
using SQL injection mechanism to carry out their dubious acts on web base
applications. The preventive measure provided here really tallied with the ones
listed by (Joint Universities Computer
Centre Limited, 2012) thus, giving me more rooms to
confidently rely on the preventive measures as provided by (Aaron, 2012) . The most
interesting thing about these preventive measures is that, they a not so
difficult task to implement, that is to say that they can easily be implemented
on the course of development. Also the preventive measure should even be seen
from the perspective of good ethics a developer should even inculcate in his or
herself, so that when such ethics is embedded in a developers mind it will
become a more familiar duty, thus reducing the chances of you product in fallen
a victim of SQL injection attacks.
Chapter 3
Findings
Putting
SQL injection into consideration because it is the most wide spread form of
code injection attack, this section of the literature will focus mainly on SQL
injection attack.
3.1 Brief Understanding on SQL Injection Attack
SQL injection attack has been regarded as one of the
most serious threats to Web based applications. Web based applications that are
vulnerable to SQL injection attack may easily allow an attacker to gain
complete access to their underlying databases. Because these databases mainly
contain sensitive consumer or user information, the resulting security
violations can include identity theft, loss of confidential or private
information, and fraud. In some cases, attackers can even use an SQL injection
to take control of and even corrupt the system that hosts the Web based
application. Web applications that are vulnerable to SQL Injection Attacks
(SQLIAs) are widespread, according to (Erdin, 2013) study shows that on over 300 Internet
Web sites has shown that most of them could be highly vulnerable to SQL
Injection Attack. In fact, SQLIAs have successfully targeted high-profile
victims in our present day.
According to (William, Jeremy, & Alessandro, 2002) SQL injection refers
to a class of code-injection attacks in which data provided by a user is
included in an SQL query in such a way that part of the user’s input is treated
as SQL code. With this, an attacker can submit SQL commands directly to the database.
These attacks are serious threat to any Web based application that receives
input from users and incorporates it into SQL queries to an underlying
database. Most Web based applications used on the Internet or within an enterprise
system works this way and could therefore be vulnerable to SQL injection.
3.2 Main Types of SQL Injection Mechanism
Malicious SQL statements can be introduced into a
vulnerable application using many different input mechanisms, this input mechanism
simply refer to the different ways an attacker can use SQL injection to
transverse through a vulnerable application. In this section, a detailed explanation
will be carried out on the most common mechanisms.
The main types of SQL injection mechanisms alongside
their explanation is as shown below:
·
Injection Through User Input: In this mechanism,
attackers inject SQL commands by providing suitably crafted user input. A Web based
application can read user inputs in several ways based on the environment in
which the application is deployed. In most SQL injection attacks that target
Web based applications, user inputs typically comes from form submissions. Web
base applications are generally capable to access the user inputs contained in
these requests as they would access any other variable in their environment.
·
Injection Through Cookies: Cookies simply are
files that contain state information generated by Web applications and stored
on a client’s machine. When a client returns to a Web application, cookies can be
used to restore the client’s state information. Since the client has control
over the storage of the cookie, a malicious client could tamper with the
cookie’s contents. If a Web application uses the cookie’s contents to build SQL
queries, an attacker could easily submit an attack by embedding it in the
cookie.
·
Injection Through Server Variables: Server variables
are a collection of variables that contains hypertext transfer protocol (HTTP),
network headers, and environmental variables. Web applications use these server
variables in a variety of different ways, such as logging usage statistics, and
identifying browsing trends. If these variables are logged to a database
without sanitization, this could easily create an SQL injection vulnerability. Because
attackers can forge the values that are placed in HTTP and network headers,
they can then exploit this vulnerability by placing an SQLIA directly into the
headers. When the query to log the server variable is issued to the database of
the web application, the attack in the forged header is then triggered.
·
Second-order Injection: In second-order
injections, here attackers inject malicious inputs into a system or database to
indirectly trigger an SQLIA when that input is then used at a later time. The main
objective of this kind of attack differs significantly from the regular first-order
injection attacks. Second-order injections are not trying to cause the attack
to occur when the malicious input injected initially reaches the database.
Instead, attackers rely on knowledge of where the input will be subsequently
used and craft their attacks so that it occurs or take place during that usage.
3.3 Mode of Operation
SQL injection attack takes advantage of the sequential
query language (SQL) syntax to inject commands that can read, modify or alter a
database, or even compromise the meaning of the original query. Here, the use
of one of the SQL injection mechanism called the “Injection Through User Input”, will be used
to properly explain or demonstrate the mode of operation i.e. how SQL injection
attack work or is been carried out.
Figure 1: Pictorial representation of how SQL injection
attack is performed (Woods, 2006)
For example, consider a web page that has two fields on a
form to allow users to enter a Username and also a corresponding Password. The
code behind the page will generate an SQL query to check the password against the list of user names:
Figure 2: Login page
showing Username and Password field
SELECT UserList.Username
FROM UserList
WHERE UserList.Username = 'Username'
AND UserList.Password = 'Password'
If this query returns any rows, then access is granted. However, if the malicious user enters a valid Username and injects some valid code like this ("password' OR '1'='1"
) in the Password field, then the resulting query will look like this:
SELECT UserList.Username
FROM UserList
WHERE UserList.Username = 'Username'
AND UserList.Password = 'password' OR '1'='1'
In the example above,
"Password" is assumed to be blank or can be seen as harmless string.
"
'1'='1'
" will always be
true and many rows will be returned, thereby allowing access. The technique may
be fine-tuned to allow multiple statements to run, or even to load up and run
external programs.3.4 Preventive Measures of SQL injection Attacks
The preventive measures that will be
discussed here shortly, emphasis or concentrate more on SQL injection
preventive measures, but some of the preventive measures can also be applicable
to other types of code injection attack as the case may be. Nevertheless, preventive
measures are basically ways or means in which a developer can easily safeguard
or protect its product from malicious attacks, which in this case is SQL
injection attacks. Below are some of the preventive measures:
·
Input
Validation and Sanitisation: Web sites must
filter all user
input. Ideally, user data should be properly filtered for context. For example,
e-mail addresses should be filtered to allow only the characters allowed in an
e-mail address. Phone numbers should be filtered to allow only the characters
allowed in a phone number, and so on.
· Use
of Web Application Firewall (WAF):
A
Web Application Firewall (“WAF”) is an intermediary device that sits between a
web-client and a web server. The web application firewall analyzes OSI Layer-7
messages (i.e. application layer) for violations in the pre-configured security
policy, and help to filter out malicious data and requests. In general, these
rules cover common attacks such as the cross-site Scripting (“XSS”). In addition,
WAF is particularly useful when using third party developed web based applications,
as the modification of the application source code is not required.
· Appropriate
/ Least User Privileges: Web based applications should never
connect to your database using an account with admin-level privileges (e.g.
“root” account). All application processes should always be executed with the
minimal privileges required. In addition, processes must release privileges as
soon as they no longer require them again. Best practice is to create an
isolated account specifically for each application and then deny access to all
objects that are unnecessary to be used by the applications.
·
Avoid Constructing
SQL Queries With User Input: It is
well known that, even data sanitization
routines can be flawed. Ideally, using SQL variable binding with prepared
statements or stored procedures is much more safer than constructing full
queries.
·
Error Messages Handling: Hackers can easily learn a great deal about a system architecture from
error messages, detailed error information can be used to modify the original
attack, thus increasing the chances of a successful hacking. Therefore, it
should be a necessity for one to display as little information as possible in
error messages. Besides, it is better to use the generic error messages on the
local machine while ensuring that an external hacker only gets nothing more
than the fact that his/her actions resulted in an unhandled error.
Any of the above listed preventive measure significantly reduces the
chances of a successful SQL injection attack. Implementing all of them is a
best practice that will provide an extremely high degree of protection. Despite
its widespread use, a developer’s product does not have to be SQL injection's
next victim.
Chapter 4
With this literature material which can be seen as a mini archive of
knowledge about code injection attack, and to be specific “SQL injection attack”,
one can confidently feel familiar with no fear over issues of SQL injection
attack when it arises. With background ideas on what SQL injection attacks is,
the various types of SQL injection attack, the mode of operation of SQL
injection attack, taking into consideration one of the widely used mechanism
which is “injection through user input” and also with preventive measures that
one can use to protect his or her product from malicious attackers. With all
this in place, young minds and enthusiast who asper to soar high in the various
fields of web technology and security implementation will be more equipped and
also aware of relating security breaches they will interface with in their
various lines of career pursuit.
References
Aaron.
(2012, August 16). How to prevent SQL injection Attacks - eSecurity Planet.
Retrieved from esecurityplanet:
http://www.esecurityplanet.com/hackers/how-to-prevent-sql-injection-attacks.html
Erdin, E.
(2013). Code Injection. Califonia: Golden Press.
Joint
Universities Computer Centre Limited. (2012). Code Injection. A newsletter
for IT Professionals.
William, G. H.,
Jeremy, V., & Alessandro, O. (2002). A Classification of SQL Injection
Attacks and Countermeasures. SQL Injection Attacks and Countermeasures.
Woods, P. (2006,
april 19). introduction to SQL injection attack. Retrieved from
www.simplicable.com: www.simplicable.com/introduction_to_SQL_injection_attack
0 Comments