**WEB TESTING Concepts**

Points to be considered while testing a Web site:

Web sites are essentially client/server applications -
with web servers and 쁞rowser clients.

Consideration should be given to the interactions between html pages, TCP/IP communications, Internet connections, firewalls, applications that run in web pages (such as applets, javascript, plug-in applications), and applications that run on the server side (such as cgi scripts, database interfaces, logging applications, dynamic page generators, asp, etc.).

Additionally, there are a wide variety of servers and browsers, various versions of each, small but sometimes significant differences between them, variations in connection speeds, rapidly changing technologies, and multiple standards and protocols. The end result is that testing for web sites can become a major ongoing effort.

Other considerations might include:

What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required under such loads (such as web server response time, database query response times). What kinds of tools will be needed for performance testing (such as web load testing tools, other tools already in house that can be adapted, web robot downloading tools, etc.)?

Who is the target audience? What kind of browsers will they be using? What kind of connection speeds will they by using? Are they intra- organization (thus with likely high connection speeds and similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)?

What kind of performance is expected on the client side (e.g., how fast should pages appear, how fast should animations, applets, etc. load and run)?

Will down time for server and content maintenance/upgrades be allowed? how much?

What kinds of security (firewalls, encryptions, passwords, etc.) will be required and what is it expected to do? How can it be tested?

How reliable are the site셲 Internet connections required to be? And how does that affect backup system or redundant connection requirements and testing?

What processes will be required to manage updates to the web site셲 content, and

what are the requirements for maintaining, tracking, and controlling page content, graphics, links, etc.?

Which HTML specification will be adhered to? How strictly? What variations will be allowed for targeted browsers?

Will there be any standards or requirements for page appearance and/or graphics throughout a site or parts of a site??

How will internal and external links be validated and updated? how often?
Can testing be done on the production system, or will a separate test system be required? How are browser caching, variations in browser option settings, dial-up connection variabilities, and real-world internet 쁳raffic congestion problems to be accounted for in testing?

How extensive or customized are the server logging and reporting requirements; are they considered an integral part of the system and do they require testing?

How are cgi programs, applets, javascripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?
Pages should be 3-5 screens max unless content is tightly focused on a single topic. If larger, provide internal links within the page.

The page layouts and design elements should be consistent throughout a site, so that it셲 clear to the user that they셱e still within a site.

Pages should be as browser-independent as possible, or pages should be provided or generated based on the browser-type.

All pages should have links external to the page; there should be no dead-end pages.
The page owner, revision date, and a link to a contact person or organization should be included on each page.

CHECKLIST

Let셲 have first web testing checklist.
1) Functionality Testing
2) Usability testing
3) Interface testing
4) Compatibility testing
5) Performance testing
6) Security testing

1) Functionality Testing:

Test for all the links in web pages, database connection, forms used in the web pages for submitting or getting information from user, Cookie testing.

Check all the links:

                     Test the outgoing links from all the pages from specific domain under test.

                     Test all internal links.

                     Test links jumping on the same pages.

                     Test links used to send the email to admin or other users from web pages.

                     Test to check if there are any orphan pages.

                     Lastly in link checking, check for broken links in all above-mentioned links.

Test forms in all pages:
Forms are the integral part of any web site. Forms are used to get information from users and to keep interaction with them. So what should be checked on these forms?

                     First check all the validations on each field.

                     Check for the default values of fields.

                     Wrong inputs to the fields in the forms.

                     Options to create forms if any, form delete, view or modify the forms.

Let셲 take example of the search engine project currently I am working on, In this project we have advertiser and affiliate signup steps. Each sign up step is different but dependent on other steps. So sign up flow should get executed correctly. There are different field validations like email Ids, User financial info validations. All these validations should get checked in manual or automated web testing.

Cookies testing:
Cookies are small files stored on user machine. These are basically used to maintain the session mainly login sessions. Test the application by enabling or disabling the cookies in your browser options. Test if the cookies are encrypted before writing to user machine. If you are testing the session cookies (i.e. cookies expire after the sessions ends) check for login sessions and user stats after session end. Check effect on application security by deleting the cookies. (I will soon write separate article on cookie testing)

Validate your HTML/CSS:
If you are optimizing your site for Search engines then HTML/CSS validation is very important. Mainly validate the site for HTML syntax errors. Check if site is crawlable to different search engines.

Database testing:
Data consistency is very important in web application. Check for data integrity and errors while you edit, delete, modify the forms or do any DB related functionality.
Check if all the database queries are executing correctly, data is retrieved correctly and also updated correctly. More on database testing could be load on DB, we will address this in web load or performance testing below.

2) Usability Testing:

Test for navigation:
Navigation means how the user surfs the web pages, different controls like buttons, boxes or how user using the links on the pages to surf different pages.
Usability testing includes:
Web site should be easy to use. Instructions should be provided clearly. Check if the provided instructions are correct means whether they satisfy purpose.
Main menu should be provided on each page. It should be consistent.

Content checking:
Content should be logical and easy to understand. Check for spelling errors. Use of dark colors annoys users and should not be used in site theme. You can follow some standards that are used for web page and content building. These are common accepted standards like as I mentioned above about annoying colors, fonts, frames etc.
Content should be meaningful. All the anchor text links should be working properly. Images should be placed properly with proper sizes.
These are some basic standards that should be followed in web development. Your task is to validate all for UI testing

Other user information for user help:
Like search option, sitemap, help files etc. Sitemap should be present with all the links in web sites with proper tree view of navigation. Check for all links on the sitemap.
쏶earch in the site option will help users to find content pages they are looking for easily and quickly. These are all optional items and if present should be validated.

3) Interface Testing:
The main interfaces are:
 Web Server and application server interface
Application server and Database server interface.

Check if all the interactions between these servers are executed properly. Errors are handled properly. If database or web server returns any error message for any query by application server then application server should catch and display these error messages appropriately to users. Check what happens if user interrupts any transaction in-between? Check what happens if connection to web server is reset in between?

4) Compatibility Testing:
Compatibility of your web site is very important testing aspect. See which compatibility test to be executed:

                     Browser compatibility

                     Operating system compatibility

                     Mobile browsing

                     Printing options

Browser compatibility:
In my web-testing career I have experienced this as most influencing part on web site testing.
Some applications are very dependent on browsers. Different browsers have different configurations and settings that your web page should be compatible with. Your web site coding should be cross browser platform compatible. If you are using java scripts or AJAX calls for UI functionality, performing security checks or validations then give more stress on browser compatibility testing of your web application.
Test web application on different browsers like Internet explorer, Firefox, Netscape navigator, AOL, Safari, Opera browsers with different versions.

OS compatibility:
Some functionality in your web application is may not be compatible with all operating systems. All new technologies used in web development like graphics designs, interface calls like different API셲 may not be available in all Operating Systems.
Test your web application on different operating systems like Windows, Unix, MAC, Linux, Solaris with different OS flavors.

Mobile browsing:
This is new technology age. So in future Mobile browsing will rock. Test your web pages on mobile browsers. Compatibility issues may be there on mobile.

Printing options:
If you are giving page-printing options then make sure fonts, page alignment, page graphics getting printed properly. Pages should be fit to paper size or as per the size mentioned in printing option.

5) Performance testing:
Web application should sustain to heavy load. Web performance testing should include:
Web Load Testing
Web Stress Testing

Test application performance on different internet connection speed.
In web load testing test if many users are accessing or requesting the same page. Can system sustain in peak load times? Site should handle many simultaneous user requests, large input data from users, Simultaneous connection to DB, heavy load on specific pages etc.

Stress testing: Generally stress means stretching the system beyond its specification limits. Web stress testing is performed to break the site by giving stress and checked how system reacts to stress and how system recovers from crashes.
Stress is generally given on input fields, login and sign up areas.

In web performance testing web site functionality on different operating systems, different hardware platforms is checked for software, hardware memory leakage errors,

6) Security Testing:

Following are some test cases for web security testing:

                     Test by pasting internal url directly into browser address bar without login. Internal pages should not open.

                     If you are logged in using username and password and browsing internal pages then try changing url options directly. I.e. If you are checking some publisher site statistics with publisher site ID= 123. Try directly changing the url site ID parameter to different site ID which is not related to logged in user. Access should denied for this user to view others stats.

                     Try some invalid inputs in input fields like login username, password, input text boxes. Check the system reaction on all invalid inputs.

                     Web directories or files should not be accessible directly unless given download option.

                     Test the CAPTCHA for automates scripts logins.

                     Test if SSL is used for security measures. If used proper message should get displayed when user switch from non-secure http:// pages to secure https:// pages and vice versa.

                     All transactions, error messages, security breach attempts should get logged in log files somewhere on web server.

Web Testing, Example Test cases

WEB TESTING
While testing a web application you need to consider following Cases:

Functionality Testing
Performance Testing
Usability Testing
Server Side Interface
Client Side Compatibility
Security

Functionality:
In testing the functionality of the web sites the following should be tested:
Links
i. Internal Links
ii. External Links
iii. Mail Links
iv. Broken Links

Forms
i. Field validation
ii. Error message for wrong input
iii. Optional and Mandatory fields

Database
* Testing will be done on the database integrity.

Cookies
* Testing will be done on the client system side, on the temporary Internet files.

Performance :
Performance testing can be applied to understand the web site셲 scalability, or to benchmark the performance in the environment of third party products such as servers and middleware for potential purchase.

Connection Speed:
Tested over various networks like Dial Up, ISDN etc
Load:
i. What is the no. of users per time?
ii. Check for peak loads and how system behaves
iii. Large amount of data accessed by user
Stress:
i. Continuous Load
ii. Performance of memory, CPU, file handling etc..

Usability:
Usability testing is the process by which the human-computer interaction characteristics of a system are measured, and weaknesses are identified for correction.
Ease of learning
Navigation
Subjective user satisfaction
General appearance

Server Side Interface:
In web testing the server side interface should be tested. This is done by verify that communication is done properly. Compatibility of server with software, hardware, network and database should be tested.

Client Side Compatibility:
The client side compatibility is also tested in various platforms, using various browsers etc.

Security:
The primary reason for testing the security of a web is to identify potential vulnerabilities and subsequently repair them.
Network Scanning
Vulnerability Scanning
Password Cracking
Log Review
Integrity Checkers
Virus Detection

 

What is client-server and web based testing and how to test these applications

Question:

What is the difference between client-server testing and web based testing and what are things that we need to test in such applications?

Ans:
Projects are broadly divided into two types of:

                     2 tier applications

                     3 tier applications

CLIENT / SERVER TESTING
This type of testing usually done for 2 tier applications (usually developed for LAN)
Here we will be having front-end and backend.

The application launched on front-end will be having forms and reports which will be monitoring and manipulating data

E.g: applications developed in VB, VC++, Core Java, C, C++, D2K, PowerBuilder etc.,
The backend for these applications would be MS Access, SQL Server, Oracle, Sybase, Mysql, Quadbase

The tests performed on these types of applications would be
- User interface testing
- Manual support testing
- Functionality testing
- Compatibility testing & configuration testing
- Intersystem testing

WEB TESTING
This is done for 3 tier applications (developed for Internet / intranet / xtranet)
Here we will be having Browser, web server and DB server.

The applications accessible in browser would be developed in HTML, DHTML, XML, JavaScript etc. (We can monitor through these applications)

Applications for the web server would be developed in Java, ASP, JSP, VBScript, JavaScript, Perl, Cold Fusion, PHP etc. (All the manipulations are done on the web server with the help of these programs developed)

The DBserver would be having oracle, sql server, sybase, mysql etc. (All data is stored in the database available on the DB server)

The tests performed on these types of applications would be
- User interface testing
- Functionality testing
- Security testing
- Browser compatibility testing
- Load / stress testing
- Interoperability testing/intersystem testing
- Storage and data volume testing

A web-application is a three-tier application.
This has a browser (monitors data) [monitoring is done using html, dhtml, xml, javascript]-> webserver (manipulates data) [manipulations are done using programming languages or scripts like adv java, asp, jsp, vbscript, javascript, perl, coldfusion, php] -> database server (stores data) [data storage and retrieval is done using databases like oracle, sql server, sybase, mysql].

The types of tests, which can be applied on this type of applications, are:
1. User interface testing for validation & user friendliness
2. Functionality testing to validate behaviors, i/p, error handling, o/p, manipulations, services levels, order of functionality, links, content of web page & backend coverage셲
3. Security testing
4. Browser compatibility
5. Load / stress testing
6. Interoperability testing
7. Storage & data volume testing

A client-server application is a two tier application.
This has forms & reporting at front-end (monitoring & manipulations are done) [using vb, vc++, core java, c, c++, d2k, power builder etc.,] -> database server at the backend [data storage & retrieval) [using ms access, sql server, oracle, sybase, mysql, quadbase etc.,]

The tests performed on these applications would be
1. User interface testing
2. Manual support testing
3. Functionality testing
4. Compatibility testing
5. Intersystem testing
Some more points to clear the difference between client server, web and desktop applications:

Desktop application:
1. Application runs in single memory (Front end and Back end in one place)
2. Single user only

Client/Server application:
1. Application runs in two or more machines
2. Application is a menu-driven
3. Connected mode (connection exists always until logout)
4. Limited number of users
5. Less number of network issues when compared to web app.

Web application:
1. Application runs in two or more machines
2. URL-driven
3. Disconnected mode (state less)
4. Unlimited number of users
5. Many issues like hardware compatibility, browser compatibility, version compatibility, security issues, performance issues etc.

As per difference in both the applications come where, how to access the resources. In client server once connection is made it will be in state on connected, whereas in case of web testing http protocol is stateless, then there comes logic of cookies, which is not in client server.

For client server application users are well known, whereas for web application any user can login and access the content, he/she will use it as per his intentions.

So, there are always issues of security and compatibility for web application.

Difference between Desktop, Client server and Web testing

Q.What is difference between client server and Web Testing?
Vijay: Well Srividya I would like to add one more testing type i.e Desktop Testing in this discussion. So now we have three testing types Desktop application testing, Client server application testing and Web application testing.

Each one differs in the environment in which they are tested and you will lose control over the environment in which application you are testing, while you move from desktop to web applications.

Desktop application runs on personal computers and work stations, so when you test the desktop application you are focusing on a specific environment. You will test complete application broadly in categories like GUI, functionality, Load, and backend i.e DB.

In client server application you have two different components to test. Application is loaded on server machine while the application exe on every client machine. You will test broadly in categories like, GUI on both sides, functionality, Load, client-server interaction, backend. This environment is mostly used in Intranet networks. You are aware of number of clients and servers and their locations in the test scenario.

Web application is a bit different and complex to test as tester don셳 have that much control over the application. Application is loaded on the server whose location may or may not be known and no exe is installed on the client machine, you have to test it on different web browsers. Web applications are supposed to be tested on different browsers and OS platforms so broadly Web application is tested mainly for browser compatibility and operating system compatibility, error handling, static pages, backend testing and load testing.

I think this will have an idea of all three testing environment. Keep in mind that even the difference exist in these three environments, the basic quality assurance and testing principles remains same and applies to all.

 

An approach for Security Testing of Web Applications

Introduction

As more and more vital data is stored in web applications and the number of transactions on the web increases, proper security testing of web applications is becoming very important. Security testing is the process that determines that confidential data stays confidential (i.e. it is not exposed to individuals/ entities for which it is not meant) and users can perform only those tasks that they are authorized to perform (e.g. a user should not be able to deny the functionality of the web site to other users, a user should not be able to change the functionality of the web application in an unintended way etc.).

Some key terms used in security testing

Before we go further, it will be useful to be aware of a few terms that are frequently used in web application security testing:

What is 쏺ulnerability?
This is a weakness in the web application. The cause of such a 쐗eakness can be bugs in the application, an injection (SQL/ script code) or the presence of viruses.

What is 쏹RL manipulation?
Some web applications communicate additional information between the client (browser) and the server in the URL. Changing some information in the URL may sometimes lead to unintended behavior by the server.

What is 쏶QL injection?
This is the process of inserting SQL statements through the web application user interface into some query that is then executed by the server.

What is 쏼SS (Cross Site Scripting)?
When a user inserts HTML/ client-side script in the user interface of a web application and this insertion is visible to other users, it is called XSS.

What is 쏶poofing?
The creation of hoax look-alike websites or emails is called spoofing.
Security testing approach:

In order to perform a useful security test of a web application, the security tester should have good knowledge of the HTTP protocol. It is important to have an understanding of how the client (browser) and the server communicate using HTTP. Additionally, the tester should at least know the basics of SQL injection and XSS. Hopefully, the number of security defects present in the web application will not be high. However, being able to accurately describe the security defects with all the required details to all concerned will definitely help.

1. Password cracking:

The security testing on a web application can be kicked off by 쐏assword cracking. In order to log in to the private areas of the application, one can either guess a username/ password or use some password cracker tool for the same. Lists of common usernames and passwords are available along with open source password crackers. If the web application does not enforce a complex password (e.g. with alphabets, number and special characters, with at least a required number of characters), it may not take very long to crack the username and password.

If username or password is stored in cookies without encrypting, attacker can use different methods to steal the cookies and then information stored in the cookies like username and password.

2. URL manipulation through HTTP GET methods:

The tester should check if the application passes important information in the querystring. This happens when the application uses the HTTP GET method to pass information between the client and the server. The information is passed in parameters in the querystring. The tester can modify a parameter value in the querystring to check if the server accepts it.

Via HTTP GET request user information is passed to server for authentication or fetching data. Attacker can manipulate every input variable passed from this GET request to server in order to get the required information or to corrupt the data. In such conditions any unusual behavior by application or web server is the doorway for the attacker to get into the application.

3. SQL Injection:

The next thing that should be checked is SQL injection. Entering a single quote () in any textbox should be rejected by the application. Instead, if the tester encounters a database error, it means that the user input is inserted in some query which is then executed by the application. In such a case, the application is vulnerable to SQL injection.

SQL injection attacks are very critical as attacker can get vital information from server database. To check SQL injection entry points into your web application, find out code from your code base where direct MySQL queries are executed on database by accepting some user inputs.

If user input data is crafted in SQL queries to query the database, attacker can inject SQL statements or part of SQL statements as user inputs to extract vital information from database. Even if attacker is successful to crash the application, from the SQL query error shown on browser, attacker can get the information they are looking for. Special characters from user inputs should be handled/escaped properly in such cases.

4. Cross Site Scripting (XSS):

The tester should additionally check the web application for XSS (Cross site scripting). Any HTML e.g. <HTML> or any script e.g. <SCRIPT> should not be accepted by the application. If it is, the application can be prone to an attack by Cross Site Scripting.

Attacker can use this method to execute malicious script or URL on victim셲 browser. Using cross-site scripting, attacker can use scripts like JavaScript to steal user cookies and information stored in the cookies.

Many web applications get some user information and pass this information in some variables from different pages.

E.g.: http://www.examplesite.com/index.php?userid=123&query=xyz

Attacker can easily pass some malicious input or <script> as a &query parameter which can explore important user/server data on browser.

Important: During security testing, the tester should be very careful not to modify any of the following:

                      Configuration of the application or the server

                      Services running on the server

                      Existing user or customer data hosted by the application

Additionally, a security test should be avoided on a production system.

The purpose of the security test is to discover the vulnerabilities of the web application so that the developers can then remove these vulnerabilities from the application and make the web application and data safe from unauthorized actions.

 

 

 

SQL Injection How to Test Web Applications against SQL Injection Attacks

Many applications use some type of a database. An application under test might have a user interface that accepts user input that is used to perform the following tasks:

1.    Show the relevant stored data to the user e.g. the application checks the credentials of the user using the log in information entered by the user and exposes only the relevant functionality and data to the user

2.    Save the data entered by the user to the database e.g. once the user fills up a form and submits it, the application proceeds to save the data to the database; this data is then made available to the user in the same session as well as in subsequent sessions

Some of the user inputs might be used in framing SQL statements that are then executed by the application on the database. It is possible for an application NOT to handle the inputs given by the user properly. If this is the case, a malicious user could provide unexpected inputs to the application that are then used to frame and execute SQL statements on the database. This is called SQL injection. The consequences of such an action could be alarming.

The following things might result from SQL injection:

1. The user could log in to the application as another user, even as an administrator.

2. The user could view private information belonging to other users e.g. details of other users profiles, their transaction details etc.

3. The user could change application configuration information and the data of the other users.

4. The user could modify the structure of the database; even delete tables in the application database.

5. The user could take control of the database server and execute commands on it at will.

Since the consequences of allowing the SQL injection technique could be severe, it follows that SQL injection should be tested during the security testing of an application. Now with an overview of the SQL injection technique, let us understand a few practical examples of SQL injection.

Important: The SQL injection problem should be tested only in the test environment.

If the application has a log in page, it is possible that the application uses a dynamic SQL such as statement below. This statement is expected to return at least a single row with the user details from the Users table as the result set when there is a row with the user name and password entered in the SQL statement.

SELECT * FROM Users WHERE User_Name = 섃 & strUserName & 쒋 AND Password = 섃 & strPassword & 쒋;

If the tester would enter John as the strUserName (in the textbox for user name) and Smith as strPassword (in the textbox for password), the above SQL statement would become:

SELECT * FROM Users WHERE User_Name = 쁉ohn AND Password = 쁓mith;

If the tester would enter John쇺 as strUserName and no strPassword, the SQL statement would become:

SELECT * FROM Users WHERE User_Name = 쁉ohn쇺 AND Password = 쁓mith;

Note that the part of the SQL statement after John is turned into a comment. If there were any user with the user name of John in the Users table, the application could allow the tester to log in as the user John. The tester could now view the private information of the user John.

What if the tester does not know the name of any existing user of the application? In such a case, the tester could try common user names like admin, administrator and sysadmin. If none of these users exist in the database, the tester could enter John or 쁷=셹 as strUserName and Smith or 쁷=셹  as strPassword. This would cause the SQL statement to become like the one below.

SELECT * FROM Users WHERE User_Name = 쁉ohn or 쁷='x AND Password = 쁓mith or 쁷=셹;

Since 쁷=셹 condition is always true, the result set would consist of all the rows in the Users table. The application could allow the tester to log in as the first user in the Users table.

Important: The tester should request the database administrator or the developer to copy the table in question before attempting the following SQL injection.

If the tester would enter John; DROP table users_details;쇺봞s strUserName and anything as strPassword, the SQL statement would become like the one below.

SELECT * FROM Users WHERE User_Name = 쁉ohn; DROP table users_details; 볛 AND Password = 쁓mith;

This statement could cause the table 쐕sers_details to be permanently deleted from the database.

Though the above examples deal with using the SQL injection technique only the log in page, the tester should test this technique on all the pages of the application that accept user input in textual format e.g. search pages, feedback pages etc.

SQL injection might be possible in applications that use SSL. Even a firewall might not be able to protect the application against the SQL injection technique.

I have tried to explain the SQL injection technique in a simple form. I would like to re-iterate that SQL injection should be tested only in a test environment and not in the development environment, production environment or any other environment. Instead of manually testing whether the application is vulnerable to SQL injection or not, one could use a web vulnerability scanner that checks for SQL injection.

 

Website Cookie Testing, Test cases for testing web application cookies?

We will first focus on what exactly cookies are and how they work. It would be easy for you to understand the test cases for testing cookies when you have clear understanding of how cookies work? How cookies stored on hard drive? And how can we edit cookie settings?

What is Cookie?
Cookie is small information stored in text file on user셲 hard drive by web server. This information is later used by web browser to retrieve information from that machine. Generally cookie contains personalized user data or information that is used to communicate between different web pages.

Why Cookies are used?
Cookies are nothing but the user셲 identity and used to track where the user navigated throughout the web site pages. The communication between web browser and web server is stateless.

For example if you are accessing domain http://www.example.com/1.html then web browser will simply query to example.com web server for the page 1.html. Next time if you type page as http://www.example.com/2.html then new request is send to example.com web server for sending 2.html page and web server don셳 know anything about to whom the previous page 1.html served.

What if you want the previous history of this user communication with the web server? You need to maintain the user state and interaction between web browser and web server somewhere. This is where cookie comes into picture. Cookies serve the purpose of maintaining the user interactions with web server.

How cookies work?
The HTTP protocol used to exchange information files on the web is used to maintain the cookies. There are two types of HTTP protocol. Stateless HTTP and Stateful HTTP protocol. Stateless HTTP protocol does not keep any record of previously accessed web page history. While Stateful HTTP protocol do keep some history of previous web browser and web server interactions and this protocol is used by cookies to maintain the user interactions.

Whenever user visits the site or page that is using cookie, small code inside that HTML page (Generally a call to some language script to write the cookie like cookies in JAVAScript, PHP, Perl) writes a text file on users machine called cookie.
Here is one example of the code that is used to write cookie and can be placed inside any HTML page:

Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME;

When user visits the same page or domain later time this cookie is read from disk and used to identify the second visit of the same user on that domain. Expiration time is set while writing the cookie. This time is decided by the application that is going to use the cookie.

Generally two types of cookies are written on user machine.

1) Session cookies: This cookie is active till the browser that invoked the cookie is open. When we close the browser this session cookie gets deleted. Some time session of say 20 minutes can be set to expire the cookie.
2) Persistent cookies: The cookies that are written permanently on user machine and lasts for months or years.

Where cookies are stored?
When any web page application writes cookie it get saved in a text file on user hard disk drive. The path where the cookies get stored depends on the browser. Different browsers store cookie in different paths. E.g. Internet explorer store cookies on path 쏞:\Documents and Settings\Default User\Cookies
Here the 쏡efault User can be replaced by the current user you logged in as. Like 쏛dministrator, or user name like 쏺ijay etc.
The cookie path can be easily found by navigating through the browser options. In Mozilla Firefox browser you can even see the cookies in browser options itself. Open the Mozila browser, click on Tools->Options->Privacy and then 쏶how cookies button.

How cookies are stored?
Lets take example of cookie written by rediff.com on Mozilla Firefox browser:
On Mozilla Firefox browser when you open the page rediff.com or login to your rediffmail account, a cookie will get written on your Hard disk. To view this cookie simply click on 쏶how cookies button mentioned on above path. Click on Rediff.com site under this cookie list. You can see different cookies written by rediff domain with different names.

Site: Rediff.com Cookie name: RMID
Name: RMID (Name of the cookie)
Content: 1d11c8ec44bf49e0 (Encrypted content)
Domain: .rediff.com
Path: / (Any path after the domain name)
Send For: Any type of connection
Expires: Thursday, December 31, 2020 11:59:59 PM

Applications where cookies can be used:

1) To implement shopping cart:
Cookies are used for maintaining online ordering system. Cookies remember what user wants to buy. What if user adds some products in their shopping cart and if due to some reason user don셳 want to buy those products this time and closes the browser window? When next time same user visits the purchase page he can see all the products he added in shopping cart in his last visit.

2) Personalized sites:
When user visits certain pages they are asked which pages they don셳 want to visit or display. User options are get stored in cookie and till the user is online, those pages are not shown to him.

3) User tracking:
To track number of unique visitors online at particular time.

4) Marketing:
Some companies use cookies to display advertisements on user machines. Cookies control these advertisements. When and which advertisement should be shown? What is the interest of the user? Which keywords he searches on the site? All these things can be maintained using cookies.

5) User sessions:
Cookies can track user sessions to particular domain using user ID and password.

Drawbacks of cookies:

1) Even writing Cookie is a great way to maintain user interaction, if user has set browser options to warn before writing any cookie or disabled the cookies completely then site containing cookie will be completely disabled and can not perform any operation resulting in loss of site traffic.

2) Too many Cookies:
If you are writing too many cookies on every page navigation and if user has turned on option to warn before writing cookie, this could turn away user from your site.

3) Security issues:
Some times users personal information is stored in cookies and if someone hack the cookie then hacker can get access to your personal information. Even corrupted cookies can be read by different domains and lead to security issues.

4) Sensitive information:
Some sites may write and store your sensitive information in cookies, which should not be allowed due to privacy concerns.

Some Major Test cases for web application cookie testing:

The first obvious test case is to test if your application is writing cookies properly on disk. You can use the Cookie Tester application also if you don셳 have any web application to test but you want to understand the cookie concept for testing.

Test cases: 

1) As a Cookie privacy policy make sure from your design documents that no personal or sensitive data is stored in the cookie.

2) If you have no option than saving sensitive data in cookie make sure data stored in cookie is stored in encrypted format.

3) Make sure that there is no overuse of cookies on your site under test. Overuse of cookies will annoy users if browser is prompting for cookies more often and this could result in loss of site traffic and eventually loss of business.

4) Disable the cookies from your browser settings: If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. Then try to access the web site under test. Navigate through the site. See if appropriate messages are displayed to user like 쏤or smooth functioning of this site make sure that cookies are enabled on your browser. There should not be any page crash due to disabling the cookies. (Please make sure that you close all browsers, delete all previously written cookies before performing this test)

5) Accepts/Reject some cookies: The best way to check web site functionality is, not to accept all cookies. If you are writing 10 cookies in your web application then randomly accept some cookies say accept 5 and reject 5 cookies. For executing this test case you can set browser options to prompt whenever cookie is being written to disk. On this prompt window you can either accept or reject cookie. Try to access major functionality of web site. See if pages are getting crashed or data is getting corrupted.

6) Delete cookie: Allow site to write the cookies and then close all browsers and manually delete all cookies for web site under test. Access the web pages and check the behavior of the pages.

7) Corrupt the cookies: Corrupting cookie is easy. You know where cookies are stored. Manually edit the cookie in notepad and change the parameters to some vague values. Like alter the cookie content, Name of the cookie or expiry date of the cookie and see the site functionality. In some cases corrupted cookies allow to read the data inside it for any other domain. This should not happen in case of your web site cookies. Note that the cookies written by one domain say rediff.com can셳 be accessed by other domain say yahoo.com unless and until the cookies are corrupted and someone trying to hack the cookie data.

8 ) Checking the deletion of cookies from your web application page: Some times cookie written by domain say rediff.com may be deleted by same domain but by different page under that domain. This is the general case if you are testing some 쁝ction tracking web portal. Action tracking or purchase tracking pixel is placed on the action web page and when any action or purchase occurs by user the cookie written on disk get deleted to avoid multiple action logging from same cookie. Check if reaching to your action or purchase page deletes the cookie properly and no more invalid actions or purchase get logged from same user.

9) Cookie Testing on Multiple browsers: This is the important case to check if your web application page is writing the cookies properly on different browsers as intended and site works properly using these cookies. You can test your web application on Major used browsers like Internet explorer (Various versions), Mozilla Firefox, Netscape, Opera etc.

10) If your web application is using cookies to maintain the logging state of any user then log in to your web application using some username and password. In many cases you can see the logged in user ID parameter directly in browser address bar. Change this parameter to different value say if previous user ID is 100 then make it 101 and press enter. The proper access message should be displayed to user and user should not be able to see other users account.

These are some Major test cases to be considered while testing website cookies. You can write multiple test cases from these test cases by performing various combinations. If you have some different application scenario, you can mention your test cases in comments below.

 

12 Best Cross Browser Testing Tools to Ease Your Browser Compatibility Testing Efforts

Cross Browser Testing can be the biggest pain for Software testers. But thanks to all cross browser testing tools available online which help to minimize testing efforts.

I셶e written this post mainly for software testers but designers can also refer crossbrowser testing methods and tools mentioned in this post.

Here셲 a handy cross browser testing checklist you can refer while testing your web project on different browsers and operating systems:

1) CSS validation
2) HTML or XHTML validation
3) Page validations with and without JavaScript enabled
4) Ajax and JQeury functionality
5) Font size validation
6) Page layout in different resolutions
7) All images and alignment
8 ) Header and footer sections
9) Page content alignment to center, LHS or RHS
10) Page styles
11) Date formats
12) Special characters with HTML character encoding
13) Page zoom-in and zoom-out functionality

And obviously you will have to repeat these tests on:
14) Different Operating Systems like Windows, Linux and Mac
15) Different browsers (with different versions) like Internet explorer, Firefox, Google Chrome, Safari and Opera.

There are many free and paid cross browser testing tools available in the market. You need to select the browser compatibility tool depending on your needs. If cross browser testing is critical part of your web project then you must allocate considerable time, resources and budget testing your website on different web browsers. Paid cross browser testing tools can be also a good option for projects having browser dependent functionality. But for most of the projects, free cross browser testing tools are sufficient to verify cross browser functionality

Check out below list of all cross browser testing tools available online for testing website in multiple browsers:

Free Cross Browser Testing Tools:


1) Spoon Browser Sandbox:
The Spoon Browser Sandbox allows you to use almost all web browsers without installing on your machine. You can run all popular browsers including Internet Explorer, Firefox, Chrome, and Opera on your machine directly from the web. (Note: Currently Internet Explorer is removed temporary from the list of this sandbox)

Spoon Browser Sandbox is a free service currently supporting following browsers:

Mozilla Firefox versions:
Firefox 2, Firefox 3, Firefox 3.5, Firefox 3.6, Firefox 4 beta

Internet Explorer versions:
IE6, IE7, IE8

Google Chrome versions:
Chrome, Chrome 5 and Chrome 6 beta

Opera versions:
Opera 9 and Opera 10

2) Browsershots
Browsershots allow you to test website in any browser and operating system. This is widely used cross browser testing tool because of its features and available customizations.

You can run cross browser compatibility tests with great customization options like browser type, operating system, screen size, color depth, JavaScript status and Flash enable/disable settings. Just put your website url, select compatibility test parameters and submit the test request.

You need to repeat the steps for every test. This free browser compatibility test service can be used for taking website screen-shots almost in 61 browsers and various operating systems.

Main drawback of this service is the time taken to display the result when you select many browsers and many times it shows timeout error.

Supported browsers:
IE, Firefox, Google Chrome, Opera, Safari, Minefield, Netscape and many more browsers with all versions.


 3) IE NetRenderer

This is a free online browser compatibility check tool to test website on almost all versions of Microsoft Internet Explorer. Just select the Internet Explorer version from drop down list and put your url to start rendering website. You can instantly verify the screen-shot of the page under test.

There is also a 쏧E NetRenderer Firefox add-on available that allows you to render the web page that you are currently reading.


4) IE Tab
A Firefox and Chrome add on to simulate IE browse with a single click of a button. This is a best tool for software testers and developers, since you can easily view how your web page displayed in Internet Explorer with just one click using Firefox or Chrome browsers. Unfortunately this add-on is not available for Firefox 6.0 and above versions. But again a good tool to quickly start your testing on Internet explorer when you have either Firefox or Google Chrome browsers.



5) IE Tester



There are many options available online if you want to check browser compatibility on Internet Explorer versions. IE tester is one of those options that allows you to test your website on multiple Internet Explorer versions at the same time using one application.

IETester, a free cross browser testing tool can be used to test website on IE 5.5, IE6, IE7, IE8 and IE9 preview browsers on Windows 7, Vista and XP operating systems.



6) Microsoft SuperPreview


Microsoft Expression Web SuperPreview free cross browser testing software allows you to test and debug layout issues across different IE browsers and platforms. You can check websites in different browsers simultaneously. Also check how a page renders in a browser and compare it with other standard screen-shots you have.

Expression Web SuperPreview for Internet Explorer shows your web pages rendered in Internet Explorer 6 and either Internet Explorer 7 or Internet Explorer 8, depending on which version you have installed on your machine.

If you can셳 rely on these free online cross browser testing tools then using Virtual Desktop is the best solution for you. Using Virtual machine you can simulate live environment for multiple browsers and different operating systems. You can use virtual machine software or can setup a virtual machine in your office network with different operating system images and browsers which can be accessed remotely for browser compatibility testing.

Paid Cross Browser Testing Tools:


7) Browsera

This is an automated browser compatibility testing tool used to test website and its elements in multiple browsers. You can use this service to test website and all web pages for layout and scripting errors.

8 ) Adobe BrowserLab

You can preview web pages across multiple versions of Internet Explorer (Windows), Firefox (Windows and Mac OS X), Safari (Mac OS X), and Chrome (Windows). You can quickly view full screen-shots with multiple view options and customizable test settings. You can also test web page content by zooming particular sections and comparing those with different browser screen-shots for alignment and other layout issues.

9) BrowserCam

BrowserCam is a paid online service that allows you to view your web pages across different platforms and browsers, either by automatically taking the screen-shot or manually navigating web pages in different browsers. Free trial is available for 200 screen captures in a day.

10) Browserseal

BrowserSeal cross browser testing tool allows you to capture an image of your website under different browsers with a single click of a mouse. You can navigate images to spot layout and UI issues. Browserseal tool support almost all major versions of Internet Explorer, Firefox, Google Chrome, Opera and Safari.

Free Trial version of Browserseal is also available, limited to two browsers (Firefox and Internet Explorer) and one screen-shot per session.

11) Cross Browser Testing

Test your website live on different operating systems and browsers. You just need to login to Cross Browser Testing platform, select operating system, browser and start testing your website for Ajax, JavaScript and flash functionality. You can also check your website design using automated screen-shot tool to view website셲 design across every browser. Free trial of this cross browser testing software is available for one week.

12) Cloud Testing

Cloud Testing tool allows you to check website look and feel and the functionality on Internet Explorer, Firefox, Safari. Opera and Google Chrome browsers on real operating systems in the cloud.

7 basic tips for testing multi-lingual web sites

These days a number of web sites are deployed in multiple languages. As companies perform more and more business in other countries, the number of such global multi-lingual web applications will continue to increase.

Testing web sites supporting multiple languages has its own fair share of challenges. In this article, I will share seven tips with you that will enable you to test the multi-lingual browser-based applications in a complete way:

Tip # 1 Prepare and use the required test environment

If a web site is hosted in English and Japanese languages, it is not enough to simply change the default browser language and perform identical tests in both the languages. Depending on its implementation, a web site may figure out the correct language for its interface from the browser language setting, the regional and language settings of the machine, a configuration in the web application or other factors. Therefore, in order to perform a realistic test, it is imperative that the web site be tested from two machines one with the English operating system and one with the Japanese operating system. You might want to keep the default settings on each machine since many users do not change the default settings on their machines.

Tip # 2 Acquire correct translations

A native speaker of the language, belonging to the same region as the users, is usually the best resource to provide translations that are accurate in both meaning as well as context. If such a person is not available to provide you the translations of the text, you might have to depend on automated web translations available on web sites like wordreference.com and dictionary.com. It is a good idea to compare automated translations from multiple sources before using them in the test.

Tip # 3 Get really comfortable with the application

Since you might not know the languages supported by the web site, it is always a good idea for you to be very conversant with the functionality of the web site. Execute the test cases in the English version of the site a number of times. This will help you find your way easily within the other language version. Otherwise, you might have to keep the English version of the site open in another browser in order to figure out how to proceed in the other language version (and this could slow you down).

Tip # 4 Start with testing the labels

You could start testing the other language version of the web site by first looking at all the labels. Labels are the more static items in the web site. English labels are usually short and translated labels tend to expand. It is important to spot any issues related to label truncation, overlay on/ under other controls, incorrect word wrapping etc. It is even more important to compare the labels with their translations in the other language.

Tip # 5 Move on to the other controls

Next, you could move on to checking the other controls for correct translations and any user interface issues. It is important that the web site provides correct error messages in the other language. The test should include generating all the error messages. Usually for any text that is not translated, three possibilities exist. The text will be missing or its English equivalent will be present or you will see junk characters in its place.

Tip # 6 Do test the data

Usually, multi-lingual web sites store the data in the UTF-8 Unicode encoding format. To check the character encoding for your website in mozilla: go to View -> Character Encoding and in IE go to View -> Encoding. Data in different languages can be easily represented in this format. Make sure to check the input data. It should be possible to enter data in the other language in the web site. The data displayed by the web site should be correct. The output data should be compared with its translation.

Tip # 7 Be aware of cultural issues

A challenge in testing multi-lingual web sites is that each language might be meant for users from a particular culture. Many things such as preferred (and not preferred) colors, text direction (this can be left to right, right to left or top to bottom), format of salutations and addresses, measures, currency etc. are different in different cultures. Not only should the other language version of the web site provide correct translations, other elements of the user interface e.g. text direction, currency symbol, date format etc. should also be correct.

As you might have gathered from the tips given above, using the correct test environment and acquiring correct translations is critical in performing a successful test of other language versions of a web site. 

Security Testing Techniques

Although it셲 a broad term, security testing can be broken down into six basic concepts:  Availability, Authentication, Authorization, Confidentiality, Integrity and Non-repudiation. I셪l define each concept briefly, however, I encourage you to research each concept for a better understanding.

                     Availability: Assuring that information & communications services are available and maintained for authorized persons when needed.

                     Authentication: Assuring the validity of any type of originator, transmission or message.  This also gives confidence that information is received by a known and validated source.

                     Authorization: Assuring that an individual can allow/deny access to a system/service/operation (e.g. Access control).

                     Confidentiality: Ensuring information is accessible only for those with authorized access and to prevent information disclosure to any party other than the intended recipients. Often ensured by encoding information using algorithms (cryptography).

                     Integrity: Ensuring received information is preserved successfully with no alteration.

                     Non-repudiation: Ensuring action/communication cannot later be denied (usually used by form of authentication and time stamping).

Security Testing Methods:

There are 3 types of testing methods which involve various sets of attacks: Information/system gathering, logical, and injection attacks. Each are used for specific testing results, however various attacks share the same security concepts, and are therefore quite similar to one another.

Information gathering (i.e. system-related) attacks

                     Client-side source code analysis

                     Application reconnaissance

                     Error messages analysis

                     Directory traversal

These methods include various types of information gathering from a web application/server by means of source code and error message analysis, exposure of directory structure or other attacks which results in information exposure. Here they are in no particular order:

Logical Attacks

                     Cookie poisoning

                     Parameter tampering

                     Flow bypassing

                     Direct access of components files

                     Session hijacking

                     Penetration testing

                     Buffer overflow

These methods relate to various logical attacks which may be executed both manually or via specific tools/scripts. Logical attacks are more sophisticated, and thus, more interesting & challenging to the tester, who needs to have a good understanding of information technology and specific knowledge of cookies, POST/GET requests & parameters, etc.

Injection Attacks

                     SQL injection

                     Cross Site Scripting (XSS)

                     Scripts injection

These methods relate to various scripts & SQL commands injections into web application forms. These are the most common attacks, yet they are both serious and dangerous. Detecting such vulnerabilities in the early stages of development can prevent unnecessary flaws.

In my next blog post, I will address some common (and some not-so-common) tools that can make security testing easier and more productive for testing engineers of all experience levels.

In the meantime, happy testing!


Free Web Application Security Testing Tool

Websites are getting more and more complex everyday and there are almostno static websites being built.


Today, the simplest website has at least a contact or newsletter form and many are built with CMS systems or it may be using 3rd party plugins, services, etc. that we don't have an exact control over.

Even if the website is 100% hand-coded, we trust what we created and think that it is safe, it is still possible that a special character is not sanitized or we are not aware of a new attacking technique.

So, it is really hard to say "my website is safe" without running tests over it. The good part is there are powerful and free web application security testing tools which can help you to identify any possible holes.

Before presenting them, let's remind the classic: "something can be secure as only as its weakest link" (which also tells us that it is not always the application and can still be the server it is hosted or that easy to remember FTP password).

Netsparker Community Edition (Windows)

This is the free-community edition of the powerful Netsparker which still comes with a bunch of features and also false-positive-free.

The application can detect SQL Injection + cross-site scripting issues.

Once a scan is complete, it displays the solutions besides the issues and enables you to see the browser view and HTTP request/response.

Websecurify (Windows, Linux, Mac OS X)

Websecurify is a very easy-to-use and open source tool which automatically identifies web application vulnerabilities by using advanced discovery and fuzzing technologies.

It can create simple reports (that can be exported into multiple formats) once ran.

The tool is also multilingual and extensible with the add-on support.

Wapiti (Windows, Linux, Mac OS X)

Wapiti is an open source and web-based tool that scans the web pages of the deployed web applications, looking for scripts and forms where it can inject data.

It is built with Python and can detect:

                     File handling errors (Local and remote include/require, fopen, readfile)

                     Database, XSS, LDAP and CRLF injections (HTTP response splitting, session fixation)

                     Command execution detection (eval(), system(), passtru())

N-Stalker Free Version (Windows)

The free edition performs restricted-yet-still-powerful set of web security assessment checks compared to the paid versions of the application.

It can check up to 100 web pages at once including web server and cross-site scripting checks.

skipfish (Windows, Linux, Mac OS X)

skipfish is a fully automated and active web application security reconnaissance tool.

It is lightweight and pretty fast (can perform 2000 requests/second).

The application has automatic learning capabilities, on-the-fly wordlist creation and form autocompletion.

skipfish comes with low false positive, differential security checks which are capable of spotting a range of subtle flaws, including blind injection vectors.

Scrawlr (Windows)

Scrawlr is a free software for scanning SQL injection vulnerabilities on your web applications.

It is developed by HP Web Security Research Group in coordination with Microsoft Security Response Center.

Watcher (Windows)

It is a plugin for Fiddler (the awesome HTTP debugging proxy) and works as a passive-analysis tool for HTTP-based web applications.

Watcher runs silently in the background and interact with the web-application to apply 30+ tests (where new ones can be added) while you browse.

It will identify issues like cross-domain form POSTs, dangerous context-switching between HTTP and HTTPS, etc.

x5s (Windows)

x5s is again a plugin for Fiddler just like Watcher which is designed to find encoding and character transformation issues that can lead to XSS vulnerability.

It simply tests user-controlled input using special characters like <, >, ', and reviews how the output encodes the special characters.

Exploit-Me (Windows, Linux, Mac OS X)

Rather than using a proxy like most of the security testing tools, Exploit-Me directly integrates into Firefox.

It is a set of 3 add-ons:

                     XSS-Me: for testing reflected XSS vulnerabilities

                     SQL Inject Mefor testing SQL injection vulnerabilities

                     Access Me: for testing access vulnerabilities

They are all lightweight , work while you browse websites and simply inform you by adding extra styles to the objects with vulnerabilities

WebScarab (Windows, Linux, Mac OS X)

WebScarab is actually a proxy to sniff the HTTP(s) traffic and manipulate it.

However, it comes with features like "parameter fuzzer (for testing XSS and SQL injection vulnerabilities), or "CRLF injection (HTTP response splitting)" and more.

Acunetix Free Version (Windows)

This is the free and limited-featured version of a paid/pro product.

It performs a check on any website and identifies cross site scripting (XSS) vulnerabilities.

And, if you are looking to improve yourself in the area of web application security and need to play with an application legally, there is DVWA (damn vulnerable web app.) which is there for just this purpose.

Share