INTRO TO SECURITY TESTING
Security testing is an important aspect of software testing focused on identifying and addressing security vulnerabilities in a software application. It aims to ensure that the software is secure from malicious attacks, unauthorized access, and data breaches.
Security testing involves verifying the software’s compliance with security standards, evaluating the security features and mechanisms, and conducting penetration tests to identify weaknesses and vulnerabilities that might be exploited by malicious actors.
The goal of security testing is to identify security risks and offer recommendations for remediation to improve the overall security of the software application. Testers simulate attacks to check existing security mechanisms and look for new vulnerabilities.
SECURITY TESTING-COMMON TEST CASES
TC ID | FEATURE | TEST CASES/STEPS | EXP RESULT |
TC_SECURITY_24 | ACCESS RIGHTS | Objective: To ensure the proper implementation of access rights for each of the application functionalities Pre-req: Test steps: | 1. All credentials should be transferred over an encrypted channel 2. The critical resources/functionalities in the system should be available only to authorized persons and services only, depending on the role of the logged in user |
TC_SECURITY_25 | LOG AUDIT RIGHTS | Objective: To ensure access rights/permissions are in place, for the log files & directory Pre-req: Test steps: | 1. Ensure whether the app has any local logs (stored on device’s file system) 2. Also ensure the logs displayed in logcat doesn’t shows the confidential data like username, password, encryption key, api url or session ID etc |
TC_SECURITY_26 | AUTHENTICATION ENDPOINT REQUEST SHOULD BE HTTPS | Objective: To ensure that the users are asked to submit their authentication credentials only on SSL served pages Pre-req: Test steps: | 1. The URL should contain ‘https’ and a gold lock icon at the bottom of the webpage has to be displayed. 2. This ensures that the user knows who is asking for their credentials as well as where they are being sent. 3. All credentials should be transferred over an encrypted channel |
TC_SECURITY_27 | CODE OBFUSCATION | Objective: To ensure that the source code is in non readable format for human beings, when the application is made public Pre-req: Test steps: | Source code should be in non readable format for human beings |
TC_SECURITY_28 | PARAMETER ANALYSIS | Objective: To ensure whether the application enforces its access control model by ensuring that any parameters available to an attacker would not afford additional service Note: This includes URL query strings, client-side script values and cookies |
|
TC_SECURITY_29 | AUTHENTICATION BYPASS | Objective: To ensure that the authentication process cannot be bypassed Note: Typically, this happens in conjunction with flaws such as SQL Injection |
|
TC_SECURITY_30 | SESSION TOKEN LENGTH | Objective: To ensure that the session token is of adequate length to provide protection from guessing during an authenticated session |
|
TC_SECURITY_31 | SESSION REUSE | Objective: To ensure that the session tokens are changed when the user moves from an SSL protected resource to a non-SSL protected resource |
|
TC_SECURITY_32 | SESSION DELETION | Objective: To ensure that the session token gets expired when the user logout’s from the application | 1. Session tokens should be transmitted over secured channel 2. Check session cookie duration and session termination after timeout or logout 3. Password should not be stored in cookies |
TC_SECURITY_33 | SESSION TOKEN FORMAT | Objective: To ensure that the session token is non-persistent and is never written to the browsers history or cache | 1. Session tokens should be transmitted over secured channel 2. Check session cookie duration and session termination after timeout or logout 3. Password should not be stored in cookies |
TC_SECURITY_34 | HTTP METHODS | Objective: To ensure that the web server does not support the ability to manipulate resources from the Internet (e.g., PUT and DELETE) |
|
TC_SECURITY_35 | VIRTUALLY HOSTED SITES | Objective: Try to determine if the site is virtually hosted. If there are further sites, they could be vulnerable and lead to the compromise of the base server. |
|
TC_SECURITY_36 | WEB SERVER CONFIGURATION | Objective: To ensure that common configuration issues such as directory listings and sample files have been addressed |
|
TC_SECURITY_37 | WEB SERVER COMPONENTS | Objective: To ensure that web server components such as Front Page Server Extensions or Apache modules do not introduce any security vulnerabilities |
|
TC_SECURITY_38 | SSL VERSION | Objective: To ensure that supported SSL versions do not have cryptographic weaknesses Note: Typically, this means supporting SSL 3 and TLS 1.0 only |
|
TC_SECURITY_39 | SSL KEY EXCHANGE METHODS | Objective: To ensure that the web server does not allow anonymous key exchange methods Note: Typically ADH Anonymous Diffie-Hellman |
|
TC_SECURITY_40 | SSL ALGORITHMS | Objective: To ensure that weak algorithms are not available Note: Typically, algorithms such as RC2 and DES |
|
TC_SECURITY_41 | SSL KEY LENGTHS | Objective: To ensurethat the web site uses an appropriate length key Note: Most web sites should enforce 128 bit encryption |
|
TC_SECURITY_42 | DIGITAL CERTIFICATE VALIDITY | Objective: To ensure the application uses valid digital certificates Note: To ensure that the digital certificate is valid; i.e., its signature, host, date, etc. are valid |
|
TC_SECURITY_43 | SCRIPT INJECTION | Objective: To ensure that any part of the application that allows input does not process scripts as part of the input Note: Classic case of Cross Site Scripting but includes other scripting as well |
|
TC_SECURITY_44 | OS COMMAND INJECTION | Objective: To ensure the applications will not process operating system commands from the user Hint: This typically includes issues such as path traversal, spawning command shells, and OS functions |
|
TC_SECURITY_45 | LDAP INJECTION | Objective: To ensure the application will not process LDAP commands form the user |
|
TC_SECURITY_46 | CROSS SITE SCRIPTING | Objective: To ensure that the application will not store or reflect malicious script code |
|
TC_SECURITY_47 | SPAM ATTACKS | Objective: To ensure if web application is able to identify spam attacks on contact forms used in the website |
|
TC_SECURITY_48 | PROXY SERVER | Objective: To ensure if network traffic is monitored by proxy appliances Note: Proxy server make it difficult for hackers to get internal details of the network thus protecting the system from external attacks |
|
TC_SECURITY_49 | SPAM EMAIL FILTERS | Objective: To ensure if incoming and outgoing email traffic is filtered and unsolicited emails are blocked Hint: Many email clients come with in-build spam filters which needs to be configured as per your needs. These configuration rules can be applied on email headers, subject or body |
|
TC_SECURITY_50 | DATA SCANNING | Objective: To ensure whether all files are scanned before uploading to the server |
|
TC_SECURITY_51 | HARD CODE VALUES | Objective: To ensure the hard coded values are not used in the code Eg: Public Variables, Comments |
|
TC_SECURITY_52 | MEMORY LEAKS & BUFFER OVERFLOW | Objective: Test for memory leakage and buffer overflow |
|
TC_SECURITY_53 | TROJAN ATTACKS | Objective: To ensure if incoming network traffic is scanned to find Trojan attacks |
|
TC_SECURITY_54 | USERNAME | Objective: To ensure that the username is not public (or “wallet”) information such as e-mail or SSN Note: Username should not be ‘Hard coded’ |
|
TC_SECURITY_55 | BACKUP FILES | Objective: To ensure that no backup files of source code are not accessible on the publicly accessible part of the application |
|
TC_SECURITY_56 | OPEN PORTS | Objective: Ensure there are no open port(s) used by the application |
|
TC_SECURITY_57 | NETWORK | Objective:1. To ensure whether the invading access to all servers, desktop systems, printers and network devices are not allowed by ensuring WIFI network security |
|
TC_SECURITY_58 | REGISTRY ENTRIES | Objective: To ensure that sensitive information is not kept or stored in registry entries |
|
TC_SECURITY_59 | INFRASTRUCTURE ADMIN INTERFACES | Objective: To ensure that the administrative interfaces to the application or web servers are not accessible to the Internet | The administrative interfaces to infrastructure, such as web servers and application servers, should not be accessible to the Internet |
TC_SECURITY_60 | SENSITIVE DATA IN HTML or COOKIES | Objective: To ensure that there is no sensitive data in the HTML or stored cookies which could lead an attacker to mount a focused attack Hint: Occurs when developers leave information in HTML comments or the application renders names and addresses in HTML Test Steps: 1. View the source code in HTML, after the application usage | 1. There has to be no sensitive data in the HTML or cache memory or browsed history or cookies 2. Cookie information should be stored in encrypted format only 3. Password should not be stored in cookies |
TC_SECURITY_61 | SESSION COOKIE DURATION | Objective: To validate the session cookies duration Test Steps: 1. View the source code in the stored cookies, after the application usage | 1. Session tokens should be transmitted over secured channel 2. Check session cookie duration and session termination after timeout or logout 3. Password should not be stored in cookies |
TC_SECURITY_62 | SESSION COOKIE DURATION | Objective: To validate the session cookies duration Test Steps: 1. View the source code in the stored cookies, after the application usage | 1. Session tokens should be transmitted over secured channel 2. Check session cookie duration and session termination after timeout or logout 3. Password should not be stored in cookies |
TC_SECURITY_63 | SQL INJECTION | Objective: To ensure that the application doesn’t allow external queries or commands from an outsider Test Steps: 1. Launch & login to the application | The application should not process external SQL queries/commands from outsider |
TC_SECURITY_64 | ENCRYPTION OF SENSITIVE DATA | Objective: To ensure the transmission of sensitive data in an encrypted format over secured connection like https 1. Launch the application | The user data has to be transmitted over a secured connection like https in an encrypted format |
TC_SECURITY_65 | INPUT VALUE HANDLING | Objective: To ensure that the special characters, html tags and scripts are handled as an input value by the application Test Steps: 1. Launch & login to the application | The application has to accept the special characters, html tags and scripts as an input value(s) |