Security Testing – Scenarios and
Test Cases
Introduction
Definition:
Application Security Testing is defined as a process of
identifying the various vulnerabilities in a system that are exposed because of
improper design or coding issues.
A
software application might be completely functional in every way possible, yet
still can be exploited by hackers and malicious users. This is due to the fact
that security bugs are inherently different than functional bugs, which is why
specialized skills are required. Hence security testing is important.
Background:
Security is often a non-functional entity that is overlooked in most
software development projects. Security breaches not only cost companies money,
but also a loss of business and market confidence. This material explains
security testing which is applicable to testers, developers, business analyst
and managers. It provides insight into the various security vulnerabilities and
threats that systems are being exposed to and measures on how to prevent
security breaches.
Objectives of Security Testing
The security testing is carried out to ensure that the software under
test is sufficiently robust and functions in an acceptable manner even in the
event of a malicious attack.
The objectives of security testing are
1) To ensure that adequate attention is provided to identify the
security risks.
2) To ensure that a realistic mechanism to define & enforce access
to the system is in place.
3) To ensure that sufficient expertise exists to perform adequate
security testing.
4) To conduct reasonable tests to confirm the proper functioning of
the implemented security measures.
Concepts of Security Testing
Some of the basic security concepts that are covered in Security
testing are:
•
Confidentiality - A security measure which protects against the disclosure of
information or data to unauthenticated or unauthorized parties other than the
intended recipient. The most relevant question that can be asked to verify this
is - Does your application keep your private data private?
•
Integrity - A security measure intended to allow the receiver to determine that
the information that is provided is correct. The most relevant question that
can be asked to verify this is - Can the data from your app be trusted and
verified?
• Authentication - A process that
involves confirming the identity of a person, tracing the origins of an
artifact ensuring that a product is what its packaging and labeling claims to
be, or assuring that a computer program is a trusted one. Basically, it allows
a receiver to have confidence that information it receives originated from a
specific known source. The most relevant question that can be asked to verify
this is - Does your application verify you are who you say you are?
•
Authorization - A process of determining that a requester is allowed to receive
a service or perform an operation. e.g. - Access Control. The most relevant
question that can be asked to verify this is - Does your application properly
limit user privileges?
•
Availability - A security measure that ensures that the information must be
available to authorized and authenticated person only. It also assures that
information and communication services will be ready for use when expected. The
most relevant question that can be asked to verify this is - Can an attacker
take the application offline?
• Non – repudiation - A security measure intended to prevent the later
denial that an action happened or communication that took place. In
communication terms, it often involves the interchange of authentication
information combined with some form of provable time stamp, e.g. session id. The
most relevant question that can be asked to verify this is - Does your application
keep records/log of events?
How Security Testing can be a part of Software Development Life Cycle?
Security Testing must be a part of SDLC for a better capture of vulnerabilities
that can cause the firewall of the application to rupture. Following activities
can be undertaken in each phase of SDLC pertaining to Security Testing:
1.
Define Phase:
a)
Define the security requirements
b)
Training for associates on Industry Regulations,
Organizational Policies, Secure Development Policies, Cyber Laws and Standards
and Procedures.
2.
Design/Analysis Phase:
a)
Design the security architecture of the web
application based on industry standards for security patterns.
b)
Analysis of Threat Models and further enhancement
of design based on this.
c)
Data Classification Analysis and design change
for the same in the architecture.
3.
Development:
a)
Security awareness training for developers and
QA.
b)
Security coding guidelines for developers.
4.
Quality Control/Testing:
a)
Code Review with respect to Security flaws
b)
Testing the application for various
vulnerabilities
5.
Implementation:
a)
Release Penetration Testing (Black Box) and
Security Assessment of the application by examining logs, system responses,
error messages, codes, etc.
b)
Account and Password policies (with respect to
the application) must be made public.
c)
Secure Configuration Setup for the production
system.
d)
Auditing and Logging Services for the application
with respect to application security.
e)
Lessons Learnt documentation.
Vulnerabilities to be tested
The different vulnerabilities for which a web application should be
tested are as follows:
a)
Authentication
b)
Session Management
c)
Error Handling
d)
Cross Site Scripting
e)
Anti-Automation
Authentication
It comprises of the following features that can be tested:
a)
User guesses the password - Some websites
allow user to register with
weak password. The
weak password
can be one of dictionary word,
user of either lower or
upper case only, only alphabets, small length password.
b)
Brute Force Attack - Some websites doesn’t
allow
the
account lockout features in case wrong information is entered for more than few attempts. It allows the Brute
Force attack, which is
an automated process of trial and error
to
guess the person username, password and credit
card numbers.
c)
Password Recovery Validation - The attack
happens
when the attacker illegally obtains, or changes another
user’s password.
Following test
cases have been designed for testing the above phenomena:
|
Test Step#
|
Principle to be tested
|
Action
|
Expected Result
|
Actual Result
|
Comments
|
|
1
|
Authentication - Guessing password
|
On the registration page, check the
complexity of the password.
|
The password must be complex as
defined in the requirements
|
|
|
|
2
|
Authentication - Guessing password
|
Check that the password confirms
and required length with combination of lower and upper case and special keywords |
The password must be complex as
defined in the requirements
|
|
|
|
3
|
Authentication - Guessing password
|
Check that the password
is not a dictionary word |
The password must be complex as
defined in the requirements
|
|
|
|
4
|
Authentication - Brute Force Attack
|
On the login page - check that
account lockout
happens after few unsuccessful attempts |
Ideally account lockout must occur
after 3 unsuccessful attempts or as defined in requirements
|
|
|
|
5
|
Authentication - Brute Force Attack
|
Check that the error message
displayed does not tell that which part of authentication credentials is incorrect. |
The error message must say
something like - "You have entered wrong password or username…"
|
|
|
|
6
|
Authentication - Brute Force Attack
|
After the account lockout, try for
login again after some intervals of time, say 5 minutes, 1 hour etc.
|
The login must be unsuccessful all
times after the lockout.
|
|
|
|
7
|
Authentication - Brute Force Attack
|
Login through an Admin user and
enable the above user again. Login with the above user.
|
Login must be successful.
|
|
|
|
8
|
Authentication - Password Recovery
Validation
|
On the Change/Forgot
Password page check the Old Password field. |
The Old Password fields must be
mandatory.
|
|
|
|
9
|
Authentication - Password Recovery
Validation
|
Check the Password field
|
The Password field must not have
Auto Complete feature "On"
|
|
|
|
10
|
Authentication - Password Recovery
Validation
|
Check the new password
|
It must not be displayed on
screen/webpage. It must be send to user on email.
|
|
|
|
11
|
Authentication - Password Recovery
Validation
|
Attempt to enter Old Password as
wrong more than 3 times.
|
The account must get locked.
|
|
|
Session Management
Session management is
necessary to maintain the
identity of user across
multiple requests.
Cookies are information
which is stored on client machine
by
web server. They are basically name-value
pair
which website uses to retrieve data when user visits the site again or across
requests. Attackers can
tamper this
data to acquire information.
a)
Insufficient session
expiration - The application
allows the attacker
to reuse the old session IDs. All it needs for an
attacker is
to know the old session id and he can
reuse the same.
b)
Session Hijacking - If session ids are predictable, it is possibility that attacker can guess the
session id and can use it.
Following test cases can be executed to test the
above:
|
Test Step#
|
Principle to be
tested
|
Action
|
Expected Result
|
Actual Result
|
Comments
|
|
1
|
Session Management – Expiration
|
After login, leave the page idle
for some duration of time. Click on any link.
|
The user must be logged out and
login screen must display. The login page must display relevant message such
as - ''Your session has expired. Please login again to continue."
|
|
The time duration must depend upon
the requirements
|
|
2
|
Session Management – Expiration
|
Repeat the above for all the pages
of the application.
|
The result must be same as above.
|
|
|
|
3
|
Session Management – Expiration
|
Login to application. Copy a URL,
logout, and then paste the above URL in a new browser window/tab. Press
Enter.
|
The user must be logged out. Login
screen must be visible.
|
|
|
|
4
|
Session Management – Expiration
|
Login to the application. Go to
browser history and delete everything. Click on any link.
|
The user must be logged out. Login
screen must be visible.
|
|
|
|
5
|
Session Management – Expiration
|
Login to the application. Copy the
URL. Close the application by clicking on X on the webpage. Open fresh browser
and paste the URL. Press Enter.
|
The user must be logged out. Login
screen must be visible.
|
|
|
|
6
|
Session Management – Expiration
|
Copy a URL, and paste it into a new
browser window. Press Enter.
|
The user must be logged out. Login
screen must be visible.
|
|
|
|
7
|
Session Management – Expiration
|
Login to the application. Copy the
URL from some other user's login screen and paste on current user. Press
Enter.
|
The webpage for the current user
only must be displayed.
|
|
The URL for the other user can be
obtained through mail/IM.
|
|
8
|
Session Management – Expiration
|
Click on Logout. Click on browser
'Back' button.
|
The user must be logged out. Login
screen must be visible.
|
|
|
|
9
|
Session Management – Hijacking
|
Check the session id.
|
The session id must not be predictable.
They must not contain the same username, password, and IP address of the
user.
|
|
Manual checks must include
comparisons of Session IDs issued for the same login conditions – e.g., the
same username, password, and IP address.
|
|
10
|
Session Management – Hijacking
|
Login with the same user in
different browser windows or tabs.
|
This must not be allowed.
|
|
|
|
11
|
Session Management – Hijacking
|
Check the session id in the above
instances.
|
The session id must be same for
both the browser windows.
|
|
|
|
12
|
Session Management – Hijacking
|
Close one of the instances above.
Take note of the session id and logout. Login again. Compare the new session
id with the old.
|
The new and old session ids must
not be same.
|
|
Ideally, there must be no mechanism
that any one can predict the session ids.
|
|
13
|
Session Management – Hijacking
|
Carry out the above step multiple
times.
|
There must be no pattern in session
id generation.
|
|
Based on the previous session ids,
it must not be possible to deduce a fresh one.
|
|
14
|
Session Management – Hijacking
|
Login to the application with
another pair of username/password on a new browser window. Click on any link
on the previous login.
|
The old user must be logged out.
|
|
|
Error Handling
It is common mistake
from
developer that errors are not handled properly and
lot of
information is disclosed
and leads to information disclosure
attack.
a)
Path Traversal - Techniques used to access
the files and folder
which are outside
the web root directory. If you have a website, say - http://somethingsomething.com/ex.html,
just change the URL to point to some file which is not present for example http:// somethingsomething.com/any.html
if the error message thrown is something like file any.html is
not present in C:\test\webapp etc.
Then error message has disclosed very important information
to
the attacker
showing the directory structure
of web server. This can be exploited
by
an attacker for accessing
files and folders that resides outside the root directory.
b)
Predictable Resource Location - Technique used to gain access to hidden content.
The reason is most of the time application follows a similar folder structure
and file naming convention which makes the content more predictable.
Following test cases hold good for testing the
above:
|
Test Step#
|
Principle to be tested
|
Action
|
Expected Result
|
Actual Result
|
Comments
|
|
1
|
Error Handling - Path Traversal
|
For any web page change the URL
such that it contains a file with a random name
|
The error message must not display
the directory structure of the server.
|
|
|
|
2
|
Error Handling - Predictable
resource location
|
Check the file server.
|
Files must not be stored in
sequential manner. The folder structure and file names must not be predictable. |
|
The files must not be saved like -
www. somethingsomething.com/myfiles/fil1.txt
www. somethingsomething.com/myfiles/fil2.txt
www. somethingsomething.com/myfiles/fil3.txt
|
Cross Site Scripting
In this the malicious script is executed
on the
client side. This happens
when server side validation is
not done for the input fields.
a)
Echo type Cross Scripting - In this the input is entered in some
fields on the client machine which is echoed
back
from
the server
b)
Stored Cross Scripting - In this type
of attack, the message is stored
in the
server without proper validation and when clicked
on the message link, the user is redirected to
some
other page and this
can
result in session ID hijacking.
Following
test cases are valid for testing the above concepts.
|
Test Step#
|
Principle to be
tested
|
Action
|
Expected Result
|
Actual Result
|
Comments
|
|
1
|
Cross Site Scripting - Echo type
|
Give the input
<script>Hello World </script> in any field. Submit the form. |
The server must echo back and the
script is executed showing the dialog box “Hello World’
|
|
|
|
2
|
Cross Site Scripting - Echo type
|
Test to check
the inputs
doesn’t accepts the special character such as <> |
|
|
Until stated in requirements <
> special characters must not be allowed
|
|
3
|
Cross Site Scripting - Echo type
|
Go to Internet Options and turn off
the scripts. Click on any link
|
System must display message
“Please turn on your scripts” |
|
|
XSS Me
Cross-Site
Scripting (XSS) is a common flaw found in today’s web applications. XSS flaws
can cause serious damage to a web application. Detecting XSS vulnerabilities
early in the development process will help protect a web application from
unnecessary flaws.
XSS-Me is the
Exploit-Me tool used to test for reflected Cross-Site Scripting (XSS). It does
NOT currently test for stored XSS. The tool works by submitting your HTML forms
and substituting the form value with strings that are representative of an XSS
attack. If the resulting HTML page sets a specific JavaScript value (document.
vulnerable=true) then the tool marks the page as vulnerable to the given XSS
string.
Anti-Automation
Insufficient anti-automation attack
is when a web site permits an attacker to automate a
process that should
be performed manually.
This can even result in denial of
service for some functionality.
|
Test Step#
|
Principle to be
tested
|
Action
|
Expected Result
|
Actual Result
|
Comments
|
|
1
|
Anti- Automation
|
Check the user registration page.
|
This page should not be allowed to
be automated. There must be some mandatory manual entry also.
|
|
|
|
2
|
Anti- Automation
|
Test the CAPTCHA.
|
It should allow to entry data
manually through the keyboard.
|
|
|
|
3
|
Anti-Automation
|
Listen to CAPTCHA text.
|
The user must be able to listen to
CAPTCHA too.
|
|
|
Other flaws and subtleties
Other flaws that must be tested are:
·
SQL Injection - An
SQL injection is often used to attack the security of a website by inputting
SQL statements in a web form to get a poorly designed website to perform
operations on the database (often to dump the database content to the attacker)
other than the usual operations as intended by the designer. SQL injection is a
code injection technique that exploits security vulnerability in a website's
software.
Defense Strategy to prevent SQL
injection:
1. All queries should be
parameterized.
2. All dynamic data
should be explicitly bound to parameterized queries.
3. String concatenation
should never be used to create dynamic SQL.
The following link can be accessed to Fix SQL Injection using the Java
Persistence API
SQL
Inject Me
SQL Injection vulnerabilities can cause a
lot of damage to a web application. A malicious user can possibly view records,
delete records, drop tables or gain access to your server. SQL Inject-Me is
Firefox Extension used to test for SQL Injection vulnerabilities.
The tool works by submitting your HTML forms
and substituting the form value with strings that are representative of an SQL
Injection attack.
The tool works by sending database escape
strings through the form fields. It then looks for database error messages that
are output into the rendered HTML of the page.
The tool does not attempt to compromise the
security of the given system. It looks for possible entry points for an attack
against the system. There is no port scanning, packet sniffing, password
hacking or firewall attacks done by the tool.
You can think of the work done by the tool
as the same as the QA testers for the site manually entering all of these
strings into the form fields.
·
Clickjacking - Clickjacking (User Interface redress attack, UI
redress attack, UI redressing) is a malicious technique of tricking a Web user
into clicking on something different to what the user perceives they are clicking
on, thus potentially revealing confidential information or taking control of
their computer while clicking on seemingly innocuous web pages.
·
Phishing is a
way of attempting to acquire information such as usernames, passwords, and
credit card details by masquerading as a trustworthy entity in an electronic
communication. Communications purporting to be from popular social web sites,
auction sites, online payment processors or IT administrators are commonly used
to lure the unsuspecting public. Phishing is typically carried out by e-mail
spoofing or instant messaging and it often directs users to enter details at a
fake website whose look and feel are almost identical to the legitimate one.
Phishing is an example of social engineering techniques used to deceive users,
and exploits the poor usability of current web security technologies.
·
Buffer Overflow - In
computer security and programming, a buffer overflow, or buffer overrun, is an
anomaly where a program, while writing data to a buffer, overruns the buffer's
boundary and overwrites adjacent memory. This is a special case of violation of
memory safety. Please see the wiki page for this for details:
Buffer
overflow in Java (This is core technical stuff and an architect or developer
will have to take care of this, not QA) -
Java has
array bounds checking which will check that data cannot be accessed from area
outside of the allocated array. When one tries to access area that is beyond
the size of the array, an ArrayOutOfBounds exception will be thrown.
Hence,
Buffer overflows are only possible in unusual scenarios:
1. If
you call native code via JNI
2. In
the JVM itself (usually written in C++)
3. The
interpreter or JIT compiler does not work correctly (Java bytecode mandated
bounds checks)
For
avoiding Buffer Overflow in Java code; following can be a solution:
If the
developers are using C/C++ for development, consider using the following link
for avoiding Buffer Overflow problems:
Penetration Test
A
penetration test, also called pentest, is a method of evaluating the security
of a computer system or network by simulating an attack from malicious
outsiders (who do not have an authorized means of accessing the organization's
systems) and malicious insiders (who have some level of authorized access). The
process involves an active analysis of the system for any potential vulnerabilities
that could result from poor or improper system configuration; both known and
unknown hardware or software flaws, or operational weaknesses in process or
technical countermeasures. This analysis is carried out from the position of a
potential attacker and can involve active exploitation of security
vulnerabilities.
A
penetration test should be carried out on any computer system that is to be
deployed in a hostile environment, in particular any Internet facing site,
before it is deployed. This provides a level of practical assurance that any
malicious user will not be able to penetrate the system.
Planning:
Penetration
testing is not about verifying functionality; it's about verifying the absence
of insecure functionality. Unfortunately, no one normally defines any software
development artifacts for these behaviors, and testers are forced to fend for
themselves.
The first place
to harvest penetration testing information is in the interfaces between the
software and its external environment. User interfaces, network interfaces,
APIs, and any other place where input is processed are clear attack vectors for
hackers. If any of these interfaces are poorly designed or implemented, they
may allow maliciously crafted input to enter and wreak havoc. Identifying and
documenting these interfaces is a good place to start penetration testing.
The second area
requiring special attention is error messages and user alert dialogs, which
communicate information from the software to external users. Since such users
may have malicious intent, it is important to understand what information is
revealed to them and how that information is communicated.
Finally,
penetration testers often define disaster scenarios that specify what a
successful attack might look like. These misuse cases (or abuse cases if you
prefer) often spring from a threat model or from prior known attacks.
Types of
Penetration Tests:
From a security
standpoint, the environment, user input, and internal data and logic are the
primary places where such variation can reveal security issues. The environment
consists of the files, applications, system resources, and other local or
network resources used by the application. Any of these could be the entry
point of attack. User input is the data that originates with external (usually
untrusted) entities that is parsed and used by the software. Internal data and
logic are the internally stored variables and logic paths, which have any
number of potential enumerations.
Ø
Environment Attacks
Software does not
execute in isolation. It relies on N number of binaries and code-equivalent modules, such as
scripts and plug-ins. It may also use configuration information from the
registry or file system as well as databases and services that may reside
anywhere. Each of these environmental interactions may be the source of a
security breach and therefore must be tested.
There are also a
number of important questions you must ask about the degree of trust that your
application has in these interactions, including the following: How much does
the application trust its local environment and remote resources? Does the
application put sensitive information in a resource (for instance, the
registry) that can be read by other applications? Does it trust every file or
library it loads without verifying the contents? Can an attacker exploit this
trust to force the application to do his bidding?
In addition to
the trust questions, penetration testers should watch for DLLs that might be
faulty or have been replaced (or modified) by an attacker, binaries, or files
with which the application interacts that are not fully protected by access
control lists (ACLs) or are otherwise unprotected. Testers must also be on the
lookout for other applications that access shared memory resources or store sensitive
data in the registry or in temporary files. Finally, testers must consider
factors that create system stress, such as a slow network, low memory, and so
forth, and determine the impact of these factors on security features.
Environment
attack checks are often conducted by rigging an insecure environment and then
executing the application within that environment to see how it responds. This
is an indirect form of testing; the attacks are waged against the environment
in which the application is operating.
Ø
Input Attacks
In penetration
testing, the subsets of inputs that come from untrusted sources are the most
important. These include communication paths such as network protocols and
sockets, exposed remote functionality such as DCOM, remote procedure calls
(RPCs) and Web services, data files (binary or text), temporary files created
during execution, and control files such as scripts and XML, all of which are
subject to tampering. Finally, UI controls allowing direct user input,
including logon screens, Web front ends, and the like, must also be checked.
Specifically,
you'll want to determine whether input is properly controlled: are good inputs
allowed in and bad ones (such as long strings, malformed packets, and so forth)
kept out? Suitable input checking and file parsing are critical.
You'll need to
test to see whether dangerous input can be entered into UI controls, and find
out what happens when it is. This includes special characters, encoded input,
script fragments, format strings, escape sequences, and so forth. You'll need
to determine whether long strings that are embedded in packets fields or in
files and are capable of causing memory overflow will get through. Corrupt
packets in protocol streams are also a concern. You must watch for crashes and
hangs and check the stack for exploitable memory corruption. Finally, you must
ensure that such things as validation and error messages happen in the right
place (client-side rather than server side) as a proper defense against bad
input.
Input attacks
really are like lobbing grenades against an application. Some of them will be
properly parried and some will cause the software to explode. It's up to the
penetration team to determine which are which and initiate appropriate fixes.
Ø
Data and Logic Attacks
Some faults are
embedded in an application's internal data storage mechanisms and algorithm
logic. In such cases, there seem to be design and coding errors where the
developer was assuming either a benevolent user or failed to consider some code
paths where a user might tread.
Denial of service
is the primary example of this category but certainly not the most dangerous.
Denial of service attacks can be successful when developers have failed to plan
for a large number of users (or connections, files, or whatever inputs cause
some resource to be taxed to its limit). However, there are far more insidious
logical defects that need to be tested. For example, information disclosure can
happen when inputs that drive error messages and other generated outputs reveal
exploitable information to an attacker. One practical example of such data that
you should always remove is any hardcoded test accounts or test APIs (which are
often included in internal builds to aid test automation). These can provide
easy access to an attacker. Two more tests you should run are to input false
credentials to determine if the internal authorization mechanisms are robust,
and choose inputs that vary the code paths. Often one code path is secure but
the same functionality can be accessed in a different way, which could
inadvertently bypass some crucial check.
What
should you test?
Ø Off-the-shelf
products like servers, smart phones, firewalls and routers etc.
Ø Bespoke
software development like web sites, mobile applications and games etc.
Ø Telephone
equipment like exchanges, smart phones, VOIP and fax servers etc.
Ø Wireless
systems like WIFI networks, RFID tokens, and contactless cash etc.
Ø Physical
protection like CCTV, door entry systems and mechanical locks etc.
Conclusion
So we can see that Security Testing has so
many aspects to test. Hence it must not be made a part of Application Testing
or Functional Testing. Effectively it must be a part of non-functional test
suite. It is an integral part of this test suite.
