Professional Documents
Culture Documents
November 2008
Table of Contents
1.
2.
Preface ................................................................................................................. 3
1.1.
General ......................................................................................................................... 3
1.2.
2.2.
2.2.1.
2.2.2.
2.3.
3.
2.3.1.
2.3.2.
2.3.3.
White Paper
Page 2
1. Preface
1.1. General
Enabling organizational processes and applications for the Internet is a critical
requirement in todays business landscape. As a result, strong network level protection
against attacks, such as firewalls and intrusion detection systems, is mandatory in all
enterprise Web Application environments, as such threats impose real risk and high costs.
However, hacking techniques are now designed to legitimately access a Web Application
and attack back-end systems using transactions that appear to be normal. These well
publicized Web application level attack techniques cannot be detected by network
firewalls and intrusion detection systems. Web Application attacks pass through
unchecked, enabling access to sensitive information and systems. In addition, since this
entire activity looks like perfectly legitimate Internet traffic, the network security team is
completely unaware of these attacks unless someone happens to notice their effects.
This paper provides an overview of Web Application Security and discusses the following
topics:
White Paper
Page 3
Background on HTTP
HTTP is the network protocol used to deliver virtually all files and other data (collectively
referred as resources) on the World Wide Web, including HTML files, image files, query
results, or using any other format.
A browser, known as an HTTP client, sends requests to an HTTP server (Web server),
which then sends responses back to the client. HTTP usually takes place over TCP
White Paper
Page 4
connections, usually using port 80, though this can be overridden so that another port is
used.
After a successful connection, the client transmits a request message to the server, which
sends a reply message back. The simplest HTTP message is "GET <URL>", to which the
server replies by sending the named document. If the document does not exist, the server
will send an HTML-encoded message stating that.
HTTP is used to transmit resources, not just files. A resource is a chunk of information
that can be identified by a Uniform Resource Locator (URL - resources are the R in URL).
The most common type of resource is a file, but a resource may also be a dynamicallygenerated query result, the output of a CGI script, the output of a PHP or any other
dynamic Web scripting language, Java servlets, a document that is available in several
languages, or something else.
2.2.2.
HTTP Methods
HTTP defines eight methods (sometimes referred to as "verbs"), indicating the desired
action to be performed on the identified resource, as follows:
HEAD: Asks for the response identical to the one that would correspond to a GET
request, but without the response body. This is useful for retrieving metainformation written in response headers, without having to transport the entire
content.
POST: Submits data to be processed (for example, from an HTML form) to the
identified resource. The data is included in the body of the request. This may
result in the creation of a new resource or the updates of existing resources or
both.
TRACE: Echoes back the received request, so that a client can see which
intermediate servers are adding or changing in the request.
OPTIONS: Returns the HTTP methods that the server supports for specified
Universal Resource Identifier (URI). This can be used to check the functionality of
a Web server by requesting '*' instead of a specific resource.
White Paper
Page 5
The Web Application in use by your enterprise may have been created using
different types of technologies and software platforms.
The development personnel in your enterprise might not have had security in mind
while developing the Web Application or may have left backdoors to the
application for maintenance. Furthermore, it is common that the development
personnel have changed jobs or have failed to document the application
structure.
White Paper
Page 6
Vulnerability Class
Summary Description
A2 Injection Flaws
A6
Information
Leakage
Improper Error Handling
and
Applications
can
unintentionally
leak
information about their configuration, internal
workings, or violate privacy through a variety of
application problems. Attackers use this
weakness to steal sensitive data, or conduct
more serious attacks.
A7
Broken Authentication
Session Management
and
White Paper
Page 7
Vulnerability Class
Summary Description
A9 Insecure Communications
2.3.2.
The Web Security Threat Classification is a cooperative effort to clarify and organize the
threats for the security of a Web site. The members of the Web Application Security
Consortium (WASC) have created this project to develop and promote industry standard
terminology for describing these issues. Application developers, security professionals,
software vendors, and compliance auditors will have the ability to access a consistent
language for web security related issues.
The WASC Threat Classification is broken-down to the following main classes:
1) Authentication Authentication threats includes attacks against validation methods
used by Web Applications to validate users, services or applications. The threats that
target the authentication process of Web Applications include the following:
Credential/Session Prediction
Insufficient Authorization
Insufficient Session Expiration
Session Fixation
White Paper
Page 8
Content spoofing
Cross-site scripting
Buffer Overflow
Format String Attack
LDAP Injection
OS Commanding
SQL Injection
SSI Injection
XPath Injection
Directory Indexing
Information Leakage
Path Traversal
Predictable Resource Location
6) Logical Attacks Logical Attack threats focus on the possible exploitation of Web
Application logic flow, by a potential hacker. Application logic is a term that describes
the procedure used by the application to perform a specific action. For example,
account registration, recovering passwords, online purchases, etc. A hacker may
bypass a specific process required by the application; hence find a way to damage
users or the application. These threats include:
2.3.3.
Abuse of Functionality
Denial of Service
Insufficient Anti-Automation
Insufficient Process Validation
Unclassified Application-Layer Attack Types
The following table highlights attack forms that are not classified by any particular
organization, yet they exist. These attack forms may appear as part of any of the above
classifications, or may be a result of a different class completely.
White Paper
Page 9
Forms of Attack
Brief Description
Parameters Tampering
Cookie Poisoning
Database Sabotage
Stealth Commanding
Debug Options
Backdoor
Manipulation of IT
Infrastructure Vulnerabilities
3rd-Party Misconfiguration
Data Encoding
Protocol Piggyback
White Paper
Page 10
Filter Description
Parameters
Security Filter
Global
Parameters
Security Filter
XML Security
Filter
Web Services
Security Filter
Session Security
Filter
Parameters Tampering
Unvalidated Input
Buffer Overflow
Data Encoding
Parameters Tampering
Unvalidated Input
Buffer Overflow
Data Encoding
Unvalidated Input
Buffer Overflow
Parameters Tampering
Unvalidated Input
Buffer Overflow
Parameters Tampering
Web Services
Manipulation
Broken Access Control
Broken Authentication and
Session Management
Insecure Storage
Authorization
Cookie Poisoning
Allow List
Security Filter
Path Blocking
Security Filter
White Paper
Page 11
Authentication and
Session Management
Authentication
Database
Security Filter
Vulnerabilities
Security Filter
Safe Reply
Security Filter
Files Upload
Security Filter *
HTTP Methods
Security Filter *
Logging Security
Filter *
For further information on working with AppWall Security Filters, please refer to the
Security Filters section of the AppWall Management Application online help.
White Paper
Page 12
2008 Radware, Ltd. All Rights Reserved. Radware and all other Radware product and service names are registered trademarks
of Radware in the U.S. and other countries. All other trademarks and names are the property of their respective owners. Print ed
in the U.S.A.
White Paper
Page 13