ID 8705
Neuhaus, Michael: Application Level Security Management
Hamburg: Diplomica GmbH, 2005
Zugl.: Fachhochschule Konstanz, Diplomarbeit, 2005
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2005
Printed in Germany
"When I took office,
only high energy physicists had ever heard
of what is called the Worldwide Web...
Now even my cat has its own page."
- Bill Clinton, 1996
Declaration
iii
Declaration
Hereby I, Michael Neuhaus, borne 1981-06-06, affirm:
1)
that the Diploma Thesis with the title
"Application Level Security Management"
constitutes work carried out by myself and without external help. Only the listed
references are used within the Diploma Thesis.
2)
that the adoption of citations, tables, figures and other resources are referenced at
the appropriate positions.
I am aware of the fact that an incorrect declaration will have legal consequences.
Basel,
2005-02-28
...
Michael Neuhaus
Faculty of Electrical Engineering and Information Technology
Department of Information and Communication Technology
University of Applied Sciences of Konstanz (FH Konstanz)
Global IT Security
Novartis Pharma AG, Basel, Switzerland
Thesis Advisors:
Prof. Dr. Thomas Birkhölzer (FH Konstanz)
Andreas Wuchner (Novartis Pharma AG)
Acknowledgements
iv
Acknowledgements
Getting the opportunity to write a diploma thesis within the Global IT department of a
company has been extremely effective for me. The execution of my research with a global
focus regarding manageability and feasibility of the different parts analyzed enabled myself
for the constitution of the thesis in the way it is provided now. But this is just one side of the
story:
Without the support, encouragement, input and contributions of many different colleagues
and the professor from my university, who was dedicated to the supervision of this diploma
thesis, it would have been impossible to conduct the research related to application-level
security management in this way.
Special thanks go to Prof. Dr. Birkhölzer from the FH Konstanz for his fast responses on any
open issues form my side and his proactive proposals on several topics within the thesis.
Also special acknowledgements go to Andreas Wuchner, my thesis advisor at Novartis, firstly
for his open conceptual formulation of the topic "application level security management"
which enabled me to find my own way and view on this topic. Secondly, for his valuable input
on any topic related to IT in general, not only dedicated to IT security.
Further special acknowledgements are dedicated to Herbert Steiert, who acted much as a co-
advisor for my thesis. Once again many thanks for your valuable input as well, I appreciate
that.
As I conducted my thesis in a very large-scale department, the list of all people that should
receive acknowledgements namely would go beyond this scope. Therefore I'd like to thank
anyone else who provided input for my thesis or also just offered interesting discussions on
IT related topics in general. This includes anyone within my Global IT Security department,
many different people form Global Network Services, some of the external consultants from
Bearing Point, at rete or JHP - and especially Stefan Strobel and Steffen Gundel from
Cirosec.
Finally, a big thank you to those who offered me with the correction of the written thesis
drafts, namely Johannes Hess from FH Konstanz and Ronald Warnecke from Bearing Point.
Abstract
v
Abstract
Today, more and more enterprises are developing business applications for Internet usage,
which results in the exposure of their sensitive data not only to customers, and business
partners but also to hackers. Because web applications provide the interface between users
sitting somewhere within the World Wide Web and enterprises' backend-resources, hackers
can execute sophisticated attacks that are almost untraceable, aiming to steal, modify or
delete enterprises` vital data, even when it is protected by passwords or encryption.
As recent viruses and worms such as Nimda, CodeRed or MSBlast have shown, modern
attacks are occurring at the application itself, since this is where high-value information is
most vulnerable. Such attack scenarios a becoming very problematic nowadays, since
traditional network security products such as firewalls or network intrusion detection
systems are completely blind to those malicious activities and therefore can not offer any
protection at all. Modern protection mechanisms require more sophisticated detection
capabilities in order to protect enterprises assets from such attacks now and in the future.
Additionally web application security currently is a highly dynamic and also very emerging
field within enterprises' IT security activities. Therefore this diploma thesis aims to provide
a strong focussed picture on the current state of web application security and its different
possibilities to raise the overall security level of already implemented web applications and
also of future web applications.
Acting as a basis for further analysis, the currently most common web application
vulnerabilities are described to get an overview of what a web application has to be protected
of and where the root problems of these weaknesses are lying. Although these generic
categories may not be applicable to every actually implemented web application, they may be
used as baseline for future web applications.
Armed with the background of the current vulnerabilities and their related root causes, a
detailed analysis of currently available countermeasures will provide recommendations that
may be taken at each of the certain stages of a web application's lifecycle. Since all further
decisions generally should be based upon risk evaluations of specifically considered systems,
a possible risk management assessment methodology is provided within the thesis.
Controls and countermeasures are provided from an attack's timeline perspective, describing
preventive countermeasures attached to each certain stage within the web application
lifecycle and also different protective controls which are actively capable to defend
enterprises from being successfully attacked. These countermeasures are analyzed form a
functionality point of view, followed by currently available products providing such dedicated
mechanisms. If available, such products and technologies were additionally judged with
analyst's perspectives for the provision of a more prospective view on current possibilities
and future opportunities.
Table of Contents
vi
Table of Contents
DECLARATION...III
ACKNOWLEDGEMENTS... IV
ABSTRACT...V
TABLE OF CONTENTS... VI
LIST OF FIGURES ...VIII
LIST OF TABLES ... IX
1 INTRODUCTION... 1
1.1
T
HE
B
USINESS
P
ERSPECTIVE
... 1
1.1.2 The Problem inherent to Web Applications
... 2
1.1.3 Different Forms of Attacks
... 4
1.2
B
ASICS OF
W
EB
A
PPLICATION
S
ECURITY
... 5
1.2.1 The Basic Principles of Security
... 5
1.2.2 Common Security Terms Defined
... 6
1.2.3 Application Security A Holistic Approach
... 6
1.3
C
ONTENTS OF THIS
T
HESIS
... 8
2 ARCHITECTURE OF A WEB APPLICATION... 9
2.1
T
HE
L
OGICAL
V
IEW
... 10
2.2
T
HE
P
HYSICAL
V
IEW
... 10
2.3
C
OMMUNICATION BETWEEN
W
EB
C
LIENT AND
W
EB
S
ERVER
... 12
2.3.1 The ISO/OSI Reference Model
... 12
2.3.2 HTTP
... 13
2.3.3 HTTP over SSL
... 13
3 RISKS AND VULNERABILITIES OF WEB APPLICATIONS ... 16
3.1
R
ISK
M
ANAGEMENT
... 16
3.1.2 Definition of Risk
... 16
3.1.3 The NIST Risk Assessment Methodology
... 17
3.2
T
HE
10
MOST COMMON
W
EB
A
PPLICATION
V
ULNERABILITIES
... 21
3.2.1 Unvalidated Input
... 23
3.2.2 Broken Access Control
... 27
3.2.3 Broken Authentication and Session Management
... 28
3.2.4 Cross-Site Scripting (XSS) Flaws
... 31
3.2.5 Buffer Overflows
... 34
3.2.6 Injection Flaws
... 35
3.2.7 Improper Error Handling
... 35
3.2.8 Insecure Storage
... 36
3.2.9 Denial of Service
... 36
3.2.10 Insecure Configuration Management
... 37
3.3
W
EB
A
PPLICATION
S
ECURITY
C
HECKLIST
... 38
4 CURRENT CONTROLS AND COUNTERMEASURES ... 39
4.1
W
EB
A
PPLICATION
A
RCHITECTURE
R
EVISITED
... 39
4.2
P
RE
-A
TTACK
M
EASURES
... 41
4.2.1 Web Application Lifecycle Management From a Security Perspective
... 41
4.2.1.1 Project definition... 43
4.2.1.2 Software Development Lifecycle (SDLC) ... 43
4.2.1.3 Operations and Maintenance... 46
4.2.2 Automatic Source Code Analysis
... 46
Table of Contents
vii
4.2.2.1 Commercial Automatic Source Code Analyzers... 48
4.2.2.2 Open-Source Automatic Source Code Analyzers ... 50
4.2.3 Secure Coding Libraries
... 51
4.2.4 Web Application Vulnerability Scanning
... 52
4.2.4.1 Web Application Scanner ... 52
4.2.4.2 Database Scanner... 53
4.2.5 Security Services of Providers
... 55
4.2.5.1 Architecture and Design Assessment Services... 55
4.2.5.2 Code Review Services ... 56
4.2.5.3 Managed Web Application Assessments ... 56
4.2.6 Summary of currently available Preventive Countermeasures
... 58
4.3
A
TTACK
D
EFENSE
... 59
4.3.1 Web Application Security Gateways
... 59
4.3.1.1 HTTP Filtering... 62
4.3.1.2 Static and Dynamic Configuration Mechanisms... 66
4.3.1.2 WASG Network Integration Options... 66
4.3.1.3 Current Products ... 68
4.3.3 Host Intrusion Prevention Systems
... 73
4.3.4 Proxies for Backend Protocols
... 76
4.4
P
OST
-A
TTACK
M
EASURES
... 77
5 FUTURE TRENDS ... 78
5.1
W
EB
S
ERVICES
... 78
6 CONCLUSIONS AND OUTLOOK ... 82
Appendix A: List of Acronyms... A-1
Appendix B: References ... B-1
Appendix C: Web Application Security Checklist ... C-1
List of Figures
viii
List of Figures
F
IGURE
1:
P
ERCENTAGE
E
XPERIENCING
W
EB
S
ITE
I
NCIDENTS
... 3
F
IGURE
2:
D
OLLAR
A
MOUNT OF
L
OSSES BY
T
YPE
... 3
F
IGURE
3:
A
H
OLISTIC
A
PPROACH TO
S
ECURITY
... 7
F
IGURE
4:
P
HYSICAL AND
L
OGICAL
A
RCHITECTURE OF A
3
T
IER
W
EB
A
PPLICATION
... 9
F
IGURE
5:
T
HE
ISO/OSI
R
EFERENCE
M
ODEL INCLUSIVE IMPORTANT INTERNET PROTOCOLS
... 12
F
IGURE
6:
T
HE
NIST
R
ISK
A
SSESSMENT
M
ETHODOLOGY
... 17
F
IGURE
7:
R
ISK
M
ATRIX DISPLAYING THE
C
OHERENCE OF
L
IKELIHOOD AND
I
MPACT
... 20
F
IGURE
8:
T
HE
OWASP
T
OP
T
EN
W
EB
A
PPLICATION
S
ECURITY
V
ULNERABILITIES
... 22
F
IGURE
9:
W
EB
A
PPLICATION GENERATING A
U
SER
L
OGIN
SQL
S
TATEMENT
... 26
F
IGURE
10:
S
CENARIO FOR A
XSS
ATTACK EXECUTED THROUGH
J
AVA
S
CRIPT
... 33
F
IGURE
11:
R
EFERENCE
W
EB
A
PPLICATION
A
RCHITECTURE INCLUDING
N
ETWORK
F
IREWALLS AND
DMZ'
S
... 40
F
IGURE
12:
A
PPLICATION
L
IFECYCLE
S
ECURITY
E
NHANCEMENT
P
OSSIBILITIES
... 42
F
IGURE
13:
C
OST FOR REMEDIATION OF VULNERABILITIES AT DIFFERENT STAGES OF THE
SDLC ... 44
F
IGURE
14:
O
UNCE
L
ABS
P
REXIS
M
ECHANISM
... 49
F
IGURE
15:
WASG
I
NTEGRATION INTO THE
R
EFERENCE
W
EB
A
RCHITECTURE
... 60
F
IGURE
16:
T
HE
Y
ANKEE
G
ROUP
A
PPLICATION
G
ATEWAY
M
ARKET
F
ORECAST
2003-2009... 61
F
IGURE
17:
E
XAMPLE FOR
R
UNTIME
D
YNAMIC
URL
L
EARNING AND A CORRESPONDING
A
TTACK
... 63
F
IGURE
18:
E
XAMPLE FOR
R
UNTIME
D
YNAMIC
P
ARAMETER
L
EARNING AND A CORRESPONDING
A
TTACK
... 64
F
IGURE
19:
R
UNTIME
C
OOKIE
M
ANAGEMENT OF A
W
EB
A
PPLICATION
S
ECURITY
G
ATEWAY
... 66
F
IGURE
20:
WASG
N
ETWORK
I
NTEGRATION AS
R
EVERSE
P
ROXY OR
AIPS ... 67
F
IGURE
21:
K
AVADO
I
NTER
D
O
S
ECURITY
P
OLICY
C
ONFIGURATION
E
XAMPLE
... 69
F
IGURE
22:
I
MPERVA
S
ECURE
S
PHERE
N
ETWORK
/O
PERATING
M
ODE
I
MPLEMENTATION
O
PTIONS
... 72
F
IGURE
23:
C
OMMON
C
ONCEPTUAL
W
EB
S
ERVICES
A
RCHITECTURE
... 79
List of Tables
ix
List of Tables
T
ABLE
1:
H
UMAN
T
HREAT
-S
OURCES AND THEIR POSSIBLE
M
OTIVATIONS AND
T
HREAT
A
CTIONS
... 18
T
ABLE
2:
V
ULNERABILITY
/T
HREAT PAIRS
... 19
T
ABLE
3:
S
OME
P
OPULAR
C
HARACTERS FOR
I
NPUT
V
ALIDATION
T
ESTING
... 24
T
ABLE
4:
S
UMMARY OF CURRENTLY AVAILABLE PREVENTIVE
C
OUNTERMEASURES
... 58
T
ABLE
5:
L
OSING THE
S
YSTEM
P
ATCHING
R
ACE
... 74
1 Introduction
1 Introduction
1.1 The Business Perspective
When discussing about today's businesses, there are many terms very common just as
globalization, mobility, compliance to external regulations and related legal issues. These
externally driven objects are driving the business requirements which will be translated into
business processes, which also will have a big impact on the IT
1
solutions of companies, as
they are derived form the corresponding business processes.
As a consequence, with each new IT solution developed also new IT security risks should be
considered. These can be divided into risks relating to the underlying infrastructure or to the
applications themselves. From an application-level perspective regarding distributed systems
there are currently two architectures, namely the classical client-server model, and the web
application model, which were born through the widespread use of the World Wide Web
(WWW) exploding since the early 1990´s.
Today companies are moving more and more of their non-critical and also critical
applications onto the World Wide Web, as these emerging technologies are very attractive to
the business, especially regarding requirements like mobility, which means authorized
access anytime from any place in the world. There are different motivations behind this move
to the Web besides the mobility issues, but one major reason is also related to cost. In the
past, developing, deploying and maintaining client-server applications became very
expensive, as clients had to be tested on multiple operating systems, installed on every client
machine and re-installed every time there was a minor version change of the software. The
cost of deploying new applications or maintaining existing ones for large numbers of users
has become unmanageable.
One major advantage of web applications is, that one part of the client now is standardized:
"The browser". The other part (if necessary) will be downloaded automatically every time a
user invokes an application. This application deployment is very cost saving, as the delivery
is almost free and the clients are now platform/device independent.
Today, the World Wide Web - which has to be considered as a global communications
medium - enables people or companies to use functionalities like:
·
E-commerce, which enables to purchase a nearly unlimited array of goods and
services (e.g. medical services, drugs or computer equipment, just to name a few)
·
Online financial transactions, e.g. e-banking
·
Information research on nearly every subject conceivable
1
All abbreviations, which are not directly illustrated within the diploma thesis itself are itemized within the list of
acronyms, which can be found in Appendix A.
1 / 83
1 Introduction
·
Global communications and collaborations in real-time with anyone anywhere using
e.g. web-based email, chat or telephony (voice and video) attached to network devices
·
Inter-company communications and transactions, also known as e-business
1.1.2 The Problem inherent to Web Applications
Web applications can take many forms an informational website, an e-commerce website, a
search engine or a transaction engine, just to name a few. As such functionalities are
becoming more and more important for the business there are also some "side-effects" which
have to be covered. Unfortunately, by making data accessible outside the corporate trust
boundary, web applications have dramatically increased the business risks associated with
that data. One web application attack can stop business with one click of the mouse.
Web based technology will continue to grow as many companies embrace the benefits of e-
business. Enterprises today use the Web for managing their customer relationships,
enhancing their supply chain operations and deploying new products and services to
customers and employees. However, successfully implementing the benefits of Web based
technologies cannot be achieved without a consistent approach to web application security.
As a short overview of the current state of application security on the Internet, here are some
of the findings of the Symantec Internet Security Threat Report[2] for the first half year of
2004, published in September 2004:
·
"The average time between the public disclosure of a vulnerability and the release of
an associated exploit was 5.8 days."
·
"On average, 48 new vulnerabilities per week were disclosed between January 1 and
June 30, 2004."
·
"In the first half of 2004, 479 vulnerabilities, or 39% of the total volume, were
associated with web application technologies. This is an increase of 8% over the 31%
seen in the second half of 2003, and is also higher than the 35% observed in the fist
half of the same year."
·
"In the first six months of 2004, 82% of the web application vulnerabilities were
considered easy to exploit."
·
"During this period, 64% of vulnerabilities for which exploit code was available were
considered high severity."
·
"Client-side and web application attacks are expected to increase in the near future."
In addition the 2004 CSI/FBI Computer Crime and Security Survey[4] provides facts
regarding Web site incidents (figure 1) and estimated Dollar amount of losses by type (figure
2):
2 / 83
1 Introduction
Figure 1: Percentage Experiencing Web Site Incidents
Through inspecting the figure it is visible that the vast majority of the respondents indicated
between one and five web site incidents to their organization between the previous 12
months. A significant justification for the importance of web application security is that 5
percent of these respondents even experienced more than 10 web site incidents.
Figure 2: Dollar Amount of Losses by Type
3 / 83
1 Introduction
Regarding figure 2, it is really alarming that the 269 respondents contributing at the 2004
CSI/FBI survey estimated cumulated losses of $141,496,560. While looking at the different
types of losses, several of those are directly assigned to web applications, just as "Web site
defacement" and "Misuse of public Web application". Others like "Unauthorized access",
"Insider Net abuse", "Theft of proprietary info", "Denial of Service" and also the valuably
biggest loss type "Virus", can be brought into relation with web applications. As these values
are not itemized more precisely, no definitive statement to amounts of losses per type
generated through web application security breaches may be provided. Surely, web
applications are one major target among a few others to be harmed (and the discovery of this
target has nearly just begun).
1.1.3 Different Forms of Attacks
As partly mentioned in the previous chapter here is a short list of possible attacks on a
specific web application just to mention a few concrete scenarios already successfully
occurred:
·
Scanning the system for confidential documents, which eventually will be transmitted
to other systems.
·
Information stored on the system will be accessed, corrupted or even deleted.
·
Reformatting of the complete hard disk drive(s).
·
Doing modifications on the computer system's operating system, e.g. leaving traps,
creating new security holes which later may be exploited or simply causing the
system to crash.
·
A Denial of Service attack (DoS) may be executed in order to block access to the
system for legitimate users.
·
The system may also be abused to participate in a Distributed Denial of Service
attack (DDoS) targeted on another computer system.
·
A specific web site may be "defaced", which means the web application will be
attacked in order to provide false or fraudulent information to legitimate users, e.g. a
companies´ annual report with modified numbers, or just manipulating data to create
attention in the media.
Today, web applications are entry-points into companies, not only from a marketing or
business point of view, but also from a hacker's perspective.
4 / 83
1 Introduction
1.2 Basics of Web Application Security
1.2.1 The Basic Principles of Security
According to [8] web application security relies on the following six elements:
·
Authentication
This mechanism is the process of identifying the clients of a web application. These
might be end users, other services or computers.
·
Authorization
This describes the process of identifying which resources an authenticated client is
allowed to access and which operations this client is permitted to execute.
·
Auditing
For ensuring non-repudiation within a web application, effective auditing and logging
controls have to be implemented.
·
Confidentiality
Property of information (data) to be kept ensured so that the information cannot be
viewed by unauthorized users or eavesdroppers who monitor the flow of traffic across
networks. Encryption is frequently used to enforce confidentiality.
·
Integrity
This basic principle should guarantee that data is protected from accidental or
knowingly malicious modification.
·
Availability
This means that systems and information remain available for legitimate users so
that the web application could be accessed whenever wanted.
Additionally to the six basic elements of security mentioned above the term "Accountability"
is often used within this context:
·
Accountability
Often also referred to as non-repudiation it is the ability of a system to keep track of
who or what accessed the system and/or made changes to it. This can be achieved
through using a combination of security principles mentioned above, including
authentication, auditing and integrity and related services like a trusted time source,
as a possible example.
5 / 83
1 Introduction
1.2.2 Common Security Terms Defined
This section will provide short descriptions of security terms which will be used frequently
within this thesis:
·
Vulnerability: A vulnerability is a weakness in an web application (system security
procedures, design, implementation or internal controls) that can be triggered
accidentally or exploited intentionally.
·
Threat: A threat is the potential for a particular threat-source (e.g. a hacker) to
successfully exercise a specific vulnerability.
·
Exploit: An exploit is an attack on a web application (based on an exploit-code),
especially one that takes advantage of a particular vulnerability that the web
application offers to intruders.
1.2.3 Application Security A Holistic Approach
As the enterprise network perimeter
1
has become more secure, intruders have progressed up
the software stack to focus on the web application itself. When securing networks, companies
think of controls like firewalls, SSL-encryption, Anti-Virus or even Intrusion Detection
Systems, but there is more to security than just securing the network. On the one hand the
impact of these solutions for protecting the web application itself is minor, on the other hand
only the appropriate combination of such network and host security mechanisms and
additional security mechanisms dedicated for the protection of the web applications
themselves will be able to cope with the risks these web applications are currently facing.
As described in [8] it is essential to have a holistic approach on web application security,
which includes security controls attached to the network, the host and the web application
itself (with its data).
1
Perimeter: The boundary of the domain in which a security policy or security architecture applies, i.e. the boundary of
the space in which security services protect system resources.
6 / 83
1 Introduction
Figure 3: A Holistic Approach to Security
"A vulnerability in a network will allow a malicious user to exploit a host or an application. A
vulnerability in a host will allow a malicious user to exploit a network or an application. A
vulnerability in an appli ation will allow a malicious user to exploit a network or a host."
c
Carlos Lyons, Corporate Security, Microsoft, [8]
As this citation specifies, it is important to have an integrated approach on application
security, meaning that the underlying infrastructure (network and host) is secured in the
most effective way to provide a good basis for a sophisticated application security concept. As
these basic security services are very important for a holistic view, short explanations to each
of them will follow:
Securing the Network
"A secure web application relies upon a secure network infrastructure"[8]. Basically, the
network infrastructure consists of firewalls, routers and switches which themselves have to
ensure the protection from TCP/IP-based attacks and the integrity of the forwarded traffic.
Vulnerabilities dealing with ports and network protocols like IP, UDP or TCP should be
addressed at that layer. Considerations about remote administrative interfaces for those
network devices should also be in place, as weaknesses in the password policy could be very
harmful for the security level of a network, just to mention one possible issue.
7 / 83
1 Introduction
Securing the Host
Regarding web applications, host security deals with characteristics of servers and their
specific settings. Different categories like the following mentioned below should be analyzed:
·
Patch level of the Operating System and relating updates
·
Shares
·
Services
·
Accounts
·
Auditing and Logging
·
Files and Directories
·
Registry
·
Network settings (ports, protocols, proxies, etc.)
Securing the Application (and its data)
For this thesis it will be assumed that the maximum security level for the network and the
host is applied, as the further research will strictly focus on the security of the web
applications and their data themselves.
1.3 Contents of this Thesis
According to the trend described in the former chapters regarding web applications, the
security in this area becomes an increasingly important cornerstone. As the originally
proposed subject had to be limited on an specific "field" within application security for
complexity and time reasons - the diploma thesis will strictly focus on web applications
providing an in-depth analysis of the current situation around web application security.
The actual threats, vulnerabilities and their derived risks which are targeted onto web
applications will be described and analyzed. Furthermore recommendations of currently
available countermeasures and controls for improving the security level of web applications
will be given in order to address the emerging problems inherent to web applications. These
countermeasures will be divided into the categories "pre-attack measures", "attack defense"
and "post-attack measures" to provide a more granular level of available and considerable
preventive, detective or reactive mechanisms.
Additionally, future trends within the growing field of web application security will be
analyzed and reported.
8 / 83
2 Architecture of a Web Application
2 Architecture of a Web Application
This section covers the preconditioned web application architecture for web applications
which will be needed for the understanding of the upcoming chapters. Furthermore,
descriptions of the most relevant protocols for web applications will be provided within this
section.
Figure 4: Physical and Logical Architecture of a 3 Tier Web Application
Figure 4 describes the web application architecture which will be assumed as reference for
the remainder of the thesis. It is important to know that I chose this architecture among a
few other possible architectures, as the 3-tiered architecture is currently the mostly
widespread one and also for the reason that I believe that it is the most appropriate one. The
figure above includes a physical and a logical view, which will be shortly described in the
following sections.
For the physical architecture, modern web applications are assumed to be split onto 3
different servers, which are namely the web server, the application server and the database
server.
From the logical point of view, a modern web application is structured in 3 tiers, which are
referred to as presentation tier, logic tier and data tier. The idea behind these separate tiers
was to separate the presentation from the logic of an application, and additionally disperse
both of these two different layers from the data itself. This has some advantages, e.g. data
does not have to be hard-coded into the logic layer and therefore for example provides more
flexibility for updates of the data. Another advantage is the clear "balance of power" between
presentation, logic and the data itself.
Briefly explained, the presentation layer is responsible for taking inputs from the user of a
web application and for displaying the results of a requested service, e.g. a search query on a
9 / 83
2 Architecture of a Web Application
web page. The logic layer takes this input provided from the presentation layer and performs
some work on it and hands then the result back to the presentation layer or if additional
information (e.g. from a database) is required interacts with the data layer for e.g. querying
or updating stored information.
2.1 The Logical View
As displayed in figure 4, the following is an imaginary example for the basic processing of a
possible standard request within a web application to explain how the three different tiers
are working together.
Imagine a simple web application which provides a search function for specific filenames
containing text which former has to be supplied by the user and afterwards displays the
results of this query. In this case the presentation layer consists of a form with a field called
"search.html" asking the user for the provision of a search string.
As next step, the logic layer - which in our case consists of an executable simply called
"search.exe" - takes the provided input string, performs some action (e.g. generating a query
for a database) and then forward this request to the data layer
1
, which in our case is a
database called "filenames.db".
This database which stores an index of all filenames residing on the data layer - returns (if
successful) a matching database record or even a set of matching records. This output will be
handed back to the logic layer executable, which will be forwarded to the presentation layer.
Finally, the presentation layer will embed the provided database results in another html-file
called "results.html", so that they are formatted nice as the page provided by the web server
will be displayed in the end user's browser.
2.2 The Physical View
Regarding the physical view of this modern web applications´ reference architecture, it is
commonly built up through utilizing different servers, namely as mentioned above the
web server, the application server and the database server. These different servers do not
necessarily have to be implemented on different physical servers, but for this thesis and the
provided reference architecture it is assumed that they are.
Furthermore - as several scenarios may be applicable for this architecture - here a few widely
implemented examples:
·
Web server, application server and database server are physically implemented on
different physical machines and are located within a companies´ network.
·
Web server, application server and database server are physically implemented on
different machines and are completely located in an external hosting center.
1
Often also referred to as backend as the data layer typically makes up the last tier in a 3-tier web application
architecture. In some cases the data layer could also utilize backend connections (e.g. from an external hosting center back
into a company's LAN), legacy applications or ERP-applications (such as SAP or Peoplesoft) instead of using just a regular
database.
10 / 83
2 Architecture of a Web Application
·
Web server, application server and database server are physically implemented on
different machines. Furthermore, the web server and the application server are
physically located in an external hosting center, but the database server is hosted in
the companies´ network.
·
Based on the requirement specification for a specific web application, web servers
and/or application servers and/or database servers may be clustered in server farms
in order to e.g. increase performance or increase availability.
Actual market situation regarding server products
At the time of the thesis development, the following products were identified as mostly used
globally, based on Novartis-internal and also external research and their correlation.
Currently the most commonly used web servers include the Apache HTTP Server
1
with a
market penetration of 68.43% and the Microsoft IIS
2
(Internet Information Services) with a
total usage of 20.86%, according to the "January 2005 Web Server Survey", conducted by
Netcraft
3
(58,194,836 web sites were scanned).
BEA WebLogic Server
4
, IBM WebSphere Server
5
, Oracle Application Server
6
and the Lotus
Domino Server
7
are currently the mostly used application servers, at least while writing this
thesis.
Regarding database servers, Oracle Database Server
8
, Microsoft SQL Server
9
and IBM-
DB2
10
are currently having the biggest population coverage.
1
This software including its documentation is accessible through the following link: http://httpd.apache.org/.
2
Additional information on Microsoft IIS (as of Windows Server 2003 version) is available at the following URL:
http://www.microsoft.com/WindowsServer2003/iis/default.mspx.
3
Netcraft: The complete "January 2005 Web Server Survey" is available at
http://news.netcraft.com/archives/web_server_survey.html.
4
Detailed information is available at. http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/server.
5
More details on IBM WebSphere are available at the following link: http://www-306.ibm.com/software/websphere/.
6
For product details please see: http://www.oracle.com/appserver/index.html.
7
Details are available at: http://www.lotus.com/products/product4.nsf/wdocs/dominohomepage.
8
Oracle database server details are available at: http://www.oracle.com/database/Enterprise_Edition.html.
9
For details on Microsoft SQL server please see the following link: http://www.microsoft.com/sql/default.mspx.
10
More details on IBM DB2 is accessible at: http://www-306.ibm.com/software/data/db2/.
11 / 83
2 Architecture of a Web Application
2.3 Communication between Web Client and Web Server
While looking again at figure 4, there are basically two mechanisms available which are
responsible for the transport of information between a web client and a web server in a
modern web application: HTTP and HTTPS. Justified by their importance for web
applications they will be described in the following chapters, additionally visualized through
their positioning within the ISO/OSI Reference Model.
2.3.1 The ISO/OSI Reference Model
For a better understanding of the upcoming chapters the ISO/OSI Reference Model and
HTTP and HTTPS - as the two most important protocols - and their placement within the
model will briefly be explained. The ISO/OSI Reference Model consists of 7 different layers.
Each of them is responsible for one specifically defined functionality. For the constitution of
the model please see the figure below:
Figure 5: The ISO/OSI Reference Model inclusive important internet protocols
Furthermore it is important to know that the ports are assigned to the transport layer, which
is also referred to as layer 4. The TCP ports and UDP ports both can range from 0 to 65535,
which is equivalent to 2^16 different ports
1
. The ports ranging from 0 to 1023 are called well
known ports, and these are the dedicated ports for the two protocols which will be important
for the further reading of this thesis:
·
TCP port 80, which is dedicated to the HTTP protocol
·
TCP port 443, which is used for HTTP over SSL
1
An actual list of the complete port-range is available at http://www.iana.org/assignments/port-numbers. IANA is the
abbreviation for "Internet Assigned Numbers Authority".
12 / 83
2 Architecture of a Web Application
IP source and destination addresses (e.g. 192.168.0.1 as an private range IP-address or
88.77.155.233 as a randomly generated public range IP-address) are assigned to the network
layer, which will later also be referred to as layer 3.
Regarding the ISO/OSI Reference Model in respect to the thesis the information actually
provided should be sufficient for an adequate understanding of the upcoming chapters, as
ports and IP-addresses, HTTP and HTTP over SSL will be mentioned several times further
on. For additional information please see [1].
2.3.2 HTTP
HTTP (Hyper Text Transport Protocol), which is specified in RFC 2616
1
, typically operates
on TCP well-known port 80, but can exist on any unused port. Although this may be possible,
nearly all web browsers automatically attempt to establish a connection through port 80 and
practically every web server listens on this port for incoming connections as well.
"HTTP's simplicity derives from its limited set of basic capabilities, request and
response. HTTP defines a mechanism to request a resource, and the server returns
that resource if it is able. Resources are called Uniform Resource Identifiers (URI's)
and they can range from static text pages to dynamic streaming video content [5]."
To give a short overview of this important transport protocol, here the official abstract
provided in RFC2616:
"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
distributed, collaborative, hypermedia information systems. It is a generic, stateless,
protocol which can be used for many tasks beyond its use for hypertext, such as name
servers and distributed object management systems, through extension of its request
methods, error codes and headers. A feature of HTTP is the typing and negotiation of
data representation, allowing systems to be built independently of the data being
transferred."
2.3.3 HTTP over SSL
Another possibility for the usage of HTTP in order to transport the HTML information over
networks is to tunnel HTTP over another protocol called Secure Socket Layer (SSL)
2
. This is
generally also referred to as HTTPS. SSL was originally developed by Netscape
Communications, but today is included as mandatory component in nearly every browser
available. Therefore, in 1996 the IETF Transport Layer Security (TLS) working group was
established to create an open stream encryption standard. SSL Version 3.0 was used as basis
for the TLS protocol developed by the IETF. SSL/TLS typically operates via TCP port 443
[5]." The actual RFC 2246 ("The TLS Protocol Version 1.0 January 1999) is accessible at
http://www.ietf.org/rfc/rfc2246.txt.
1
RFC: This stands for "Request For Comments" and provides specifications to dedicated protocols, like HTTP in our
current case. These RFC's are accessible via http://www.ietf.org/rfc, the Internet Engineering Task Force (as Part of the
Internet Society), which is responsible for the architecture of the WWW and the definition of the required protocols.
2
HTTP over SSL: Also known as HTTP encapsulation.
13 / 83
Ende der Leseprobe aus 106 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2005, Application Level Security Management, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/223681
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare