A Study on SQL Injection and XSS Attacks

Project Report Submitted in Partial Fulfilment of the Requirements for the Degree of

Bachelor of Engineering
In
Information Technology

Submitted by
Shashank Sharma: (Roll No.16ITE38031)

Under the Supervision of

Ms. Simran Choudhary
Assistant Professor

Department of Computer Science and Engineering

M.B.M Engineering College
Faculty of Engineering & Architecture
Jai Narain Vyas University, Jodhpur

April, 2019
 Department of Computer Science & Engineering
M.B.M. Engineering College, Jai Narain Vyas University
Ratanada, Jodhpur, Rajasthan, India –342011

CERTIFICATE

This is to certify that the work contained in this report entitled “A Study on SQL Injection
and XSS Techniques” is submitted by Mr. Shashank Sharma (Roll. No: 16ITE38031) to the
Department of Computer Science & Engineering, M.B.M. Engineering College, Jodhpur, for
the partial fulfilment of the requirements for the degree of Bachelor of Engineering in
Information Technology.

They have carried out their study under my supervision. This work has not been submitted
else-where for the award of any other degree or diploma.

The project work in my opinion, has reached the standard fulfilling of the requirements for
the degree of Bachelor of Engineering in Information Technology in accordance with the
regulations of the Institute.

Prof. Simran Choudhary

Assistant Professor
(Supervisor)
Dept. of Computer Science & Engineering,
M.B.M. Engineering College, Jodhpur

Prof. Anil Gupta

(HOD)
Dept. of Computer Science & Engineering,
M.B.M. Engineering College, Jodhpur

2
 DECLARATION

I Shashank Sharma hereby declare that this seminar titled “Study of SQL Injection
and XSS attacks” is a record of study done by me under the supervision and
guidance of Prof. Simran Choudhary Mam.

I, further certify that this report has not formed the basis for the award of the Degree
or similar recognition to any candidate of any university and no part of this report is
reproduced as it is from any other source without appropriate reference and
permission.

(Shashank Sharma)
7th Semester, IT
Enrol. Number – 15R/0005630
Roll No. – 16ITE38031

3
 ACKNOWLEDGEMENT

I, Shashank Sharma take immense pleasure in thanking Dr. Anil Gupta, Head of the
Department, Computer Science & Engineering, MBM Engineering College, Jodhpur for
permitting us to carry out this seminar report and for support and facilities made available.

I wish to express my deep sense of gratitude to Prof. Simran Choudhary Mam, Mentor, for
her able guidance and useful suggestions, which helped me in completing the seminar work,
in time. Her guidance, encouragement, suggestion and very constructive criticism have
contributed immensely to the evolution of my ideas on the report. I have highly benefited by
this report and have gained a lot of knowledge.

Finally, yet most importantly, I would like to express my heartfelt thanks to my beloved
parents and family for their blessings, wishes and support for the successful completion of
this report.

4
 ABSTRACT
In modern days, cyber threats and attacks are triggered to corrupt or steal the information of a
person in huge volume of data from different lines of businesses. Across the globe, nowadays
it became mandatory to protect the database from security related attacks.

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. The solutions proposed in the literature address some of the important
issues related to code injection attacks. I have carried out an extensive review of the SQL
Injection and XSS Attacks. For each type of attack, a provision, descriptions and examples of
how attacks of that type could be performed. Moreover presentation and analysis on existing
prevention techniques against code injection attacks has been done.

SQL injection is a familiar and most vulnerable threat which may exploit the entire database
of any organization, where code is injected in a web page. This code injection technique is
used to attack data-driven web applications. A SQL statement will be altered in such a
manner, which goes with ALWAYS TRUE as constraint.

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in

web applications. XSS enables attackers to inject client-side scripts into web pages viewed by
other users. Cross-site scripting carried out on websites accounted for roughly 84% of all
security vulnerabilities documented by Symantec as of 2007. XSS effects vary in range from
petty nuisance to significant security risk, depending on the sensitivity of the data handled by
the vulnerable site and the nature of any security mitigation implemented by the site's owner.

5
Contents
1. Introduction to Injection Attacks 8

1.1 Code Injection

1.2 SQL Injection Techniques
1.3 Cross Site Scripting Attacks
2. Introduction to SQLI Attacks 11

2.1 On Basis of Execution Nature of Injection

2.2 On Basis of Goal or Purpose
3. SQL Injection Techniques 16

3.1 In-band SQLi

3.2 Inferential (Blind) SQLi
3.3 Out of Band SQLi
4. Prevention Techniques and Tools 21

4.1 Prevention Techniques

4.2 SQL Injection Prevention Tools
5. Cross Site Scripting (XSS) Attacks 26

5.1 Types of XSS Attacks

6. Prevention Techniques and Tools 30

6.1 XSS Prevention Rules

6.2 XSS Prevention Rules Summary
6.3 Output Encoding Rules Summary
6.4 XSS Prevention Tools
7. Conclusion and Future Works 34

8. References 35

6
List of Figures

2.1 Illustration of SQL Injection 11

2.2 Tautological SQL Attack 14
3.1 Types of SQL Injections 16
4.1 Impact of SQL Injection 22
5.1 Illustration of XSS Attacks 26
5.2 Example of Persistent XSS Attack 28

7
Chapter 1
Introduction

1.1 Code Injection

Code injection is the exploitation of a computer bug that is caused by processing invalid
data. Injection is used by an attacker to introduce (or "inject") code into a
vulnerable computer program and change the course of execution. The result of successful
code injection can be disastrous, for example by allowing computer worms to propagate.
Code Injection Attack is a type of exploitation caused by processing invalid data input and
generally take advantage 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
include:
 Web Level
 Application/Database Level
 Operating System 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 3 main types of code injection attacks are as listed below:-

8
  SQL Injections: 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 Injections: Various types of code injection attacks which allow an

attacker to supply code to the server side scripting engine.

 Shell Injections: 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.

1.2 SQL Injection Techniques

SQL injection is a code injection technique, used to attack data-driven applications, in

which diabolical SQL statements are inserted into an entry field for execution (e.g. to
dump the database contents to the attacker). SQL injection must exploit a security
vulnerability in an application's software, for example, when user input is either
incorrectly filtered for string literal escape characters embedded in SQL statements or
user input is not strongly typed and unexpectedly executed. SQL injection is mostly
known as an attack vector for websites but can be used to attack any type of SQL
database.

SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause
repudiation issues such as voiding transactions or changing balances, allow the complete
disclosure of all data on the system, destroy the data or make it otherwise unavailable,
and become administrators of the database server.

9
1.3 Cross Site Scripting (XSS) Attacks

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts
are injected into otherwise benign and trusted websites. XSS attacks occur when an
attacker uses a web application to send malicious code, generally in the form of a
browser side script, to a different end user. Flaws that allow these attacks to succeed are
quite widespread and occur anywhere a web application uses input from a user within
the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end
user’s browser has no way to know that the script should not be trusted, and will
execute the script. Because it thinks the script came from a trusted source, the malicious
script can access any cookies, session tokens, or other sensitive information retained by
the browser and used with that site. These scripts can even rewrite the content of the
HTML pages.

10
 Seminar Report (B.E.)

Chapter 2
Introduction to SQLI Attacks
A SQL injection attack consists of insertion or "injection" of a SQL query via the input data
from the client to the application. A successful SQL injection exploit can read sensitive data
from the database, modify database data (Insert/Update/Delete), execute administration
operations on the database (such as shutdown the DBMS), recover the content of a given file
present on the DBMS file system and in some cases issue commands to the operating system.
SQL injection attacks are a type of injection attack, in which SQL commands are injected into
data-plane input in order to effect the execution of predefined SQL commands.

Fig 2.1 Illustration of SQL Injection

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.

Chapter 2 11
 Seminar Report (B.E.)

TYPES OF ATTACKS

The impact of SQL injection attacks may vary from gathering of sensitive data to manipulating
database information, and from executing system-level commands to denial of service of the
application. The impact also depends on the database on the target machine and the roles and
privileges the SQL statement runs with.

2.1 On Basis of Execution Nature of Injection:

1. First Order attacks
2. Second Order attacks

2.1.1 First Order attacks

First order attacks are those attacks when the attacker receives the desired result
immediately, either by direct response from the application they are interacting with or
through some other response mechanism, such as e-mail. For example, suppose a form
ask the email id of the user. If the user provided the correct email id with no extra code
then the query will run properly. But suppose if the user enter a “LIKE” clause with the
email id then the database will return the matching criteria to the user immediately.

SELECT email, password, login_id, full_name FROM members

WHERE email=’ x’ OR full_name LIKE ‘%Bob%’;

Here, the database will return information of any user where the name starts with “Bob”.
As, the attacker is getting the result immediately, this type of attacks are called first order
attacks.

2.1.2 Second Order Attacks

SQL injection attacks that delay execution until a secondary query are known as “second order”.
This means a malicious user can inject a query fragment into a query (that’s not necessarily
vulnerable to injection), and then have that injected SQL execute in a second query
that is vulnerable to SQL injection.

Chapter 2 12
 Seminar Report (B.E.)

This type of attacks often occurs because once data is in the database; it is often thought of as
being clean and is not checked again. However, the data is frequently used in queries where it
can still cause harm.

Consider an application that permits the users to set up some favourite search criteria. When the
user defines the search parameters, the application escapes out all the apostrophes so that a first-
order attack cannot occur when the data for the favourite is inserted into the database. However,
when the user comes to perform the search, the data is taken from the database and used to form
a second query which then performs the actual search. It is this second query which is the victim
of the attack.

For example, if the user types the following as the search criteria:

'; DELETE Orders;--

The application takes this input and escapes out apostrophe so that the final SQL statement
might look like this:

INSERT INTO favourites (UserID, FriendlyName, Criteria) VALUES(123, 'My Attack',

''';DELETE Orders;--')

which is entered into the database without problems. However, when the user selects their
favourite search, the data is retrieved to the application, which forms a new SQL command and
executes that.
The second query to the database, when fully expanded, now looks like this:

SELECT * FROM Products WHERE ProductName = ''; DELETE Orders;--

It will return no results for the expected query, but the company has just lost all of their orders.
These types of attacks are known as second order attacks.

2.2 On Basis of Goal or Purpose

There are different methods of attacks that depending on the goal of attacker are performed
together or sequentially. For a successful SQLIA the attacker should append a syntactically
correct command to the original SQL query.
Now the following classification of SQLIAs in accordance to [1][9] be presented.

Chapter 2 13
 Seminar Report (B.E.)

Tautologies: This type of attack injects SQL tokens to the conditional query statement to be
evaluated always true. This type of attack used to bypass authentication control and access to
data by exploiting vulnerable input field which use WHERE clause.

"SELECT * FROM employee WHERE userid = '112' and password ='aaa' OR '1 '='1

as the tautology statement (1=1) has been added to the query statement so it is always true.

Fig 2.2 Tautological SQL Attack

Illegal/Logically Incorrect Queries: When a query is rejected, an error message is

returned from the database including useful debugging information. This error messages help
attacker to find vulnerable parameters in the application and consequently database of the
application. In fact attacker injects junk input or SQL tokens in query to produce syntax error,
type mismatches, or logical errors by purpose.

In this example attacker makes a type mismatch error by injecting the following text into the pin
input field:

1. Original URL: http://www.arch.polimi.itleventil?id nav=8864

2. SQL Injection: http://www.arch.polimLitieventil? id_nav=8864'

3. Error message showed: SELECT name FROM Employee WHERE id =8864\'

From the message error we can find out name of table and fields: name; Employee; id. By the
gained information attacker can organize more strict attacks.

Chapter 2 14
 Seminar Report (B.E.)

Union Query: By this technique, attackers join injected query to the safe query by the word
UNION and then can get data about other tables from the application.

Piggy-backed Queries: In this type of attack, intruders exploit database by the query
delimiter, such as ";", to append extra query to the original query. With a successful attack
database receives and execute a multiple distinct queries. Normally the first query is legitimate
query, whereas following queries could be illegitimate. So attacker can inject any SQL
command to the database.

Stored Procedure: Stored procedure is a part of database that programmer could set an extra
abstraction layer on the database. As stored procedure could be coded by programmer, so, this
part is as inject able as web application forms. Depend on specific stored procedure on the
database there are different ways to attack.

Chapter 2 15
 Seminar Report (B.E.)

Chapter 3
SQL Injection Techniques
There are 3 main sub-classes of SQL injection:
 Classic SQLi
 Blind or Inference SQLi
 Out of Band SQLi

Fig 2.2 Types of SQL Injections

3.1 In-band SQLi (Classic SQLi)

In-band SQL Injection is the most common and easy-to-exploit of SQL Injection attacks. In-
band SQL Injection occurs when an attacker is able to use the same communication channel to
both launch the attack and gather results.

3.1.1 Error-based SQLi

Error-based SQLi is an in-band SQL Injection technique that relies on error messages
thrown by the database server to obtain information about the structure of the database. In
some cases, error-based SQL injection alone is enough for an attacker to enumerate an
entire database.
Thus, the attacker can try to match his query with the developers query by using the
information contained in the error messages returned in response by the database server.
While errors are very useful during the development phase of a web application, they
should be disabled on a live site, or logged to a file with restricted access instead.

Chapter 3 16
 Seminar Report (B.E.)

3.1.2 Union-based SQLi

Union-based SQLi is an in-band SQL injection technique that leverages the UNION SQL
operator to combine the results of two or more SELECT statements into a single result
which is then returned as part of the HTTP response.
By appending a union select statement to the parameter, the attacker can test to see if he can
gain access to the database:
For example,

http://example/article.asp?ID=2+union+all+select+name+from+sysobjects

The SQL server then may return the database error similar to this:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14' [Microsoft] [ODBC SQL
Server Driver] [SQL Server] All queries in the SQL statement containing a UNION
operator must have an equal number of expressions in their target lists.

This tells the attacker that he must now guess the correct number of columns for his SQL
statement to work.

3.2 Inferential SQLi (Blind SQLi)

Inferential SQL Injection, unlike in-band SQLi, may take longer for an attacker to exploit.
However, it is just as dangerous as any other form of SQL Injection. In an inferential SQLi
attack, no data is actually transferred via the web application and the attacker would not be able
to see the result of an attack in-band (which is why such attacks are commonly referred to as
“blind SQL Injection attacks”). Instead, an attacker is able to reconstruct the database structure
by sending payloads, observing the web application’s response and the resulting behaviour of
the database server.

Blind SQL injection is nearly identical to normal SQL Injection, the only difference being the
way the data is retrieved from the database. When the database does not output data to the web

Chapter 3 17
 Seminar Report (B.E.)

page, an attacker is forced to steal data by asking the database a series of true or false questions.
This makes exploiting the SQL Injection vulnerability more difficult, but not impossible.

The two types of inferential SQL Injection are Blind-Boolean-based SQLi and Blind-time-based
SQLi.

3.2.1 Boolean-based (content-based) Blind SQLi

Boolean-based SQL Injection is an inferential SQL Injection technique that relies on

sending an SQL query to the database which forces the application to return a different
result depending on whether the query returns a TRUE or FALSE result.

Depending on the result, the content within the HTTP response will change, or remain the
same. This allows an attacker to infer if the payload used returned true or false, even though
no data from the database is returned. This attack is typically slow (especially on large
databases) since an attacker would need to enumerate a database, character by character.

3.2.2 Time-based Blind SQLi

Time-based SQL Injection is an inferential SQL Injection technique that relies on sending
an SQL query to the database which forces the database to wait for a specified amount of
time (in seconds) before responding. The response time will indicate to the attacker whether
the result of the query is TRUE or FALSE.

Depending on the result, an HTTP response will be returned with a delay, or returned
immediately. This allows an attacker to infer if the payload used returned true or false, even
though no data from the database is returned. This attack is typically slow (especially on
large databases) since an attacker would need to enumerate a database character by
character.

Detecting Blind SQL Injection

Executing the following request to a web site:

http://example/article.asp?ID=2+and+1=1

Should return the same web page as:

http://example/article.asp?ID=2

Chapter 3 18
 Seminar Report (B.E.)

because the SQL statement 'and 1=1' is always true.

Executing the following request to a web site:

http://example/article.asp?ID=2+and+1=0

would then cause the web site to return a friendly error or no page at all. This is
because the SQL statement "and 1=0" is always false.

3.3 Out-of-band SQLi

Out-of-band SQL Injection is not very common, mostly because it depends on features being
enabled on the database server being used by the web application. Out-of-band SQL Injection
occurs when an attacker is unable to use the same channel to launch the attack and gather
results.
Out-of-band techniques, offer an attacker an alternative to inferential time-based
techniques, especially if the server responses are not very stable (making an inferential time-
based attack unreliable).

Out-of-band SQLi techniques would rely on the database server’s ability to make DNS or HTTP
requests to deliver data to an attacker. Such is the case with Microsoft SQL Server’s ‘xp_dirtree’
command, which can be used to make DNS requests to a server an attacker controls; as well as
Oracle Database’s UTL_HTTP package, which can be used to send HTTP requests from SQL
and PL/SQL to a server an attacker controls.

Chapter 3 19
 Seminar Report (B.E.)

Chapter 3 20
 Seminar Report (B.E.)

Chapter 4
Prevention Techniques and Tools

4.1 Prevention Techniques

SQL Injection attacks are unfortunately very common, and this is due to two factors:

1. The significant prevalence of SQL Injection vulnerabilities, and

2. The attractiveness of the target (i.e., the database typically contains all the
interesting/critical data for your application).

It’s somewhat shameful that there are so many successful SQL Injection attacks occurring,
because it is EXTREMELY simple to avoid SQL Injection vulnerabilities in your code.

SQL Injection flaws are introduced when software developers create dynamic database queries
that include user supplied input. To avoid SQL injection flaws is simple. Developers need to
either: a) stop writing dynamic queries; and/or b) prevent user supplied input which contains
malicious SQL from affecting the logic of the executed query.

SQL Injection attacks can be easily defeated with simple programming changes, however,
developers must be disciplined enough to apply the following methods to every web accessible
procedure and function. Every dynamic SQL statement must be protected. A single unprotected
SQL statement can result in comprising of the application, data or database server.

Following are some techniques that can be used to prevent SQL Injection attacks:

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.

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.

Chapter 3 21
 Seminar Report (B.E.)

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.

Use Stored Procedures

Stored procedures are not always safe from SQL injection. However, certain standard stored
procedure programming constructs have the same effect as the use of parameterized queries
when implemented safely which is the norm for most stored procedure languages.

1. Never build dynamic SQL statement directly from the user input and never concatenate user
input, with SQL statements, which is not validated.

2. Filter out characters like slash, backslash, extended characters like NULL, carry return, new
line in all strings from user input and parameters from URL.

3. Privileges of the user account used in the application for executing SQL statements on the
database must be defined.

4. Length of the user input should be limited.

Fig 4.1 Impact of SQL Injection

Chapter 3 22
 Seminar Report (B.E.)

4.2 SQL injection Prevention Tools

4.2.1 Acunetix web vulnerability scanner:

Acunetix scanner divides type of scanning according to the severity of the type of web attack. It
divides in four types high, medium, low and informational severity. Acunetix is used to detect
various types of web vulnerabilities as below.

1. SQL injection
2. Cross site scripting
3. CGI scripting
4. Firewalls and SSL
5. URL redirection

SQL injection and Cross site scripting scans are comes under the high severity type as they are
considered most dangerous attacks in the web security. Other attacks are categorized according
to their severity on the web services.

Although this scanner does little bit extra amount of scanning, it is very slow as compare to the
other tool available in market and slower than SQLiX as well.

4.2.2 SQLmap
SQLmap is an SQL injection scanner build in Python. The aim of this tool is to detect SQL
injection vulnerabilities and take advantage of these vulnerabilities on web application. SQLmap
initially detect the loop whole in your site and then use variety of option to perform extensive
back-end database management, enumerate users, dump entire or specific DBMS, retrieve
DBMS session user and database, read specific file on the file system etc.

 SQLmap is bit faster than Acunetix web scanner but still slower than SQLiX, and it also
make very few URL injection in to the database as compare to SQLiX. This tool also
doesn’t have GUI interface.

 SQLmap is an open source software that is used to detect and exploit database
vulnerabilities and provides options for injecting malicious codes into them.[5]

Chapter 3 23
 Seminar Report (B.E.)

 It is a penetration testing tool that automates the process of detecting and exploiting SQL
injection flaws providing its user interface in the terminal.[6]

 SQLmap has full support for multiple DBMSs, including MySQL, Oracle, PostgreSQL,
Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird and SAP MaxDB.

4.2.3 SQLninja

SQLninja is a SQL injection tool that exploits web applications that use a SQL server as a
database server. This tool may not find the injection place at first. But if it is discovered, it can
easily automate the exploitation process and extract the information from the database server.

 This tool can add remote shots in the registry of the database server OS to disable data
execution prevention. The overall aim of the tool is to allow the attacker to gain remote
access to a SQL database server.
 It can also be integrated with Metasploit to get GUI access to the remote database. It also
supports direct and reverse bindshell, both TCP and UDP.
 This tool is not available for Windows platforms. It is only available for Linux,
FreeBSD, Mac OS X and iOS operating systems.

4.2.4 Safe3 SQL Injector

Safe3 SQL injector is another powerful but easy to use SQL injection tool. Like other SQL
injection tools, it also makes the SQL injection process automatic and helps attackers in gaining
the access to a remote SQL server by exploiting the SQL injection vulnerability. It has a
powerful AI system which easily recognizes the database server, injection type and best way to
exploit the vulnerability.
 It supports both HTTP and HTTPS websites. You can perform SQL injection via GET,
POST or cookies. It also supports authentication (Basic, Digest, NTLM HTTP
authentications) to perform a SQL injection attack.
 The tool supports wide range of database servers including MySQL, Oracle,
PostgreSQL, Microsoft SQL Server, Microsoft Access, SQLite, Firebird, Sybase and
SAP MaxDB database management systems.

Chapter 3 24
 Seminar Report (B.E.)

Chapter 5
Cross Site Scripting (XSS) Attacks
Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web
applications. XSS enables attackers to inject client-side scripts into web pages viewed by other
users. A cross-site scripting vulnerability may be used by attackers to bypass access controls
such as the same-origin policy. Cross-site scripting carried out on websites accounted for
roughly 84% of all security vulnerabilities documented by Symantec as of 2007[8]. In 2017,
XSS is still considered a major threat vector.[9] XSS effects vary in range from petty nuisance
to significant security risk, depending on the sensitivity of the data handled by the vulnerable
site and the nature of any security mitigation implemented by the site's owner.

Cross-Site Scripting (XSS) attacks occur when:

1. Data enters a Web application through an untrusted source, such as a web request.
2. The data is included in dynamic content that is sent to a web user without being
validated for malicious content.
The malicious content sent to the web browser often takes the form of a segment of JavaScript,
but may also include HTML, Flash, or any other type of code that the browser may execute. The
variety of attacks based on XSS is almost limitless, but they commonly include transmitting
private data, like cookies or other session information, to the attacker, redirecting the victim to
web content controlled by the attacker, or performing other malicious operations on the user's
machine under the guise of the vulnerable site

Fig 5.1 Illustration of XSS Attack

Chapter 5 25
 Seminar Report (B.E.)

5.1 Types of XSS Attacks

There is no single, standardized classification of cross-site scripting flaws, but most experts
distinguish between at least two primary flavours of XSS flaws: non-persistent and persistent.
Some sources further divide these two groups into traditional (caused by server-side code flaws)
and DOM-based (in client-side code).

5.1.1 Non Persistent (reflected)

The non-persistent (or reflected) cross-site scripting vulnerability is by far the most basic type of
web vulnerability. These holes show up when the data provided by a web client, most
commonly in HTTP query parameters (e.g. HTML form submission), is used immediately by
server-side scripts to parse and display a page of results for and to that user, without
properly sanitizing the request.

Because HTML documents have a flat, serial structure that mixes control statements, formatting,
and the actual content, any non-validated user-supplied data included in the resulting page
without proper HTML encoding, may lead to mark-up injection. A classic example of a
potential vector is a site search engine: if one searches for a string, the search string will
typically be redisplayed verbatim on the result page to indicate what was searched for. If this
response does not properly escape or reject HTML control characters, a cross-site scripting flaw
will ensue.

A reflected attack is typically delivered via email or a neutral web site. The bait is an innocent
looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is
vulnerable to the vector, clicking the link can cause the victim's browser to execute the injected
script.

Example of a non-persistent XSS flaw

Non-persistent XSS vulnerabilities in Google could allow malicious sites to attack Google
users who visit them while logged in.

Chapter 5 26
 Seminar Report (B.E.)

5.2.2 Persistent (Stored)

The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site
scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then
permanently displayed on "normal" pages returned to other users in the course of regular
browsing, without proper HTML escaping. A classic example of this is with online message
boards where users are allowed to post HTML formatted messages for other users to read.

For example, suppose there is a dating website where members scan the profiles of other
members to see if they look interesting. For privacy reasons, this site hides everybody's real
name and email. These are kept secret on the server. The only time a member's real name and
email are in the browser is when the member is signed in, and they can't see anyone else's.

Persistent XSS vulnerabilities can be more significant than other types because an attacker's
malicious script is rendered automatically, without the need to individually target victims or lure
them to a third-party website. Particularly in the case of social networking sites, the code would
be further designed to self-propagate across accounts, creating a type of client-side worm.

The methods of injection can vary a great deal; in some cases, the attacker may not even need to
directly interact with the web functionality itself to exploit such a hole.

Fig 5.2 Example of Persistent XSS Attack

Chapter 5 27
 Seminar Report (B.E.)

Example of a Persistent XSS flaw

A persistent cross-zone scripting vulnerability coupled with a computer worm allowed

execution of arbitrary code and listing of file system contents via a QuickTime movie on
MySpace.

5.2.3 Server-side versus DOM-based vulnerabilities

Historically XSS vulnerabilities were first found in applications that performed all data
processing on the server side. User input (including an XSS vector) would be sent to the server,
and then sent back to the user as a web page. The need for an improved user experience resulted
in popularity of applications that had a majority of the presentation logic (maybe written
in JavaScript) working on the client-side that pulled data, on-demand, from the server
using AJAX.

As the JavaScript code was also processing user input and rendering it in the web page content,
a new sub-class of reflected XSS attacks started to appear that was called DOM-based cross-site
scripting. In a DOM-based XSS attack, the malicious data does not touch the web server.
Rather, it is being reflected by the JavaScript code, fully on the client side.

An example of DOM-based XSS vulnerability is the bug found in 2011 in a number

of JQuery plugins. Prevention strategies for DOM-based XSS attacks include very similar
measures to traditional XSS prevention strategies but implemented in JavaScript code and
contained in web pages (i.e. input validation and escaping).

Some JavaScript frameworks have built-in countermeasures against this and other types of
attack — for example Angular.js

Example of a DOM-based XSS flaw

Before the bug was resolved, Bugzilla error pages were open to DOM-based XSS attacks in
which arbitrary HTML and scripts could be injected using forced error messages.

Chapter 5 28
 Seminar Report (B.E.)

Chapter 6
Prevention Techniques and Tools
6.1 XSS Prevention Rules

The following rules are intended to prevent all XSS in your application. While these rules do not
allow absolute freedom in putting untrusted data into an HTML document, they should cover the
vast majority of common use cases. You do not have to allow all the rules in your organization.
Many organizations may find that allowing only Rule #1 and Rule #2 are sufficient for their
needs. Please add a note to the discussion page if there is an additional context that is often
required and can be secured with escaping.

Do NOT simply escape the list of example characters provided in the various rules. It is NOT
sufficient to escape only that list. Blacklist approaches are quite fragile. The whitelist rules here
have been carefully designed to provide protection even against future vulnerabilities introduced
by browser changes.

6.1.1 Rule #0 - Never Insert Untrusted Data except in Allowed Locations

The first rule is to deny all - don't put untrusted data into your HTML document unless it is
within one of the slots defined in Rule #1 through Rule #5. The reason for Rule #0 is that
there are so many strange contexts within HTML that the list of escaping rules gets very
complicated. We can't think of any good reason to put untrusted data in these contexts. This
includes "nested contexts" like a URL inside a JavaScript -- the encoding rules for those
locations are tricky and dangerous.

6.1.2 Rule #1 - HTML Escape before Inserting Untrusted Data into

HTML Element Content

Rule #1 is for when you want to put untrusted data directly into the HTML body
somewhere. This includes inside normal tags like div, p, b, td, etc. Most web frameworks
have a method for HTML escaping for the characters detailed below. However, this
is absolutely not sufficient for other HTML contexts. You need to implement the other
rules detailed here as well.

6.1.3 RULE #2 - Attribute Escape Before Inserting Untrusted Data into

HTML Common Attributes

Rule #2 is for putting untrusted data into typical attribute values like width, name, value,
etc. This should not be used for complex attributes like href, src, style, or any of the event
handlers like onmouseover. It is extremely important that event handler attributes should
follow Rule #3 for HTML JavaScript Data Values.

Chapter 6 29
 Seminar Report (B.E.)

6.1.4 RULE #3 - Sanitize HTML Markup with a Library Designed for the
Job
If your application handles markup - untrusted input that is supposed to contain HTML -- it
can be very difficult to validate. Encoding is also difficult, since it would break all the tags
that are supposed to be in the input. Therefore, you need a library that can parse and clean
HTML formatted text.

6.2 XSS Prevention Rules Summary

Context Code Sample Defence

HTML
<span>UNTRUSTED DATA </span> HTML Entity Encoding (rule #1).
Body

Aggressive HTML Entity Encoding

(rule #2), Only place untrusted data
Safe
<input type="text" name="fname" into a whitelist of safe attributes
HTML
value="UNTRUSTED DATA "> (listed below), Strictly validate unsafe
Attributes
attributes such as background, id and
name.

<a
GET
href="/site/search?value=UNTRUSTED URL Encoding (rule #5).
Parameter
DATA ">clickme</a>

Untrusted Canonicalize input, URL Validation,

URL in a <a href="UNTRUSTED URL Safe URL verification, Whitelist http
SRC or ">clickme</a> <iframe and https URL's only (Avoid the
HREF src="UNTRUSTED URL " /> JavaScript Protocol to Open a new
attribute Window), Attribute encoder.

Strict structural validation (rule #4),

CSS html <div style="width: UNTRUSTED
CSS Hex encoding, Good design of
Value DATA ;">Selection</div>
CSS Features.

<script>var
Ensure JavaScript variables are
currentValue='UNTRUSTED DATA
Javascript quoted, JavaScript Hex Encoding,
';</script>
Variable JavaScript Unicode Encoding, Avoid
<script>someFunction('UNTRUSTED
backslash encoding (\" or \' or \\).
DATA ');</script>

HTML HTML Validation (JSoup, AntiSamy,

<div>UNTRUSTED HTML</div>
Body HTML Sanitizer...).

<script>document.write("UNTRUSTED
DOM DOM based XSS Prevention Cheat
INPUT: " + document.location.hash
XSS Sheet
);<script/>

Chapter 6 30
 Seminar Report (B.E.)

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of
different contexts.

6.3 Output Encoding Rules Summary

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted
input into a safe form where the input is displayed as data to the user without executing
as code in the browser. The following charts details a list of critical output encoding methods
needed to stop Cross Site Scripting.

Encoding
Encoding Mechanism
Type

HTML Entity Convert & to &amp; Convert < to &lt; Convert > to &gt;
Encoding Convert " to &quot; Convert ' to &#x27; Convert / to &#x2F;

HTML
Except for alphanumeric characters, escape all characters with the HTML
Attribute
Entity &#xHH; format, including spaces. (HH = Hex Value)
Encoding

Standard percent encoding, see here. URL encoding should only be used to
URL Encoding
encode parameter values, not the entire URL or path fragments of a URL.

JavaScript Except for alphanumeric characters, escape all characters with

Encoding the \uXXXX Unicode escaping format (X = Integer).

CSS escaping supports \XX and \XXXXXX. Using a two character escape
can cause problems if the next character continues the escape sequence.
CSS Hex
There are two solutions:
Encoding
(a) Add a space after the CSS escape (will be ignored by the CSS parser)
(b) use the full amount of CSS escaping possible by zero padding the value.

Chapter 6 31
 Seminar Report (B.E.)

6.4 XSS Prevention Tools

6.4.1 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.

6.4.2 HtmlSanitizer

HtmlSanitizer is a .NET library for cleaning HTML fragments and documents from
constructs that can lead to XSS attacks. It uses AngleSharp to parse, manipulate, and render
HTML and CSS.
Because HtmlSanitizer is based on a robust HTML parser it can also shield
you from deliberate or accidental "tag poisoning" where invalid HTML in one fragment can
corrupt the whole document leading to broken layout or style.

6.4.3 OWASP Java HTML Sanitizer

The OWASP HTML Sanitizer is a fast and easy to configure HTML Sanitizer written in
Java which lets you include HTML authored by third-parties in your web application while
protecting against XSS. The existing dependencies are on guava and JSR 305. The other
jars are only needed by the test suite. The JSR 305 dependency is a compile-only
dependency, only needed for annotations. This code was written with security best practices
in mind, has an extensive test suite, and has undergone adversarial security review.

Chapter 6 32
 Seminar Report (B.E.)

Chapter 7
Conclusions and Future Works

Web applications have been deployed to the public with unexpected security holes. The reason
for these security holes is mainly the short time frame of this program’s development. Although
research on security programs is modern, effective solutions are highly demanded because of the
importance of creating programs that are secure and less vulnerable to attacks.

Most of the web applications uses intermediate layer to accept a request from the user and
retrieve sensitive information from the database. Most of the time they use scripting language to
build intermediate layer. To breach security of database hacker often uses SQL injection
techniques. Generally attacker tries to confuse the intermediate layer technology by reshaping
the SQL queries. Perhaps, attacker will change the activities of the programmer for their
benefits. A number of methods are used to avoid SQL injection attack at application level, but
no feasible solution is available yet.

This paper covered most powerful techniques used for SQL

injection prevention. From my research it concludes that automated technique for preventing,
detecting and logging the SQL injection attack in ‘stored procedure' is commonly used and they
are concrete method. Graph control method is also good for small databases systems.

Cross-Site Scripting (XSS) vulnerability is one of the most common security problems in web
applications. It can lead to the stealing of cookies and user accounts and to the transferring of
private data if the input is not validated. While there are many studies have been conducted to
address problems related to XSS vulnerability, but their results seems to be not efficient to
address the problem as well.

Prevention involves enforcing better coding practices and database administration procedures.

 Remember always patch and update holes because exploits are found commonly and the
attacker is not going to wait.

As future work in SQL Injection Prevention, we want to evaluate methods using different
web based application script with public domain to achieve great accuracy in SQL injection
prevention approaches. Also add feature to dump venerable database and database schema.

The future work for XSS Attacks Prevention, should involve the removal stage of the
infeasible paths from the control flow graph that will lead to minimize the false positive rate in
their results and to detect all XSS vulnerability from the source code as well.

Chapter 7 33
 Seminar Report (B.E.)

References

[1] Guide to Technical Report Writing: University of Sussex, Study Guides: School of
Engineering & Informatics, Dr. H. Prance,
http://www.sussex.ac.uk/ei/internal/forstudents/engineeringdesign/studyguides/techrepo
rtwriting, accessed 23 July 2018.

[2] Lee, Inyong, Soonki Jeong, Sangsoo Yeo, and Jongsub Moon. "A novel method for
SQL injection attack detection based on removing SQL query attributes values."
Mathematical and Computer Modelling, Volume 55, Issues 1–2, January 2012, Pages
58–68, 0895-7177/$

[3] Wikipedia Page for Cross Site Scripting, http://en.wikipedia.org/wiki/Cross-

site_scripting

[4] Wiki page of SQL Injections, https://en.wikipedia.org/wiki/SQL_injection, Retrieved

Mar 2019

[5] https://www.unixwiz.net/techtips/sql-injection.html, Retrieved Mar 2019

[6] OWASP Prevention Guidelines, "SQL Injection Prevention Cheat Sheet". OWASP.
Retrieved March 2019

[7] "SQLmap: automatic SQL injection and database takeover tool", Sqlmap.org.
Retrieved 2018-02-25.

[8] "Automated Audit using SQLMap - OWASP", www.owasp.org, Retrieved 2018-01-15.

[9] "SQLmap: automatic SQL injection and database takeover tool", Sqlmap.org,
Retrieved 2018-01-15.

[10] During the second half of 2007, 11,253 site-specific cross-site vulnerabilities were
documented by XSSed, compared to 2,134 "traditional" vulnerabilities documented by
Symantec, in "Symantec Internet Security Threat Report: Trends for July–December
2007 (Executive Summary)" (PDF). XIII. Symantec Corp. April 2008: 1–3.
Retrieved May 11, 2008.

References 34
 Seminar Report (B.E.)

References 35