|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Home | Computers & Technology | Security HTTP is the protocol used to exchange files on the World Wide Web. Generally the browser sends a request to the web server using HTTP before displaying a particular page. The web server gets the request and checks the existence of that particular page. If the requested page available inside the web server, the web server allows the browser to display that page. Once the browser receives last byte of the page using HTTP the server essentially forgot about the whole process. If at all the user wants to see another page (from the same website) the whole process will again continue. The protocol used for exchanging files on the Web is stateless, but maintaining state is essential for most Web sites. To maintain state, one option that Web developers have is to use cookies. What is a cookie?? A cookie is a small amount of data stored either in a text file on the client's file system or in-memory in the client browser session. It contains page-specific information the server sends to the client along with page output. Cookies can be temporary (with specific expiration times and dates) or persistent. Cookies are used to store information about a particular client, session, or application. The cookies are saved on the client device, and when the browser requests a page, it sends the information in the cookie along with the request information. The server can read the cookie and extract its value. A typical use is to store a token indicating that the user has already been authenticated in your application. The browser can only send the data back to the server that originally created the cookie. Therefore, cookies are a relatively secure way of maintaining user-specific data. Types of Cookies: Session: Session cookies reside in the browser’s memory and "live" as long as that instance of browser remains open. Each open browser instance will have its own session cookie for a Web site. If developers don’t explicitly set the expires parameter, it defaults to end-of-session. The length of a session can vary depending on browsers and Web servers, but it’s generally the length of time that the browser is open (even if the user is no longer at that particular Web site). Persistent (By Page Name): Persistent cookies continue to "live" after the browser (and operating system) has been closed. Persistent (By Domain Name): Persistent cookies with or without an expiration date can reside on a client’s hard drive for a long period of time. Before we go to testing we should understand the content of the cookie. Let’s take an example: .mindfiresolutions.com TRUE / FALSE 994320128 session-id 102-7224116-8052958 <1> .mindfiresolutions.com is the domain for which this cookie is valid. Only cookies set by machines in the mindfiresolutions.com domain can read this cookie. <2> FALSE (1st occurrence) is a flag indicating whether or not the cookie can be accessed by all machines in the domain. <3> / is the path the cookie is valid for. <4> FALSE (2nd occurrence) is a secure flag indicating whether or not a secure (encrypted) connection is needed to access the cookie. <5> 994320128 is the UNIX expiration time of the cookie. UNIX time is the number of seconds since January 1, 1970 00:00:00 GMT. <6> session-id is the name of the variable stored by this cookie. <7> 102-7224116-8052958 is the value of this cookie. Cookie Testing: 1. Disabling Cookie: Delete all the cookies from the pc. Open the browser disables the cookie option in the browser. Now try to use some of the major functionality of any site. Most of the time it will not work but in very rare cases the site will work but very slowly. But this is not a bug rather a fact. But the web server should recognize that the cookie is disabled in the browser and it should give a message to the user to enable the cookies to use all the functionality. 2. Selectively Rejecting Cookies: Delete all the cookies from the pc set by the site. Set the browser cookie option to prompt whenever a website attempts to set a cookie. Then try to open the site. When ever the website tries to set a cookie it will ask the user. So test the web site by accepting some of the cookies and by rejecting some of them. Let’s say there are total no of 5 cookies needs to be set to load the page. So we will have 2^5=32 test cases. 3. Corrupting Cookies: First allow all the cookies and then delete all the cookies midway through a transaction. We can also corrupt the cookies by altering the data in the persistent cookies. Since the per-session cookies are stored only in memory, they aren’t readily accessible for editing. For example we can change the session id or cookie value. When control characters or special operating system commands are added to a cookie, the site detects the situation and handles it gracefully. 4. Cookie Encryption: While testing we should pay particular attention to the meaning of the cookie data. Sensitive information like usernames and passwords should NOT be stored in plain text for the entire world to read; this data should be encrypted before it is sent to your computer. Finale: In recent years, Web application security has become a focal center for security experts. Application attacks are constantly on the rise, posing new risks for the organization. As a software tester we must have some good knowledge about HTTP, HTTPS, cookies etc…so that we can prevent our applications from the hackers. Tapas Kumar Sahoo. www.mindfiresolutions.com Article Source: http://www.articlewheel.com
|
 RSS Feeds by Category |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
