0% found this document useful (0 votes)
7 views

softwre project test case (1) (1)

The document outlines various test cases for security testing of customer account authentication processes, including password strength validation, brute force attack protection, session management, and multi-factor authentication. It emphasizes the importance of input validation, secure transmission, and error handling to prevent vulnerabilities. Additionally, it discusses both manual and automated testing approaches for authentication and authorization, providing examples for effective implementation.

Uploaded by

joshisamruddhi14
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views

softwre project test case (1) (1)

The document outlines various test cases for security testing of customer account authentication processes, including password strength validation, brute force attack protection, session management, and multi-factor authentication. It emphasizes the importance of input validation, secure transmission, and error handling to prevent vulnerabilities. Additionally, it discusses both manual and automated testing approaches for authentication and authorization, providing examples for effective implementation.

Uploaded by

joshisamruddhi14
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

Conduct security testing on a customer

account authentication process


Whats Authentication Testing ?
Authentication testing means to understand how the
authentication works and then trying to use some of the bypasses
in order to test whether it has been implemented properly or not.
For example what are the ways an application is using to
authenticate the user

Test Case: Password Strength Validation


Objective: Ensure that the password meets the required complexity and strength criteria.

• Test Case ID: TC-001

• Scenario : Validate that passwords meet the complexity requirements defined by the security
policy.

• Preconditions: User is on the account creation or password change page.

• Steps:

1. Enter a password that does not meet the complexity requirements (e.g., less than 8
characters, no special characters).

2. Submit the form.

• Expected Result: The system should reject the password and display a message indicating the
password does not meet the strength requirements.

1. Test Case: Brute Force Attack Protection


Objective: Verify that the system has mechanisms to prevent brute force attacks.

• Test Case ID: TC-002

• Scenario: Test the system’s response to repeated failed login attempts.

• Preconditions: User is on the login page.

• Steps:

2. Attempt to log in with incorrect credentials multiple times (e.g., 10 attempts).


• Expected Result: After a predefined number of failed attempts, the account should be
temporarily locked, or additional measures (e.g., CAPTCHA) should be triggered.

3. Test Case: Session Management


Objective: Ensure that session tokens are securely managed and protected against hijacking.

• Test Case ID: TC-Auth-003

• Scenario : Validate that session tokens are securely generated and managed.

• Preconditions: User is logged in.

Steps:

1. Log in to the application and capture the session token.

2. Log out and attempt to reuse the captured session token.

• Expected Result: The application should invalidate the session token upon logout, and reuse of
the token should be rejected.

4. Test Case: Multi-Factor Authentication (MFA) Functionality


Objective: Ensure that MFA is functioning correctly and provides an additional layer of security.

• Test Case ID: TC-004

• Scenario :Test the MFA process for successful authentication.

• Preconditions: MFA is enabled for the user account.

• Steps:

1. Log in with valid credentials.

2. Enter the MFA code received via SMS or an authenticator app.

• Expected Result: The system should successfully authenticate the user if the MFA code is
correct.

5. Test Case: SQL Injection in Login Form


Objective: Check for SQL injection vulnerabilities in the login form.

• Test Case ID: TC-005

• Scenario: Test the login form for SQL injection vulnerabilities.

• Preconditions: User is on the login page.

• Steps:
Enter a malicious payload in the username or password field (e.g., ' OR '1'='1).

1. Submit the form.

• Expected Result: The system should not execute unintended SQL queries, and the login attempt
should be rejected.

6. Test Case: Password Storage Security


Objective: Verify that passwords are securely hashed and salted.

• Test Case ID: TC-006

• Scenario : Check if passwords are stored securely in the database.

• Preconditions: Access to the database is available.

• Steps:

1. Retrieve stored password hashes from the database.

2. Verify that hashes are generated using a strong hashing algorithm (e.g., bcrypt, Argon2)
and include salt.

• Expected Result: Passwords should be stored as salted hashes using a secure hashing algorithm.

7. Test Case: Error Message Disclosure


Objective: Ensure that error messages do not disclose sensitive information.

• Test Case ID: TC-007

• Scenario : Verify that error messages do not reveal details about the authentication process.

• Preconditions: User is on the login page.

• Steps:

1. Enter invalid credentials.

2. Submit the form and observe the error message.

• Expected Result: The error message should be generic and should not reveal whether the
username or password was incorrect.
8. Test Case: Error Message Disclosure
Objective: Ensure that error messages do not disclose sensitive information.

• Test Case ID: TC-007

• Scenario : Verify that error messages do not reveal details about the authentication process.

• Preconditions: User is on the login page.

• Steps:

3. Enter invalid credentials.

4. Submit the form and observe the error message.

• Expected Result: The error message should be generic and should not reveal whether the
username or password was incorrect.

9. Test Case: Cross-Site Scripting (XSS) in Login Form


Objective: Test for XSS vulnerabilities in the login form fields.

• Test Case ID: TC-008

• Scenario : Check the login form for XSS vulnerabilities.

• Preconditions: User is on the login page.

• Steps:

1. Enter a script payload in the username or password field (e.g.,


<script>alert('XSS')</script>).

2. Submit the form and observe the behavior.

• Expected Result: The application should not execute the script, and the login attempt should be
rejected.
10. Test Case: Session Timeout
Objective: Verify that sessions expire after a period of inactivity.

• Test Case ID: TC-009

• Scenario : Test that sessions time out after a period of inactivity.

• Preconditions: User is logged in.

• Steps:

1. Log in and remain idle for the session timeout period.

2. Attempt to perform an action after the timeout period.

• Expected Result: The user should be required to log in again after the session has expired.
11. Test Case: Password Reset Functionality
Objective: Ensure that the password reset process is secure.

• Test Case ID: TC-010

• Scenario : Test the security of the password reset process.

• Preconditions: User has a registered email address.

• Steps:

1. Initiate a password reset request.

2. Follow the reset link received via email.

3. Set a new password.

• Expected Result: The password reset process should be secure, and the new password should be
set successfully without exposing sensitive information.

These test cases cover a broad range of security aspects related to customer account authentication. By
executing these tests, you can identify potential vulnerabilities and ensure that the authentication
process is secure and robust.
1. security Features

1.1. Input Validation

• Client-Side Validation:

o Implement HTML5 attributes like required and maxlength.

o Use JavaScript for additional validation (e.g., format checks).

• Server-Side Validation:

o Always validate and sanitize input on the server to prevent SQL injection and other
attacks.

1.2. Secure Transmission

• HTTPS: Ensure the page is served over HTTPS to encrypt data in transit.

1.3. Password Handling

• Password Field:

o Use the <input type="password"> element to obscure password input.

o Implement policies to enforce password strength (e.g., minimum length, complexity).

1.4. Authentication Mechanisms

• Multi-Factor Authentication (MFA):

o If MFA is implemented, include an additional step after the initial login form.

o Provide fields for MFA codes and a submission button for verification.

1.5. Error Handling

• Generic Error Messages:

o Use generic error messages like "Invalid username or password" to avoid revealing
specific details about failed login attempts.

1.6. Rate Limiting and Lockout

• Rate Limiting: Implement rate limiting to prevent brute-force attacks.

• Account Lockout: Temporarily lock accounts after multiple failed login attempts and notify the
user via email.
How to test Authentication and
Authorization?
Authentication and authorization can be tested either manually or in an automated
way. Either way, we must create some happy scenarios and negative scenarios as
well. Although successfully testing happy scenarios is important, creating edge
cases to uncover potential flaws in design or bugs is also crucial to the overall
product quality. Let’s dive into how you can test them manually using a very basic
approach.
Test Cases for Testing Authentication

Name Objective Example

Successful Verify that users with valid credentials Enter a valid username and password, and
authentication can successfully authenticate confirm successful login

Invalid Ensure that users with invalid credentials Enter an incorrect password for a valid
credentials cannot access the system username and verify that the login fails

Account Test how the system would response to Test how the system would respond to several
locked several failed login attempts failed login attempts

Verify that users can successfully recover


Password Test how the system would respond to several
their accounts by using the password
recovery failed login attempts
recovery functionality

Session Confirm that session management is in Click on the “Forgot Password” button, enter
management place by preventing unauthorized access the registered email, and confirm that a
password reset email has been sent.

Test Cases for Testing Authorization


Name Objective Example

Ensure that users can access only Log in as a regular user and attempt to
Successful authorization to a
the resources they are authorized access an admin-only page, ensuring
resource
to view access is denied

Log in with different user roles (e.g.,


Verify that user roles are assigned admin, regular user) and verify that each
Role-based access
correctly role can perform only the actions
allowed by their role

Check the system’s response if a Check the system’s response if a A regular user attempts to modify
user tries to access an user tries to access an unauthorized another user’s account information,
unauthorized resource resource ensuring the system denies access

An admin delegates user management


Check if a delegated user can access tasks to a regular user and confirms that
Delegation
a resource the delegated user can perform those
tasks.

Check the system’s response if a Disable a user account and attempt to


Inactive users user tries to access an unauthorized log in with that account, confirming that
resourse access is denied

Since we saw how we can test authentication and authorization


manually, let’s now dive into how we can reduce repetitive work,
decrease execution time, and improve quality by introducing automation.
Frameworks like Rest Assured, Selenium, or tools like Postman can be
employed for automated testing. We’ll take reqres.in as our dummy API
to make HTTP calls.
Automating Authentication and Authorization Testing
Postman examples:
▪ Valid Credentials Test
▪ Create a POST request to the API login endpoint with valid credentials
▪ Use test assertions to verify the status code and response message, e.g.
that your login attempt was successful

▪ Invalid Credentials Test


▪ Create a POST request to the API login endpoint with invalid
credentials
▪ Use test assertions to verify if the status code and response message
are correct, e.g. that your login attempt failed (typically you would get
401 status code)
▪ Role-Based Access Control Test
▪ Use an authenticated user to make a GET request to a resource only accessible
to specific roles
▪ Confirm that the unauthorized access attempt message is returned along the
the status code

You might also like