One of the main problems of all big companies is how their applications are secured from cyber attacks. New types of vulnerabilities and attack vectors are being developed every day, therefore they pose a potential threat to all applications that rely on some kind of web technology. This document explains the most common and most dangerous web attacks as well as techniques how to secure your infrastructure from being compromised. We focus on SQL injections, XSS, CSRF, RFI/LFI and Server Side Includes. We discuss the attack vectors of web vulnerabilities and exploitation schemas. However, regardless of the security measures taken and defenses being deployed, there will always be a way in. Nevertheless, security analysis provide a valuable insight that can grant the advantage over said attackers and allow us to stay one step ahead.

1. Web vulnerabilities and exploitation
Compromising the web
Eva Tanaskoska
Student, FCSE
Skopje, Macedonia
evamolotow@zeroscience.mk
Vlado Velichkovski
Student, FCSE
Skopje, Macedonia
v.velichkovski@hotmail.com
I. ABSTRACT
One of the main problems of all big companies is how
their applications are secured from cyber attacks. New
types of vulnerabilities and attack vectors are being
developed every day, therefore they pose a potential threat
to all applications that rely on some kind of web
technology. This document explains the most common and
most dangerous web attacks as well as techniques how to
secure your infrastructure from being compromised. We
focus on SQL injections, XSS, CSRF, RFI/LFI and Server
Side Includes. We discuss the attack vectors of we b
vulnerabilities and exploitation schemas. However,
regardless of the security measures taken and defenses
being deployed, there will always be a way in.
Nevertheless, security analysis provide a valuable insight
that can grant the advantage over said attackers and allow
us to stay one step ahead.
II. INTRODUCTION
Web servers nowadays seem to be vulnerable to the most
basic attacks which tend to get more sophisticated day by day.
Attacks like XSS which are deemed as low-risk are being
combined with other low-risk vulnerabilities to forge a more
sophisticated attack and compromise a web server. Improper
configuration and inability to deflect such attacks can prove
devastating to a network, corporation, or anything of the like.
However, as the attackers' arsenal gets more complex, so
do the security researchers'. Security experts all around the
world do their best to discover 0day vulnerabilities and
weaknesses before the malicious attackers do in order to patch
and fix said vulnerabilities.
Unfortunately, administrators all around the world don’t pay as
much attention to security as they should, which leads to
compromising sensitive information, business damage and
ultimately, loss of company value.
Securing the network infrastructure should be a priority to
administrators, as well as raising the employees’ security
consciousness, considering the human naivete is the weakest
link in the security chain.
Cyber crime has grown considerably in the past few years
with the development and use of technology, thus becoming a
problem which can not be ignored. Recent statistics have
shown that 96% of the tested applications have vulnerabilities.
However, compared to 2012, the percentage of tested
applications with vulnerabilities has dropped from 99% to 96%
and the median number of vulnerabilities per application has
grown from 13 up to 14. Fig.1 shows that Cross Site Scripting
(XSS) vulnerabilities continue to be the most common class of
application vulnerability. At 25% of the total, XSS was the
most frequently found vulnerability in applications tested in
2013. A substantial percentage of them have multiple XSS
exposure points to remediate and many of them create severe
security risks.
Fig. 1. Web application vulnerabilities of 2013
While the majority of corporations have the important
security building blocks, such as firewalls and intrusion
protection systems needed for their security infrastructure, not
enough organizations have comprehensive tools and practices
in place for securing applications. The result is that hackers are
increasingly focusing on and are succeeding with their attacks.
The results show that information security in general is still not
being taken as seriously as it should which could result in
significant damage to every system relying on computer
technology. Web applications are only a tiny grain of sand in
the vast field of possibilities open for exploitation.

2. III. ATTACK VECTORS
A. Cross Site Scripting
XSS (Cross Site Scripting)[1] is a client-side attack where
an attacker can craft a malicious link, containing script code
which is then executed within the victim's browser when
the target site vulnerable to and injected with XSS is
viewed. The script-code can be any language supported by
the browser but mostly HTML and Javascript are used
along with embedded Flash, Java or ActiveX. Cross-site
scripting is considered the most prevalent web application
vulnerability found in the wild, affecting the vast majority
of live applications. It can often be combined with other
vulnerabilities for a devastating effect. A large percentage
of XSS vulnerabilities found in the wild prove to be rather
harmless and usable only under certain conditions.
XSSQLi is a mix of Cross site scripting and SQL injection
where an unknowing victim visits a malicious link
containing SQL Injection instructions for an area on the
website which requires privileges that guests or members
don't have. An example of XSSQLI could be tricking the
administrator of example.tld to click either the SQL
Injection link or click a cross site scripting link which
contains a call to the SQL injection in the privileged area of
the site where this could be the vulnerable part:
http://example.tld/admin.php?del=1 AND 1=1/*
XSSR or CSSR aka Cross Site Script Redirection is used
to redirect a victim to another page unwillingly. The page
can, for example, contain a phishing template, browser
attack code or in some cases where the data or javascript
URI scheme is used: session-hijacking. However, the main
categorization of XSS attacks covers three main categories:
Reflected (non-persistent) XSS, stored (persistent) XSS and
DOM-based XSS.
1. Reflected XSS attacks are the most frequent type
of XSS attacks. A vulnerable web application will
pass unvalidated input sent through requests to the
client. The attacker creates an offending URI and
then convinces his victims to load this URI on
their browsers and have the code executed.
2. Stored XSS is the most dangerous type of Cross
Site Scripting. Web applications that allow users
to store data are potentially exposed to this type
of attack. As a consequence, the malicious data
will appear to be part of the web site and run
within the user’s browser under the privileges of
the web application. Stored XSS does not need a
malicious link to be exploited. A successful
exploitation occurs when a user visits a page with
a stored XSS.
Stored XSS is particularly dangerous in
application areas where users with high privileges
have access.
3. DOM-based cross site scripting vulnerabilities
may occur when active content, such as a
JavaScript function, is modified by a specially
crafted request such that a DOM element that can
be controlled by an attacker.
Due to their nature, DOM based XSS
vulnerabilities can be executed in many instances
without the server being able to determine what is
actually being executed. This may render many of
the general XSS filtering and detection rules
useless against such attacks.
An important matter about exploiting XSS vulnerabilities is
character encoding. In some cases, the web server or the web
application could only be filtering some encodings of
characters, therefore the web application might filter out
"<script>", but might not filter %3cscript%3e which simply
includes another encoding of tags.
In order to test for XSS vulnerabilities, the tester must first
detect input vectors, determine the web application's variables
and find out how to input themin the web application.
http://example.tld/index.php?user=<script>alert("XSS")</scri
pt>
The best way to protect against XSS attacks is to ensure that
all user input and output is validated and sanitized properly.
However in some cases an IPS or WAF can also be configured
to filter out XSS attacks using regular expressions that match
XSS attacks.
B. Cross Site Request Forgery
Cross-Site Request Forgery (CSRF)[2] is an attack that
tricks the victim into loading a page that contains a
malicious request. It inherits the identity and privileges of
the victim to perform an undesired function on the victim's
behalf, like change the victim's e-mail address, home
address, or password. CSRF attacks target functions that
cause a state change on the server but can also be used to
access sensitive data. A CSRF, sometimes called an XSRF,
vulnerability exists when a web application fails to properly
verify the origin of a request. CSRF is most commonly used
in conjuction with stored XSS vulnerabilities. Any
functionality that is accessible through HTTP and uses
session cookies for authorization is potentially at risk. Using
specially designed form tags and the “text/plain” content
type it is possible to generate any kind of message body in a
POST request. Web based APIs could also be at risk to
CSRF.

3. Most common methods of CSRF exploitation are:
1. Simple HTML through the use of various HTML
tags, for example:
<img src="http://example.tld/exploit?payload" height="1"
width="1" />
2. Auto submitting form, by using the form tag to
build a POST/GET request and submit it
automatically using javascript when the page is
loaded.
3. Using pure javascript to send an automatic request
by the browser. The XMLHttpRequest object can
also be used to generate a request, though this
object is not supported in all browsers.
4. Client side programming languages, by using
browser plugins such as Adobe Flash, Java applets
and Silverlight. However, even though these
languages offer the ability to send requests, a huge
disadvantage of this technique is the same origin
policy which prevents requests to hosts other than
the host the plugins were loaded on. Nevertheless,
there are ways to circumvent said policies.
The best way to protect against CSRF is by using random
form tokens where the server generates a random token and
stores it in the user’s session when he logs into the web
application. Any functionality that needs to be protected will
have to include this value as a parameter in the request. The
server simply verifies that the value in the parameter is the
same as the value stored in the session. The attacker doesn’t
have access to this value and can therefore not create a correct
request.
C. Server Side Includes injection
SSI Injection (Server Side Includes Injection)[1] is a server-
side exploitation technique that allows an attacker to inject
code into a web application, which will later be executed
locally by the web server. SSI Injection exploits a web
application's failure to sanitize user-supplied data before they
are inserted into a server-side interpreted HTML file. They
represent an alternative to writing CGI program or embedding
code using server-side scripting languages, when there's only
need to perform very simple tasks. Common SSI
implementations provide commands to include external files, to
set and print web server CGI environment variables, and to
execute external CGI scripts or system commands. When
compared to a classical scripting language, SSI injections are
considered less dangerous, as the SSI directives are not
comparable to a real scripting language and because the web
server needs to be configured to allow SSI, but also are simpler
to exploit, as SSI directives are easy to understand and
powerful enough to execute arbitrary operating system
commands, or include a restricted file's contents the next time
the page is served, for example:
< !--#exec cmd="/bin/ls /" -- >
SSI injections can be found everywhere where the user is
allowed to submit input without proper validation. Other than
common user-supplied data, possible input vectors are HTTP
request headers and cookies content, if the web application is
going to use that data to build a dynamically generated page,
for example:
GET / HTTP/1.0
Referer: <!--#exec cmd="/bin/ps ax"-->
User-Agent: <!--#virtual include="/proc/version"-->
It is possible to check if the application is validating input
fields data by inserting characters that are used in SSI
directives, like:
< ! # = / . " - > and [a-zA-Z0-9]
Another way to find out whether the application is
vulnerable is to search for .stm, .shtm and .shtml pages.
However, the lack of such pages does not mean it's not possible
to performan SSI injection attack.
D. SQL injection
SQL injection[3] vulnerabilities pose a serious threat for
Web applications. Web applications that are vulnerable to SQL
injections allow unauthorized users to execute queries and gain
access to information contained in the database. In some cases,
attackers can exploit an SQL injection vulnerability to take
control over the system. Data provided by the user is included
in an SQL query in such a way that part of the user’s input is
treated as an SQL query. An attacker can submit a query that
can be directly executed in the database and extract sensitive
information like credit cards, usernames, passwords, phone
numbers, pins...
SQL injections can be classified into several types,
including:
1. Union queries
Using the UNION SELECT command, we can extract
database information by controlling the second query after the
UNION command, e.g:
http://example.tld/song.php?id=1 union select
1,2,3,@@version,5--
2. Time based queries
This method uses functions like sleep(). If an SQL
statement is true, then page will wait longer before rendering.
By using this information about page rendering time, we can
conclude if an SQL statement is true or false.
3.Error based queries

4. With error based queries we can forge SQL statements that
will produce errors with duplicate entry key along with some
information.
4.Boolean based queries
These queries make comparison in statement and return result
if logic is true, therefore the page will only be rendered if the
logic of comparing two values is true. If not, either the page
may be not rendered or an error/warning message will show
up.
There are plenty of methods to sanitize this type of
vulnerability. We can use built-in functions to sanitize users’
input. Every database driver has functions string escaping
functions like mysql_real_escape_string(). The best solution
for this problem is using prepared statements.
E. LFI/RFI
Local File Inclusion (LFI)[4] and Remote File Inclusion (RFI)
are methods and attack vectors where users can include
local/remote scripts on run-time, execute them and gain full
unauthorized access to the target system. Most LFI/RFI can be
found in the URL, in GET parameters.
There are several methods for exploitation and circumventing
defense mechanisms:
1. Null byte
With the null byte technique, we can bypass an extension
from a script that is added after the filename. By adding
%00 in the url after the filename, the extension will not be
read and processed.
<?php include ($_GET['f'].'.php'); ?>
http://example.com/file.php?f=/etc/passwd%00
2. 2.Apache Log
Every access on web server running Apache will be
logged to the Apache access log file. If we know the
location of Apache access logs, we can use them in this
vulnerability as a file that’s to be included, in the same
time with script command to execute, as part of user-
agent header or any GET parameter.
http://example.com/file.php?f=/var/log/apache/access.log
3. /proc/self
By including /proc/self/environ and using spoofed user
agent containing a script/system command, we can
execute commands on the system. This method is widely
used to exploit Linux systems with this type of
vulnerability.
http://example.com/file.php?f=/proc/self/environ
User-Agent: <?php system(COMMAND_HERE);?>
RFI is essentially the same as LFI. The only difference is that
if the configuration of web server allows us to include scripts
located on a remote system, then we can use url in order to
include and execute arbitrary scripts.
LFI/RFI can be sanitized by not allowing user input in
include() calls.
CONCLUSION
Web applications can be vulnerable to a number of various
vulnerabilities depending on their complexity, the more
technologies they utilize – the more attack vectors are
available. In order to build a sophisticated website and provide
an enjoyable experience for the everyday user, the
administrator must sacrifice either the security, or the ease of
use. The best approach is to aim for balance. However, by
suppressing the security aspect, a number of vulnerabilities are
being introduced which could prove devastating. Security
should be a top priority concern during the development stage
of the application and must not be taken lightly. Most
databases contain information which should not under any
circumstance end up in the wrong hands. In order to achieve
the required level of security, an administrator should follow
best practices and rely on methods which are proven to be
secure. Unfortunately, it is not always possible to do so,
considering every web application has different needs and
deploys various technologies, which combined, could open
new attack vectors which previously weren’t present. Cyber
security is an investment which pays off in the long run and as
time progresses, becomes an inevitable part of every business
present on the internet. Simple attack vectors, like the ones
included in this document, can be easily dealt with, but a
sophisticated attacker might be able to forge a chain of at first
sight insignificant vulnerabilities and achieve full system
control, which is why in the security industry, one should
always be alert enough and expect the unexpected.
REFERENCES
[1] OWASP Foundation, 2002-2008 “OWASP Testing Guide v3”
[2] Acadion Security, “Cross Site Request Forgery – Vulnerability
ovevrview” v.1
[3] William G.J. Halfond, Jeremy Viegas and Alessandro Orso, “A
Classification of SQL injection Attacks and Countermeasures,” College
of Computing, Georgia Institute of Technology
[4] Fredrik NordbergAlmroth, “Local File Inclusion” unpublished.