Introduction to At a Glance:

Because we now have new opportu-

Testing Web
nities to communicate, we also have
new opportunities for misuse. Even
though every application is different,
there are some general industry-
standard risk areas for Web applica-

Application tions. This article addresses Web

security testing at the application
level.

Security by Tim Van Tongeren

Unlike most client-only applications, Web
based applications have viewable code,
access to the contents of the Web server,
and information that can be intercepted.
Because of these new opportunities to
communicate, there are also new opportu-
nities for misuse.
Most of the security testing literature looks
at vulnerabilities of the network and Web
server, but this article discusses Web secu-
rity testing at the application level. Much
attention is given to the network and Web
server, but sometimes the applications
they are housing are not secure.
Additionally, when testing a Web applica-
tion, the tester does not always know the
network architecture, operating system, or
Web server for each implementation of the
application. Finally, the risk areas dis-
cussed in this article allow average users
to stumble on secure information. These
risk areas do not require a malicious user
to run a Perl script or use network penetra-
tion tools; they can be exploited with the
browser and a text editor.
The amount of security testing one should
perform generally depends on the type of
application under test. The level of testing
required should be based on the security
requirements, which should be defined by
a requirements analyst, like other non-
functional requirements. When there are
no requirements or requirements are not
complete, the tester can use the risk areas
identified in this article to raise concerns.
Even though every application is different,
there are some general industry-standard
risk areas for Web applications. The risk
areas that we will examine in this article
are:
• User authentication
• User authorization
• Security holes in the application
• Data access through the URL
• Altered client code
User Authentication
In order to be identified as a user, so one
can gain authority to perform tasks, some
Web systems require users to register and
be verified via a login process. Generally,
the users will login with a User ID and a
password.
Before one can just log in to the applica-
tion, their user profile must be created in
the system. For some Web applications,
the user can register and create an online
profile. For other Web applications, only
the system administrator can create user
profiles. The registration process should
be tested for potential security risks. For
example, if the user sets the password, it
should be a required field. If the password
is assigned by the system, there should be
business rules concerning generation,
delivery and first-use of passwords. For
example, duplicate, identical users should
not be allowed to register.
The verification portion of the application
should be tested to ensure that valid user
and password combinations allow access
and that invalid user and password combi-
nations do not allow access. There may be
other security requirements like a log file
of failed logins, the disabling of profiles
after a certain number of incorrect logins,
or the disabling of access after a certain
number of failed logins. There should also
be verification of proper logout processes,
including the handling of session timeouts,
user requested logouts, and logouts by
navigating away from the site.
Another potential security risk with logins
is when cookies are used. A cookie is
information stored on the client machine

September/December 2001 http://www.testinginstitute.com Journal of Software Testing Professionals 41

with which the Web server can interact
(read and write privileges.) Cookies can
store any information the user sends to the
Web application, either entered by the user
or automatically sent by the client brows-
er. Additionally, cookies may store infor-
mation derived by the server.
Generally, cookies store things like names,
User IDs, passwords, and browsing trends.
By storing the authentication information
on the client machine, the user does not
need to enter the User ID and password at
each login. With these applications, the
system should be tested to ensure that
cookie processing is secure.
The most common way to ensure cookie
security is with encryption. If not, the
cookies.txt file could be read or altered. If
a malicious user knew the structure of the
cookies used by the application, they
could check clients for the cookies and
extract additional personal information
contained in them. Likewise, they could
create a cookie on their client to pose as
another user, and be allowed access to per-
form the tasks allowed for that user.
User Authentication with
Cookies
Let’s go through a sample test of cookies.
The cookie for this application stores the
username. There is also a requirement that
the most recent successful login shall
become the default User ID for the com-
puter. Based on these requirements here
are a few scenarios we can test:
Scenarios
1. Valid login
2. Valid login, return to site and use
cookie for authentication
3. Valid login, valid login with different
username
4. Invalid login due to unregistered
username
5. Invalid login due to incorrect pass-
word for username
42 Journal of Software Testing Professionals
Using these scenarios, we can consolidate
them into test cases. Test Case 1 will incor-
porate Scenario 1 and 2. Test Case 2 will
incorporate Scenario 3 and 2. Test Case 3
will incorporate Scenario 2 and 4. Test
Case 4 will incorporate Scenario 2 and 5.
Test Cases
1. Log in with USERNAME1. Verify that
the cookie stores USERNAME1. Go back
to the site and verify that the cookie stored
USERNAME1 as the default username
for that client.
2. Log in with USERNAME1. Log out
and verify that the cookie stored USER-
NAME1. Return to the site and log in with
USERNAME2. Verify that the cookie
stores USERNAME2.
3. Log in with USERNAME1. Log out
and attempt to log in with USERNAME3
(which does not exist). Verify that the sys-
tem gives a login error. Verify that the
cookie stored USERNAME1. Go back to
the site and verify that it allows login with
USERNAME1.
4. Log in with USERNAME1. Log out
and attempt to log in with USERNAME2
and an incorrect password. Verify that the
system gives a login error. Verify that the
cookie stored USERNAME1. Go back to
the site and verify that it allows login with
USERNAME1.
To verify that the cookie stores the correct
User ID the tester can take either a black-
box or white-box approach. Using the
black-box approach, the tester would use
the Web application to display the current
User ID. Even if the password is not
stored, the User ID may populate in the
login field. The white-box approach to
verification would have the tester verify
the contents of the cookie file on the client
machine. Since cookies are generally
encrypted, this will require a separate pro-
gram that decrypts the contents of the
cookie for verification.
A variation on this application might
http://www.testinginstitute.com
include a checkbox on the login screen to
allow the user to tell the system to store the
username (e.g. “remember me”). In this
case, you will need to make sure that when
the box is checked, the cookie stores the
username, but when it’s not checked, the
cookie does not store the new username
and that it retains the current default user-
name.
Also, when testing cookies, don’t forget to
delete old ones if the test case requires the
server to act as if this is a new visitor. In
between execution of each of the test cases
described in our example above, the cook-
ie should be deleted on the client machine,
as an initialization step, to ensure a clean
test.
User Authorization
Once granted permission to access the
application, the user is allowed to perform
tasks. Most Web applications have multi-
ple user groups or roles with different lev-
els of authority. Some of these groups may
include the general public, registered
members, moderators, and the administra-
tor. Members of each of these groups have
different privileges within the application.
The definition of each group and access
allowed to its members should be speci-
fied in the requirements.
To verify that these rules are enforced by
the system, the tester will need to perform
positive and negative testing for each sys-
tem task with a user profile from each
group. For example, let’s look at some
security requirements for a message board
application. In order to perform a test from
Table 1, you should create a user in each of
the user groups. Then for each user, test
each of the authorities. (See Table 1.)
If the system supports the functionality to
change a user’s group, then additional test-
ing should be done to ensure that the
allowed actions are changed as well. In the
above example, if a user is moved from
the Moderator group to the Members
group, he should no longer be able to
September/December 2001
 User Group Read Message Post Message Delete Message Delete User
Public Allowed Prohibited Prohibited Prohibited
Members Allowed Allowed Prohibited Prohibited
Moderator Allowed Allowed Prohibited Prohibited
Administrator Allowed Allowed Allowed Allowed
Table 1: User groups and authorities for a message board application

delete a message.
Security holes in the
program
During security testing, the tester should
verify that the system is safeguarded
against a command language invocation
attack. This type of attack attempts to
force the server to execute operating sys-
tem commands by using escape charac-
ters, overflowing the buffer, or overriding
parameters in the programs. The easiest
targets are the default programs included
with a system since these vulnerabilities
are well known. For example, there are
several CGI programs that come standard
on UNIX. Since anyone with UNIX has
access to them, malicious users can figure
out how to use or break them. With some
of these programs, if a bad character is
sent as a parameter the program will exit
and then the rest of the command, still in
the buffer, is executed at the command
line.
So, let’s say that a backtick was an escape
character that exited a specific program
named lookup.pl. This program would be
working fine until it attempted to process
the backtick. Upon hitting the backtick
character, the program would hit an error
condition where it failed over to the com-
mand line. Everything after the backtick,
still in the buffer, would be executed at the
command line. Imagine what would hap-
pen if you typed in this URL:
www.server.com/cgi-bin/lookup.pl`rm-rf
Other, less destructive attacks might only
steal password files or other sensitive data.
But in this case, the command “rm-rf”
would be sent to the system’s command
line and it would start deleting files.
The same principle applies to proprietary
applications. Buffer overflows and escape
characters should not give access to the
operating system. To avoid this security
hole, test the application for escape char-
acters. Make sure that the system does not
rollover to the command line when the
application receives bad parameters. In the
above example, perhaps the application
should give a general error message
instead.
Data access through the
URL
Another attack that can be made from the
location field of a browser is parameter
tampering. When a malicious user uses
this technique they modify the parameters
of SQL statements in the URL to try to
retrieve or modify data.
You may have done something similar to
save time. Let’s say you are looking up
stock prices on a certain site. If you like
viewing the 5-year chart for the stock per-
formance, but the default chart is the 1-
year chart, you may just go up the URL
and change the Year field. If you want to
switch tickers you may just change it in
the URL rather than submitting a new
request through the Submit button. For a
certain application, the URL for the five-
year, detailed chart of McDonalds might
be:
www.server.com/5yr+DetailView+MCD
When this specific application receives
these parameters it submits a query for a
five-year set of data with the detailed view
for the ticker of “MCD”. Each value is a
specific field in a pre-built query that is
sent to a database. Then retrieving the
information in the database, the applica-
tion builds a Web page. Based on the pre-
vious example, we can view the chart for
IBM, for example, by changing the
“MCD” to “IBM”.
www.server.com/5yr+DetailView+IBM
Now, let’s take this data access a step fur-
ther. Let’s say your current URL is this:
www.server.com/pgm.exe&Function=Re
view&Order=1029343
This URL returned a page that reviewed a
customer order #1029343. Now, what
would happen if the server did not verify
commands before invoking them? For
example, if you changed the order num-
ber, the system would allow you to see
other orders, as well as the order details.
What if you changed the Function from
Review to Create, Update, or Delete?
Some URLs are not that obvious but
unless the URL is encrypted it doesn’t take
very long to figure out the syntax. One
preventative measure that sites can use is
passwords or entry codes that change
every second. If the command in the URL
doesn’t have the code-of-the-second, it
won’t perform the query.
For a stock application, like we discussed
above, public users can usually view all of
the data. However, with other applications

September/December 2001 http://www.testinginstitute.com Journal of Software Testing Professionals 43

users should not have access to all data in
the database. The server should verify the
data before simply processing it. For
example, what would the server do with
this URL?
www.server.com/pgm.exe&Function=Re
view&Order=Hello!
After doing this on one Web server, the
system presented an error screen that con-
tained a login to administer the database!
The data entered caused a variable type
mismatch error, which rolled over to a
generic error-handling module. That mod-
ule pointed to a login page for the data-
base, which may have been helpful during
development, but not in a production envi-
ronment.
Altered Client Code
Rather than having application parameters
in the address, as described above, some
applications have parameters in the client
code. If one viewed the source code, they
could see those parameters and attempt a
similar attack, called embedded SQL
hijacking.
Data access that should be disallowed
might be allowed, but there are other prob-
lems as well. Parameters such as item
prices in the client code can be altered. If
the server does not verify these fields, the
customer could purchase the item at the
wrong price.
To make matters more complicated, veri-
fication logic can be inside the client code.
In an effort to improve the performance of
the Web server, developers may include all
of the verification logic with the client
rather than the server. Even so, the client
code could be altered.
Client-based verification logic such as
field lengths, data format, and mandatory
field verification are dangerous. If the field
length edits are changed, a buffer overflow
would be allowed and might crash the
application. If the data format verifications
44 Journal of Software Testing Professionals
are altered, the application could write
data improperly to the database, causing
lost or corrupted data. If the client is
changed allow mandatory fields to be
bypassed, a customer request may not be
fulfilled.
Each program on the Web server should
verify all data it receives: from clients,
other programs on the Web server, and
third party sources. If the program
assumes the data is correct and processes
it, there could be a security hole. Client
code can be changed. Programs can be
written to send malicious transactions to
your program.
To test this a tester can save the page to the
local drive. Then, modify the code to
attempt the desired query, bypass the
client edits, or alter the price of an item.
Finally, open the page in a browser. The
page should make a call to the Web server
as if it was the real page. If the server does
not catch the improper requests from the
altered client, there is probably a security
concern.
Conclusion
Many opportunities exist in Web applica-
tions for security violations. The good
news is you are now aware of some of
those issues and are able to incorporate
them into your next test plan. With this
knowledge you should be better prepared
to test Web applications and to protect
your company’s software from unautho-
rized use.
Testers wanting to learn more about Web
application security might also be interest-
ed in security risks due to improper error
handling. Overly descriptive error mes-
sages sometimes include data that can be
used for unauthorized use. Improper error
handling sometimes results in login
screens or other point of access not meant
for the public user. Additionally, perform-
ance issues occasionally cause errors due
to simultaneous database updates or sys-
tem crashes, which subsequently offer
http://www.testinginstitute.com
information about the system or login
screens.
After testing the security of the applica-
tion, the tester may need to validate the
security of third party applications with
which the main application interacts, the
Web server which hosts the application,
and the network on which the web server
resides.
About the Author
Tim Van Tongeren is a senior quality
assurance analyst at WorldCom. He has
experience across the software develop-
ment lifecycle working on government
and private projects with several Fortune
500 companies.
Call for Submissions
JSTP is looking for articles reflecting
real life experiences with any of the fol-
lowing areas:
• Testing
• Requirements
• Bug Tracking and Reporting
• Incident Management
• Configuration Management
• Release Management
• Risk Assessment
• Test Process Measurements
and Improvements
For guidelines, please visit our Web
site:
www.testinginstitute.com
September/December 2001