JKCCT

Vol:xxxx Nr: x Pg:1-11

Web Threats and Ways to Prevent Them

Puica Marian Cosmin

Faculty of Mathematics and Computer Science,

Department of Computer Science,
University of Craiova, Romania
cosminel puica@yahoo.com

Abstract In recent years, web applications have become tremendously

popular, and nowadays they are routinely used in security-critical envi-
ronments, such as medical, financial, and military systems. As the use
of web applications for critical services has increased, the number and
sophistication of attacks against these applications have grown as well.
This paper presents the most known methods of attack on web applica-
tions and also the ways in which these attacks can be prevented. Most
web applications contain important informations, but in many cases their
vulnerability attracts many attackers and thats why some protections
are needed to stop these malicious intents. I will present four of the most
known and used ways of attack that can cause serious computer damage
when found in the wrong hands.

Keywords vulnerability, malicious, web-based attacks

1 Introduction

In the past ten years, the World-Wide Web has evolved from a system to
provide access to static information into a full-fledged distributed execution
infrastructure. Web-based applications have become a popular way to provide
access to services and dynamicallygenerated information. The popularity
of web-based applications, such as online shopping catalogs and webbased
discussion forums, is a result of the ease of development, deployment, and access
of this class of applications. Even network devices and traditional applications
(such as mail servers) often provide web-based interfaces that are used for
administration as well as configuration. Unfortunately, while the developers of
the software infrastructure (that is, the developers of web servers and database
engines) usually have a deep understanding of the security issues associated with
the development of critical software, the developers of web-based applications
2 Puica Marian Cosmin

often have little or no security skills. These developers mostly focus on the
functionality for the end-user and often work under stringent time constraints,
without the resources (or the knowledge) necessary to perform a thorough
security analysis of the application code. The result is that poorly-developed
code, riddled with security flaws, is deployed and made accessible to the whole
Internet.
Web-related security flaws represent a substantial portion of the total
number of vulnerabilities.
Because of their immediate accessibility, poor security, and large installation
base, web-based applications have become popular attack targets and one of
the main venues to compromise the security of systems and networks.
Nowadays, most of the information that we need in everyday life and in
professional environments is found on the internet. Be it the latest news,
the latest activities of your friends and families, purchasing various products
available in the virtual stores, or even E-banking, the internet makes it all
possible. But, what most of the internet users dont know is that, as attractive
as it may be, its still pretty much vulnerable to cybernetic attacks.
Web based attacks are considered by security experts to be the greatest and
oftentimes the least understood of all risks related to confidentiality, availability,
and integrity.
Application vulnerabilities could provide the means for malicious end users
to breach a systems protection mechanisms typically to take advantage or gain
access to private information or system resources. Information gathered can
include social security numbers, dates of birth, and maiden names, which are all
often used in identity theft. Another popular target for attackers is credit card
data which left unprotected and unencrypted can be used to cause significant
damage to organizations most valued assets, their customers. Machines become
unresponsive or sluggish resulting in users becoming frustrated and adminis-
trators spending precious time trying to find the problem. When a machine
is infected, some administrators often want to simply re-install the operating
system, however a responsible system administrator or security analyst would
want to investigate and assess the situation before doing anything else. All of
these tasks take time and resources. People have to stop working, the hardware
has to be replaced and so on.
This paper shows how some of the best known web-based attacks work and
how can web developers protect against them.

2 Web threats

Web threats use multiple types of malware and fraud, all of which utilize HTTP
or HTTPS protocols, but may also employ other protocols and components,
such as links in email or IM, or malware attachments or on servers that access
the Web. They benefit cybercriminals by stealing information for subsequent
sale and help absorb infected PCs into botnets.
 Web Threats 3

What is a botnet?
A botnet is a collection of internet-connected programs communicating with
other similar programs in order to perform tasks. The word botnet derives from
the two words robot and network.
There are many web-based threats but only a handfull can do serious
damage and steal valuable information.

2.1 SQL Injection

SQL injection is a technique often used to attack data driven applications.[1]
This is done by including portions of SQL statements in an entry field in an
attempt to get the website to pass a newly formed rogue SQL command to the
database (e.g., dump the database contents to the attacker). SQL injection is a
code injection technique that exploits a security vulnerability in an applications
software. The vulnerability happens 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.

Different forms of SQL Injection attacks:

Incorrectly filtered escape characters

This form of SQL injection occurs when user input is not filtered for escape
characters and is then passed into a 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.

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 + ";"
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
4 Puica Marian Cosmin

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;
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 dis-
play 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.

Conditional responses

One type of blind SQL injection forces the database to evaluate a logical
statement on an ordinary application screen. As an example, a book review
website uses a query string to determine which book review to display. So
the URL http://books.example.com/showReview.php?ID=5 would
cause the server to run the query
SELECT * FROM bookreviews WHERE ID = 5;
from which it would populate the review page with data from the re-
view with ID 5, stored in the table bookreviews. The query happens com-
pletely on the server; the user does not know the names of the database,
table, or fields, nor does the user know the query string. The user only
sees that the above URL returns a book review. A hacker can load
the URLs http://books.example.com/showReview.php?ID=5 AND
1=1 and http://books.example.com/showReview.php?ID=5 AND
1=2, which may result in queries
SELECT * FROM bookreviews WHERE ID = 5 AND 1=1;
SELECT * FROM bookreviews WHERE ID = 5 AND 1=2;
respectively. If the original review loads with the 1=1 URL and a blank
or error page is returned from the 1=2 URL, the site is likely vul-
nerable to a SQL injection attack. The hacker may proceed with this
query string designed to reveal the version number of MySQL running
on the server: http://books.example.com/showReview.php?ID=5
AND substring(@@version,1,1)=4, which would show the book review
 Web Threats 5

on a server running MySQL 4 and a blank or error page otherwise. The

hacker can continue to use code within query strings to glean more informa-
tion from the server until another avenue of attack is discovered or his or
her goals are achieved.

Protection

A straightforward, though error-prone, way to prevent injections is to es-

cape characters that have a special meaning in SQL. The manual for an SQL
DBMS explains which characters have a special meaning, which allows creating
a comprehensive blacklist of characters that need translation. For instance, every
occurrence of a single quote () in a parameter must be replaced by two single
quotes ( ) to form a valid SQL string literal. For example, in PHP it is usual to
escape parameters using the function mysql real escape string(); before sending
the SQL query:

$query = sprintf("SELECT * FROM Users WHERE UserName=%s AND

Password=%s",
mysql_real_escape_string($Username),
mysql_real_escape_string($Password));
mysql_query($query);

This function calls MySQLs library function mysql real escape string, which
prepends backslashes to the following characters: \x00, \n, \r, \, , and \x1a
. This function must always (with few exceptions) be used to make data safe
before sending a query to MySQL.
There are other functions for many database types in PHP such as
pg escape string() for PostgreSQL. There is, however, one function that works
for escaping characters, and is used especially for querying on databases that do
not have escaping functions in PHP. This function is:addslashes(string $str
). It returns a string with backslashes before characters that need to be quoted
in database queries, etc. These characters are single quote (), double quote (),
backslash (\) and NUL (the NULL byte).
Routinely passing escaped strings to SQL is error prone because it is easy to
forget to escape a given string. Creating a transparent layer to secure the input
can reduce this error-proneness, if not entirely eliminate it.

Database permissions

Limiting the permissions on the database logon used by the web application
to only what is needed may help reduce the effectiveness of any SQL injection
attacks that exploit any bugs in the web application.
For example on SQL server, a database logon could be restricted from
selecting on some of the system tables which would limit exploits that try to
insert JavaScript into all the text columns in the database.
6 Puica Marian Cosmin

deny SELECT ON sys.sysobjects TO webdatabaselogon;

deny SELECT ON sys.objects TO webdatabaselogon;
deny SELECT ON sys.TABLES TO webdatabaselogon;
deny SELECT ON sys.views TO webdatabaselogon;

2.2 Cross-site Scripting (XSS)

Cross-site scripting (XSS) is a type of computer security vulnerability typically
found in Web applications. XSS enables attackers to inject client-side script 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. Their
effect may range from a petty nuisance to a 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 sites owner.
There is no single, standardized classification of cross-site scripting flaws,
but most experts distinguish between at least two primary flavors of XSS:
non-persistent and persistent.

Non-persistent

The non-persistent (or reflected) cross-site scripting vulnerability is by far

the most common type. These holes show up when the data provided by a
web client, most commonly in HTTP query parameters or in HTML form
submissions, 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 markup 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 victims browser to execute the injected script.

Persistent

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.
 Web Threats 7

Persistent XSS can be more significant than other types because an attackers
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 a 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. Any data received by the web application (via email, system
logs,IM etc.) that can be controlled by an attacker could become an injection
vector.

Exploit examples

Attackers intending to exploit cross-site scripting vulnerabilities must

approach each class of vulnerability differently. The names below are purely
technical and taken only for this example.

Non-persistent attack:

1. Alice often visits a particular website, which is hosted by Bob. Bobs website
allows Alice to log in with a username/password pair and stores sensitive
data, such as billing information.
2. Mallory observes that Bobs website contains a reflected XSS vulnerability.
3. Mallory crafts a URL to exploit the vulnerability, and sends Alice an email,
enticing her to click on a link for the URL under false pretenses. This URL
will point to Bobs website (either directly or through an iframe or ajax),
but will contain Mallorys malicious code, which the website will reflect.
4. Alice visits the URL provided by Mallory while logged into Bobs website.
5. The malicious script embedded in the URL executes in Alices browser, as
if it came directly from Bobs server (this is the actual XSS vulnerability).
The script can be used to send Alices session cookie to Mallory. Mallory can
then use the session cookie to steal sensitive information available to Alice
(authentication credentials, billing info, etc.) without Alices knowledge.

Persistent attack:

1. Mallory posts a message with malicious payload to a social network.

2. When Bob reads the message, Mallorys XSS steals Bobs cookie.
3. Mallory can now hijack Bobs session and impersonate Bob.

Prevention ways

Contextual output encoding/escaping of string input

8 Puica Marian Cosmin

The primary defense mechanism to stop XSS is contextual output encod-

ing/escaping. There are several different escaping schemes that must be used
depending on where the untrusted string needs to be placed within an HTML
document including HTML entity encoding, JavaScript escaping, CSS escaping,
and URL (or percent) encoding. Most web applications that do not need to
accept rich data can use escaping to largely eliminate the risk of XSS in a
fairly straightforward manner. It is worth noting that although it is widely
recommended, simply performing HTML entity encoding on the five XML
significant characters is not always sufficient to prevent many forms of XSS.
Encoding can be tricky, and the use of a security encoding library is highly
recommended.

Safely validating untrusted HTML input

Many operators of particular web applications (e.g. forums and webmail)

wish to allow users to utilize some of the features HTML provides, such as a
limited subset of HTML markup. When accepting HTML input from users
(say, bvery/b large), output encoding (such as <b>very</b>
large) will not suffice since the user input needs to be rendered as HTML by
the browser (so it shows as v ery large, instead of bvery/b large). Stopping
XSS when accepting HTML input from users is much more complex in this
situation. Untrusted HTML input must be run through an HTML policy engine
to ensure that it does not contain XSS.

Cookie security

Besides content filtering, other imperfect methods for cross-site scripting

mitigation are also commonly used. One example is the use of additional
security controls when handling cookie-based user authentication. Many web
applications rely on session cookies for authentication between individual HTTP
requests, and because client-side scripts generally have access to these cookies,
simple XSS exploits can steal these cookies. To mitigate this particular threat
(though not the XSS problem in general), many web applications tie session
cookies to the IP address of the user who originally logged in, and only permit
that IP to use that cookie. This is effective in most situations (if an attacker
is only after the cookie), but obviously breaks down in situations where an
attacker is behind the same NATed IP address or web proxy as the victim, the
victim is changing his or her mobile IP.
Another mitigation present in Internet Explorer (since version 6), Firefox
(since version 2.0.0.5), Safari (since version 4), Opera (since version 9.5)
and Google Chrome, is an HttpOnly flag which allows a web server to set a
cookie that is unavailable to client-side scripts. While beneficial, the feature
does not fully prevent cookie theft nor can it prevent attacks within the browser.
 Web Threats 9

Defensive technologies

There are three classes of XSS defense that are emerging. These include,
Mozillas Content Security Policy, Javascript Sandbox tools, and Auto-escaping
templates. These mechanisms are still evolving but promise a future of heavily
reduced XSS.

2.3 Authentication Bypass

Authentication and authorization bypass are a crucial unsolved security flaw
in modern web applications. Authentication bypass attacks occur when users
are authenticated without presenting valid credentials. Authorization bypass
attacks occur when missing or incorrect access control attacks allow malicious
users access to access privileged resources. These attacks are very difficult to
prevent as each web application typically creates its own authentication and
access control framework.

Authentication Bypass attacks

User authenticated without valid credentials

Weaknesses to exploit:
Cookie, URL parameter validation (not validating password)
Session management flaws
Weak cryptography
Weak, brute forceable passwords
End result: Attacker has unrestricted access to webapp

Authentication Bypass attack examples

URL Parameter validation

if (isset($_GET[admin]))
$userName = admin;
Session Management
if (isset($_COOKIE[user]))
$userName = $_COOKIE[user];
Edit cookie, add name/value pair user=admin

Protection

These attacks can be averted by creating a simple spreadsheet information

management model (IMM). In one column, list all folders and objects. List the
10 Puica Marian Cosmin

permissions, security policy and permissible users with permission to access

it in another. Then test each object from a new Web session to ensure access
without proper session tokens is denied. Most engineers do not perform such
analysis and testing of their systems prior to release and therefore accidentally
leave data or applications open to attack.

2.4 Man-in-the-middle attack

A man-in-the-middle (MITM) attack is a form of eavesdropping where com-

munication between two users is monitored and modified by an unauthorized
party. Generally, the attacker actively eavesdrops by intercepting a public key
message exchange and retransmits the message while replacing the requested
key with his own.
In the process, the two original parties appear to communicate normally.
The message sender does not recognize that the receiver is an unknown attacker
trying to access or modify the message before retransmitting to the receiver.

Defenses against the attack

Various defenses against MITM attacks use authentication techniques that

are based on:

Public key infrastructures

PKI mutual authentication The main defence in a PKI scenario is mutual
authentication. In this case as well as the application validating the user
(not much use if the application is rogue) - the users devices validates
the application - hence distinguishing rogue applications from genuine
applications
Stronger mutual authentication, such as:
Secret keys (which are usually high information entropy secrets, and thus
more secure), or
Passwords (which are usually low information entropy secrets, and thus
less secure)
Latency examination, such as with long cryptographic hash function calcula-
tions that lead into tens of seconds; if both parties take 20 seconds normally,
and the calculation takes 60 seconds to reach each party, this can indicate a
third party
Second (secure) channel verification
One-time pads are immune to MITM attacks, assuming the security and
trust of the one-time pad.
Carry-forward verification
Testing is being carried out on deleting compromised certificates from issuing
authorities on the actual computers and compromised certificates are being
exported to sandbox area before removal for analysis
 Web Threats 11

3 Conclusion
For many businesses which conduct business online, their reputation is at stake.
One breach can oftentimes lead to irreparable brand damage. And putting a
price on the amount of damage done is oftentimes extremely difficult, though
losses to public companies can be in excess of billions when stock valuations are
considered.
Because of the continuous evolution of computer science, in the near future
every person will store valuable information on their computer, thus opening the
path to every attackers with evil intents. To stop the attackers in their track,
high security programs are created. But every time a security program is created
so does its counterpart, following a neverending story. The purpose of this paper
was to show how some web attacks work and how they can be prevented so that
in the future, people can store valuable information on their computers without
fear of being hijacked.
Only a few of the possible approaches have been discussed in this paper, and
likely in time these strategies will require tweaking and improvement as attack
vectors will invariably evolve over time.
Future research will provide more ways to prevent web-based attacks.

References
1. Neil Chou, R. Ledesma, Client-side defense against web-based identity
theft.Stanford University
2. William G.J. Halfond, Jeremy Viegas, and Alessandro Orso, A Classifica-
tion of SQL Injection Attacks and Countermeasures, College of Computing, Georgia
Institute of Technology
3. Ulrike Meyer, A man-in-the-middle attack on UMTS,Darmstadt University of
Technology, (2004)
4. Justin Crist, Web Based Attacks, SANS Institute (2007)
5. Mike Dalton, Preventing Authentication and Authorization Bypass Attacks in
Web Applications , (2009)
6. William Robertson, Giovanni Vigna, Christopher Kruegel, and Richard
A. Kemmerer, Using Generalization and Characterization Techniques in the
Anomaly-based Detection of Web Attacks, University of California, Santa Barbara