Academy of Economic Studies

Cybernetics and Economic Informatics Faculty

Computer Science Department

Laboratory 5

Security Testing
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Table of Contents
1.IntRODUCTION .............................................................................................................................................. 3
1.1OBJECTIVES................................................................................................................................................. 3
1.2OVERVIEW .................................................................................................................................................. 3
1.3WHY DO WE NEED SECURITY TESTING? ...................................................................................................... 3
1.4HOW MUCH SECURITY TESTING IS ENOGH? ................................................................................................. 4
2.Top 10 most critical web application security risks ......................................................................................... 5
2.1 SQL INJECTION .......................................................................................................................................... 5
2.2 CROSS-SITE SCRIPTING .............................................................................................................................. 5
2.3 SESSION HIJACKING ................................................................................................................................... 7
2.4 PARAMETER MANIPULATION ..................................................................................................................... 7
2.5 INSECURE STORAGE ................................................................................................................................... 8
2.6 FORCED BROWSING .................................................................................................................................... 8
2.7 CROSS-SITE REQUEST FORGERY .............................................................................................................. 10
2.8 INSECURE CONFIGURATION ...................................................................................................................... 11
2.9 UNCHECKED REDIRECTS .......................................................................................................................... 12
210 USING COMPONENTS WITH KNOWN VULNERABILITIES ............................................................................ 12
3.SQL Injection Flaws practical examples ................................................................................................ 13
3.1 Blind Sql Injection....................................................................................................................................... 13
3.2 NUMERIC SQL INJECTION ........................................................................................................................ 13
3.3 STRING SQL INJECTION ........................................................................................................................... 14
4.TOOLS FOR TESTING .................................................................................................................................... 18
5.Exercises ......................................................................................................................................................... 18
...............................................................................................................................................................................
6.Further readings .............................................................................................................................................. 19
6.Further readings .............................................................................................................................................. 19

Laboratory 3 – Performance Testing

Page 2 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

1. Introduction

In the early days of the Internet, the World Wide Web consisted only of web
sites.These were essentially information repositories containing static documents, and
web browsers were invented as a means of retrieving and displaying those documents.
The flow of interesting information was oneway,from server to browser. Most sites did
not authenticate users, because there was no need to - each user was treated in the
same way and presented with the same information. Any security threats arising from
hosting a web site related largely to vulnerabilities in web server software (of which
there were many). If an attacker compromised a web server, he would not normally gain
access to any sensitive information, because the information held on the server was al-
ready open to public view.

Today, the World Wide Web is almost unrecognizable from its earlier form.
The majority of sites on the web are in fact applications that are accessed by using
a web browser to communicate with a web server. They are highly functional, and rely
upon two-way flow of information between the server and browser.
They support registration and login, financial transactions,search, and the author-
ing of content by users. The content presented to users is generated dynamically on the
fly, and is often tailored to each specific user. Moreover,much of the information pro-
cessed is private and highly sensitive.

1.1 Objectives

Laboratory 3 – Performance Testing

Page 3 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

In today`s seminar we will

• Learn what web security testing is.
• Learn why web security testing matters.
• Understand the key concepts of 10 most critical security risks according to OWASP(Open
Web Application Security Project)
• Learn how to test a Web application against SQL injection.

1.2 Overview
Information security is the practice of defending information from unauthorized ac-
cess,use,disclosure,disruption,modification,perusal,inspection,recording or destruction. There are six
principles to keep in mind all time when it comes to information security:
-Confidentiality: the term used to prevent the disclosure of information to unauthorized individu-
als or system;it is necessary for maintaining the privacy of the people who trust an
application to hold their personal information.
-Integrity: data cannot be modified undetectably; it is violated when a message is actively modi-
fied in transit
-Availability: the information must be available when needed.
-Authenticity: implies the validation of both parties involved (they are who they claim to be)
-Non-repudiation: one party of a transaction cannot deny having received a transaction nor can
other party deny having sent a transaction.

1.3 Why do we need Security testing?

Web applications have been created to perform practically every useful function one could possibly
implement online:
-shopping
-social networking
-banking
-web search
-auctions (eBay)
-gambling
-web logs (blogger)
-web mail
-interactive information (wikipedia)

Web applications bring with them new and significant security threats. Each application is
different and may contain unique vulnerabilities. Most applications are developed in-house, and
many by developers who have little understanding of the security problems that may arise in the
code they are producing. To deliver their core functionality, web applications normally require
connectivity to internal computer systems that contain highly sensitive data and are able to per-
form powerful business functions.
Ten years ago, if you wanted to make a funds transfer, you visited your bank and
someone performed it for you; today, you can visit their web application and perform it yourself.
An attacker who compromises a web application may be able to steal personal information, car-
ry out financial fraud, and perform malicious actions

Laboratory 3 – Performance Testing

Page 4 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

against other users.

1.4 How much security testing in enough?

“There is no security on this Earth. There is only opportunity” - Douglas

MacArthur

In addition to the public internet, web applications have been widely adopted inside organization to
perform key business functions, including accessing HR services and managing company resources. The
content presented to users is generated dynamically on the fly, and is often tailored to each specific user.
Much of the information processed is private and highly sensitive.
Security is therefore a big issue: no one (from usual user to big companies) wants to use a web ap-
plication if they believe their information will be disclosed to unauthorized parties. But in the same time,
little security testing is performed in a software development cycle and few companies are willing to in-
vest more in this field.
Moreover, as with any new class of technology, web applications have brought with them a new
range of security vulnerabilities. The set of most commonly encountered defects has evolved somewhat
over time. New attacks have been conceived that were not considered when existing applications were
developed.
So there is never too much testing on security. As a security specialist you must find a balance be-
tween business, kind of data you work with, time and money allocated for this stage in software develop-
ment process.
In order to understand that there is no totally secure software and that anything can be hacked, the
only inconvenient is the amount of resources you spend on finding the vulnerabilities in order to crack a
system it is important to understand the psychology of a hacker.A hacker looks for reconnaissance and
money from software vulnerabilities, he is willing to spend a lot of resources (time and hardware) in order
to plan the attack, perform it and then to cover tracks. Of course that his objective is to maximize profit
even if he obeys law.

Laboratory 3 – Performance Testing

Page 5 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

2. Top 10 most critical web application Security Risks

2.1 SQL Injection

SQL injection is a technique for exploiting web applications that use client-supplied
data in SQL queries without stripping potentially harmful characters first.
This vulnerability enables an attacker to submit crafted input to interfere with the
application’s interaction with back-end databases. An attacker may be able to retrieve
arbitrary data from the application, interfere with its logic, or execute commands on
the database server itself.

• Vulnerabilities
-Incorrectly filtered escape characters:
This form of SQL injection occurs when user input is not filtered for escape
characters and is then passed into an SQL statement. This results in the
potential manipulation of the statements performed on the database by the end
user of the application.
The following line of code illustrates this vulnerability:
statement = "SELECT * FROM users WHERE name = '" + userName + "';"
This SQL code is designed to pull up the records of the specified
username from its table of users. However, if the "userName" variable is crafted
in a specific way by a malicious user, the SQL statement may do more than the
code author intended. For example, setting the "userName" variable as
a' or 't'='t' renders this SQL statement by the parent language:
SELECT * FROM users WHERE name = 'a' OR 't'='t';
If this code were to be used in an authentication procedure then this
example could be used to force the selection of a valid username because the
evaluation of 't'='t' is always true.
The following value of "userName" in the statement below would cause
the deletion of the "users" table as well as the selection of all data from the
"userinfo" table (in essence revealing the information of every user), using an
API that allows multiple statements:
a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't
This input renders the final SQL statement as follows:
SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT *
FROM userinfo WHERE 't' = 't';
While most SQL server implementations allow multiple statements to be

Laboratory 3 – Performance Testing

Page 6 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

executed with one call in this way, some SQL APIs such as PHP's
mysql_query() do not allow this for security reasons. This prevents attackers
from injecting entirely separate queries, but doesn't stop them from modifying
Queries.
-Incorrectly type handling:
This form of SQL injection occurs when a user supplied field is not
strongly typed or is not checked for type constraints. This could take place when
a numeric field is to be used in a SQL statement, but the programmer makes no
checks to validate that the user supplied input is numeric. For example:
statement := "SELECT * FROM userinfo WHERE id = " + a_variable + ";"
It is clear from this statement that the author intended a_variable to be a
number correlating to the "id" field. However, if it is in fact a string then the end
user may manipulate the statement as they choose, thereby bypassing the
need for escape characters. For example, setting a_variable to 1;DROP TABLE
users will drop (delete) the "users" table from the database, since the SQL would
be rendered as follows:
SELECT * FROM userinfo WHERE id=1;DROP TABLE users;
-Vulnerabilities inside the database server
Sometimes vulnerabilities can exist within the database server software
itself, as was the case with the MySQL server's mysql_real_escape_string()
function.
This would allow an attacker to perform a successful SQL injection attack
based on bad Unicode characters even if the user's input is being escaped.
This bug was patched with the release of version 5.0.22 (released on 24th
May 06).
-Blind SQL injection
Blind SQL Injection is used when a web application is vulnerable to an
SQL injection but the results of the injection are not visible to the attacker. The
page with the vulnerability may not be one that displays data but will display
differently depending on the results of a logical statement injected into the
legitimate SQL statement called for that page.
This type of attack can become time-intensive because a new statement
must be crafted for each bit recovered. There are several tools that can automate
these attacks once the location of the vulnerability and the target information has
been established.

• Preventing:
To protect against SQL injection, user input must not directly be em-
bedded in SQL statements. Instead, parameterized statements must be used (pre-
ferred), or user input must be carefully escaped or filtered.
With most development platforms, parameterized statements can be used
that work with parameters (sometimes called placeholders or bind variables)
instead of embedding user input in the statement. In many cases, the SQL
statement is fixed. The user input is then assigned (bound) to a parameter.
This is an example using Java and the JDBC API:
PreparedStatement prep = conn.prepareStatement("SELECT * FROM
USERS WHERE USERNAME=? AND PASSWORD=?");

Laboratory 3 – Performance Testing

Page 7 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

prep.setString(1, username);
prep.setString(2, password);
prep.executeQuery();
Similarly, in C#:
using (SqlCommand myCommand = new SqlCommand("SELECT * FROM
USERS WHERE USERNAME=@username AND
PASSWORD=HASHBYTES('SHA1',
@password)", myConnection))
{
myCommand.Parameters.AddWithValue("@username", user);
myCommand.Parameters.AddWithValue("@password", pass);
myConnection.Open();
SqlDataReader myReader = myCommand.ExecuteReader())
...................
}

• Tools used for testing

-WebCruiser - Web Vulnerability Scanner
-Rational APPScan
-Acunetix WVS
-SQL NINJA
-SQL MAP

2.2 Cross-site scripting

This vulnerability enables an attacker to target other users of the application, potentially
gaining access to their data, performing unauthorized actions on their behalf, or carrying out

Laboratory 3 – Performance Testing

Page 8 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

other attacks against them.An XSS vulnerability arises when Web applications take data from
users and dynamically include it in Web pages without first properly validating the data.
XSS allows attackers to execute scripts in the victim’s browser which can hijack user
sessions, deface web sites, or redirect the user to malicious sites. Although XSS is enabled by
vulnerable pages in a Web application, the victims of an XSS attack are the application's users,
not the application itself. The potency of an XSS vulnerability lies in the fact that the malicious
code executes in the context of the victim's session, allowing the attacker to bypass normal
security restrictions.

There are different types of cross site scripting:

• Reflective XSS

There are many ways in which an attacker can entice a victim into initiating a re-
flective XSS request. For example, the attacker could send the victim a mislead-
ing email with a link containing malicious JavaScript. If the victim clicks on the
link, the HTTP request is initiated from the victim's browser and sent to the vul-
nerable Web application. The malicious JavaScript is then reflected back to the
victim's browser, where it is executed in the context of the victim user's session.

• Persistent XSS
Consider a Web application that allows users to enter a user name which is dis-
played on each user’s profile page. The application stores each user name in a local
database. A malicious user notices that the Web application fails to sanitize the user
name field and inputs malicious JavaScript code as part of their user name. When oth-
er users view the attacker’s profile page, the malicious code automatically executes in
the context of their session.

Laboratory 3 – Performance Testing

Page 9 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Prevention:
Essentially, prevention means that you follow good coding practice by running sanity
checks on your input to your routines.

The following list outlines the general approaches to prevent cross-site scripting attacks:

-Encode output based on input parameters.

-Filter input parameters for special characters.
-Filter output based on input parameters for special characters.

When you filter or encode, you must specify a character set for your Web pages to
ensure that your filter is checking for the appropriate special characters. The data that is
inserted into your Web pages should filter out byte sequences that are considered spe-
cial based on the specific character set. A popular charset is ISO 8859-1, which was the

Laboratory 3 – Performance Testing

Page 10 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

default in early versions of HTML and HTTP. You must take into account localization
issues when you change these parameters.

Tools:
-x5s is a Fiddler addon
-XSS me, Firefox Add-on

2.3 Session Hijacking

Session Hijacking is the process of taking over a existing active session. One of the main
reason for Hijacking the session is to bypass the authentication process and gain the access to the
machine. Since the session is already active so there is no need of re-authenticating and the
hacker can easily access the resources and sensitive information like passwords, bank details and
much more.
Session Hijacking involves two types of attacks :

• Passive attack
In Passive attack, the hacker Hijacks a session, but just sits back and watch-
es and records all the traffic that is being sent from the computer or received by the com-
puter. This is useful for finding the sensitive information like username passwords of web-
sites, windows and much more...
Passive Session Hijacking involves the use of network sniffing tools that cap-
tures data packet and exploit the vulnerability of ARP protocol by poisoning the network.
Attackers analyze those captured data to retrieve login credentials of the user.
Why we call it passive session hijacking because attackers does not need to in-
teract with the user and make him perform any specific actions. There is less risk of suspi-
cion level.
• Active attack
-Active session Hijacking involves hijacking a already authenticated session.
-Active Session Hijacking means that original user has logged in his account or profile
and then attacker steal the cookies to hijack the active session and then disconnect the origi-
nal user from the server.
In Active Session Hijacking, attackers use client side scripts to steal the origi-
nal users cookies by involving social engineering tactics which includes emails, private mes-
saging on forums and on other social networking websites.
Why we call it active session hijacking because attackers need to interact and
need some actions to be performed by the victim to steal the session successfully which
can raise the suspicion level.

Laboratory 3 – Performance Testing

Page 11 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

2.4 Parameter Manipulation

The Web Parameter Tampering attack is based on the manipulation of parame-

ters exchanged between client and server in order to modify application data, such as
user credentials and permissions, price and quantity of products, etc. Usually, this in-
formation is stored in cookies, hidden form fields, or URL Query Strings, and is used to
increase application functionality and control. This attack can be performed by a mali-
cious user who wants to exploit the application for their own benefit, or an attacker who
wishes to attack a third-person using a Man-in-the-middle attack.

Manipulating the data sent between the browser and the web application to an
attacker's advantage has long been a simple but effective way to make applications do
things in a way the user often shouldn't be able to. In a badly designed and developed
web application, malicious users can modify things like prices in web carts, session to-
kens or values stored in cookies and even HTTP headers.

No data sent to the browser can be relied upon to stay the same unless crypto-
graphically protected at the application layer. Cryptographic protection in the transport
layer (SSL) in no way protects one from attacks like parameter manipulation in which
data is mangled before it hits the wire. Parameter tampering can often be done with:

1. Cookies

2. Form Fields

3. URL Query Strings

4. HTTP Headers

Laboratory 3 – Performance Testing

Page 12 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

2.5 Insecure Storage

Many web applications do not properly protect sensitive data, such as credit
cards, SSNs, and authentication credentials, with appropriate encryption or hashing. At-
tackers may steal or modify such weakly protected data to conduct identity theft, credit
card fraud, or other crimes.
Frequently, encryption techniques are used to protect this sensitive information.
While encryption has become relatively easy to implement and use, developers still fre-
quently make mistakes while integrating it into a web application. Developers may over-
estimate the protection gained by using encryption and not be as careful in securing
other aspects of the site.
A few areas where mistakes are commonly made include:
I. Failure to encrypt critical data
II. Insecure storage of keys, certificates, and passwords
III. Improper storage of secrets in memory
IV. Poor sources of randomness
V. Poor choice of algorithm
VI. Attempting to invent a new encryption algorithm
VII. Failure to include support for encryption key changes and other re-
quired maintenance procedures
The impact of these weaknesses can be devastating to the security of a website.
Encryption is generally used to protect a site’s most sensitive assets, which may be to-
tally compromised by a weakness.

Laboratory 3 – Performance Testing

Page 13 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

2.6 Forced Browsing

Forced Browsing is an attack which is used to access those resources in a web

applications that are not referenced anywhere in the application, but exists. This can be
seen as a Brute force attack in which an attacker try to guess the unlink directory or
page in a website. This attack is also known as File Enumeration. Some other names of
this attack are Predictable Resource Location, Resource Enumeration and Directory
Enumeration. But most common names are Forced browsing and Predictable Resource
Location.

Attacker analyzes the web server HTTP response codes to predict the existence
of a resource. With this attack, attacker search for some secure content of the website
such as source code, backup files, temporary files directory, sample files, log files or
backup files. Generally these files are stored somewhere on the server and can be ac-
cessible easily if directory listing is on. This attack may disclose much valuable infor-
mation about the application to an attacker.

Most common directories names those are easy to guess:

• Admin

• Administrator

• Images

• Backup

• Log

• Scripts

One can verify the security against this vulnerability by applying a proper presen-
tation approach for all URLs in the application.

• Automatic approaches: There are many web vulnerability scanners available

which lists most of the web vulnerabilities. But all those tools have difficulty with ver-
ifying URL access control. So this approach is not going to help you to verify this
vulnerability.

• Manual approaches: Manual approach is most efficient way to verify this vulnera-
bility in the application. This approach uses the combination of code review and se-
curity testing to verify the access control mechanism in the website.
One need to verify each page of the website to check whether the vulnerability ex-
ists or not. If the page is public and accessible to all users, there is no problem. If
the page is private, then it must be checked for this vulnerability. These points must
be checked for a private page:

Laboratory 3 – Performance Testing

Page 14 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

-If proper authentication is required to access this private page?

-If there are multiple user levels, then check whether it is accessible to an authenticated
user who does not have privilege to access the page or not.
-Check whether admin pages are accessible to only admin or all authenticated users.
If vulnerability is found, then use proper ways to patch. If code level protection is used
to patch this vulnerability, verify that code level protection is in place for every required
page of the website.

2.7 Cross-site Request Forgery

CSRF is an attack which forces an end user to execute unwanted actions on a
web application in which he/she is currently authenticated. With a little help of social en-

Laboratory 3 – Performance Testing

Page 15 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

gineering (like sending a link via email/chat), an attacker may force the users of a web
application to execute actions of the attacker's choosing. A successful CSRF exploit can
compromise end user data and operation in case of normal user. If the targeted end us-
er is the administrator account, this can compromise the entire web application.
The attacker can make the victim perform actions that they didn't intend to, such
as logout, purchase item, change account information, retrieve account information, or
any other function provided by the vulnerable website.
Sometimes, it is possible to store the CSRF attack on the vulnerable site itself.
Such vulnerabilities are called Stored CSRF flaws. This can be accomplished by simply
storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex
cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity
of the attack is amplified. In particular, the likelihood is increased because the victim is
more likely to view the page containing the attack than some random page on the Inter-
net. The likelihood is also increased because the victim is sure to be authenticated to
the site already.
Synonyms: CSRF attacks are also known by a number of other names, including
XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Mi-
crosoft refers to this type of attack as a One-Click attack in their threat modeling pro-
cess and many places in their online documentation.
How does the attack work?

There are numerous ways in which an end-user can be tricked into loading information
from or submitting information to a web application. In order to execute an attack, we
must first understand how to generate a malicious request for our victim to execute. Let
us consider the following example: Alice wishes to transfer $100 to Bob using
bank.com. The request generated by Alice will look similar to the following:

POST http://bank.com/transfer.do HTTP/1.1

...
...
...
Content-Length: 19;

acct=BOB&amount=100

However, Maria notices that the same web application will execute the same transfer
using URL parameters as follows:

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

Maria now decides to exploit this web application vulnerability using Alice as her victim.
Maria first constructs the following URL which will transfer $100,000 from Alice's ac-
count to her account:

http://bank.com/transfer.do?acct=MARIA&amount=100000

Laboratory 3 – Performance Testing

Page 16 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Now that her malicious request is generated, Maria must trick Alice into submitting the
request. The most basic method is to send Alice an HTML email containing the follow-
ing:

<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pic-

tures!</a>

Assuming Alice is authenticated with the application when she clicks the link, the trans-
fer of $100,000 to Maria's account will occur. However, Maria realizes that if Alice clicks
the link, then Alice will notice that a transfer has occurred. Therefore, Maria decides to
hide the attack in a zero-byte image:

<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1"

height="1" border="0">

If this image tag were included in the email, Alice would only see a little box indicating
that the browser could not render the image. However, the browser will still submit the
request to bank.com without any visual indication that the transfer has taken place.

2.8 Insecure Configuration

Web server and application server configurations play a key role in the security of a web
application. These servers are responsible for serving content and invoking applications that gen-
erate content. In addition, many application servers provide a number of services that web appli-

Laboratory 3 – Performance Testing

Page 17 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

cations can use, including data storage, directory services, mail, messaging, and more. Failure to
manage the proper configuration of your servers can lead to a wide variety of security problems.
Frequently, the web development group is separate from the group operating the site. In
fact, there is often a wide gap between those who write the application and those responsible for
the operations environment. Web application security concerns often span this gap and require
members from both sides of the project to properly ensure the security of a site's application.

2.9 Unvalidated Redirects

Unvalidated redirects and forwards can happen when an intruder can cause a
web application to redirect visitors to a URL of his choosing. Often, such attacks are for
the purpose of tricking the user to disclose some private information (phishing attacks)
or for the installation of malware. These unsafe forwards bypass a sites built-in security
checks. But because these links are found on a trusted site, users are not hesitance to
click on them.
Such redirects may attempt to install malware or trick victims into disclosing
passwords or other sensitive information. Unsafe forwards may allow access control
bypass.
The problem is that javascript sets document.location or does some other kind of redi-
rect to a URL under the attackers control. The attacker can use this to launch attacks
towards the user, who is more likely to click the link, because the hostname is to a
trusted site.
Server-side redirects
A vulnerable server-side redirect will typically be a simple http handler that blindly
redirects to a URL given as a parameter:
http://example.com/redirect.php?url=http://evil.com As you can imagine it's rather simple
to make this redirect to a phishing site, or even a javascript: url.
Redirects in javascript
How do we do redirects in javascript? There is a decent list at the DOM XSS
Wiki. Assignment of untrusted data to any of these can lead to trouble:

• location
• location.href
• location.pathname
• location.search
• location.protocol
• location.hostname

Consider an application that does the following code where we try to limit our redirects
to redirects on the same server:
var relativePath = document.location.hash.substring(1);
var re = new RegExp("^/[a-z0-9/.]+$");
if (re.test(relativePath)) {
document.location = relativePath;
}

Laboratory 3 – Performance Testing

Page 18 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

At first we may think this is ok. We will allow things like /blog/test.html. However we for-
got about scheme less URLs like //www.insecurelabs.org. If the URL starts with //, it in-
herits the scheme from the current URL. Broken.

2.10 Using components with known vulnerabilities

Some vulnerable components (e.g., framework libraries) can be identified and
exploited with automated tools, expanding the threat agent pool beyond targeted at-
tackers to include chaotic actors.
Attacker identifies a weak component through scanning or manual analysis. They
customize the exploit as needed and execute the attack. It gets more difficult if the used
component is deep in the application.
Virtually every application has these issues because most development teams
don’t focus on ensuring their components stay up to date. In many cases, the develop-
ers don’t even know all the components they are using, never mind their versions.
Component dependencies make things even worse.
The full range of weaknesses is possible, including injection, broken access con-
trol, XSS, etc. The impact could be minimal, up to complete host takeover and data
compromise. Consider what each vulnerability might mean for the business con-
trolled by the affected application. It could be trivial or it could mean complete compro-
mise.

Laboratory 3 – Performance Testing

Page 19 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

3. SQL Injection Flaws practical examples

3.1 Blind SQL Injection

Blind SQL Injection is used when a web application is vulnerable to an SQL injection but
the results of the injection are not visible to the attacker. The page with the vulnerability may not
be one that displays data but will display differently depending on the results of a logical state-
ment injected into the legitimate SQL statement called for that page. This type of attack can be-
come time-intensive because a new statement must be crafted for each bit recovered. There
are several tools that can automate these attacks once the location of the vulnerability and the
target information has been established.
<Steps and Screen shots inserted here>

3.2 Numeric SQL Injection

3.3 String SQL Injection

3.3.1 Incorrectly filtered escape characters

This form of SQL injection occurs when user input is not filtered for escape characters and is then passed in-
to an SQL statement. This results in the potential manipulation of the statements performed on the database
by the end-user of the application.
The following line of code illustrates this vulnerability:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

This SQL code is designed to pull up the records of the specified username from its table of users. However, if the
"userName" variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code
author intended. For example, setting the "userName" variable as:

' or '1'='1

or using comments to even block the rest of the query (there are three types of SQL comments)

3.3.2 Incorrect type handling

This form of SQL injection occurs when a user-supplied field is not strongly typed or is not checked
for type constraints. This could take place when a numeric field is to be used in a SQL statement, but the
programmer makes no checks to validate that the user supplied input is numeric. For example:

statement := "SELECT * FROM userinfo WHERE id = " + a_variable + ";"

Laboratory 3 – Performance Testing

Page 20 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

It is clear from this statement that the author intended a_variable to be a number correlating to the "id"
field. However, if it is in fact a string then the end-user may manipulate the statement as they choose, there-
by bypassing the need for escape characters. For example, setting a_variable to

1;DROP TABLE users

will drop (delete) the "users" table from the database, since the SQL would be rendered as follows:

SELECT * FROM userinfo WHERE id=1;DROP TABLE users;

Laboratory 3 – Performance Testing

Page 21 of 24
Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Laboratory 3 – Performance Testing

Page 22 of 24
 Academy of Economic Studies Cybernetics and Economic Informatics Faculty

4. Further readings

1. Web Application Handbook – Discovering and Exploiting Security Flaws

2. Crash Course – Web Application Security Testing – D Van Stein
3. Web Application Security – Tom Olzak , August 2006
4. http://blackhatcrackers.blogspot.com

Laboratory 3 – Performance Testing

Page 23 of 24
Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Laboratory 3 – Performance Testing

Page 24 of 24