Risk associated with cookies
Cookies are simple text files that are stored in a user’s machine by a web server. This text file contains information in a name-value pair, which can be retrieved by a website. This unique value is used to distinguish between multiple users who are accessing the system. A cookie can only be retrieved by the website who issued that cookie. Some cookies also contain particular ids for its session and a value for time.
Necessity of cookies
- A cookie can be used to store the current state information of a website in the user’s computer. This data can be retrieved by the website to know about the state of website. By looking at the ID field of the cookie, a website can infer that the user has already visited.
- A website counts its hit by looking into the unique id that has been given to each user. Thus, by using cookies, a website can uniquely identify the number of visitors. Cookies can also be used to categorize the repeated visitors and can count the number of times a particular user visits the website.
- Cookies can store preferences and settings and this data can be used to remember user preferences and hence provide unique customization for particular users. In the case of e-commerce sites, the unique ID can be used to set up the shopping cart for a user. A user can add items to a shopping cart and this preference is linked to the site’s database along with the unique id. Later, when the same user visits the site, this unique id from cookie can be used to retrieve the shopping preference of that particular user.
- Cookies are also used by websites to track the time a particular user spends on the website and to find the links the user clicks on that particular website. In addition, cookies can also be used to remember the preferences and color settings that are unique to users.
How cookies work?
The above diagram illustrates how a cookie works. Figure 1 represents browsing a website without a cookie. When a web server receives a request for a URL from browser, it looks for the cookies. If cookies are not available, it then creates a cookie with a unique id for the user and embeds the header of the website in the cookie and passes it to the user. The cookie will then be stored on the user’s hard disk. The user preferences and settings are stored in the website database with a link to the value of id in the cookie. Then, whenever the user browses the same site, the cookie is also forwarded with the URL and the web server, using the unique id in the cookie, pulls the customized preferences from the database and passes it to the user.
How cookies are initialized in browsers
The browser gets cookie from server in the following manner:
When we type a URL, the browser sends a request to the website for the page. On doing this, the browser also looks for a cookie in the user’s computer. If the browser finds a cookie for that particular website, it will send that name-value pair to that web server associated with the URL. The server receives the name-value pair and the request for the page and uses the cookie data to produce the unique user experience by providing particular preferences and color schemes.
Likewise, if the user’s machine doesn’t have a cookie for a particular machine, the browser will send the URL alone to the web server. When the web server receives the URL without a cookie being attached, it knows that the user has not visited the website earlier. Now the web server creates a new cookie for the user with a unique ID that is link to the website’s database. This cookie will have the webpage’s header attached and will be sent to the user’s machine. Now the cookie will be stored in the user’s machine and further visits to the website may result in changes to the name-value pair in the cookie.
Furthermore, the cookies may also contain the validity and path information. Path information can be associated with different parts of the site and validity information refers to the expiration value of the cookie.
Types of cookies
There are different types of cookies, such as transient cookies, persistent cookies, and permanent cookies.
This type of cookie is stored in the computer’s memory, i.e. RAM, and contains a session ID that stores information on the user’s browsing session. These cookies are also known as session cookies and are deleted from the computer as soon as the browser is shut down.
The session id in a session cookie acts as the user id that allows navigating from one page to another without logging in repeatedly. Session cookies don’t collect any information from the user’s computer and are stored in primary memory of the computer. They are never written on the hard disk and they expire at the end of the user’s browser session. These session cookies will become inaccessible if the session becomes inactive for a specific period of time.
These types of cookies are stored on the computer’s hard drive and contain information on user preferences for a website. These preferences can be used for further browsing sessions and are retained as long as the user allows them. Unlike transient cookies, these cookies are permanently stored and are not deleted when a browser is shutdown.
Persistent cookies can be used to analyze the user’s browsing habits on a particular website and can also determine the most visited links on that website. This in turn can be used to enhance the features or contents of the website. This type of cookie is used to count the number of unique visitors to a particular website.
These cookies are small Flash files such as video clips or gifs stored on a user’s computer by websites. They contain the same data as normal cookies and they function in the same way. Unlike other cookies, Flash cookies cannot be deleted by any mechanism from the browser level. They can only be deleted manually or by using some special add-ons. So, if a Flash cookie is retained on a computer’s hard disk, it will be used as a backup for the normal cookie and hence can be used to recall the preferences of a particular user to a website.
Risk associated with cookies
Common risks of cookies are:
Cross-site request forgery attack (XSRF)
A browser sends a cookie in response to a request, regardless of where the request came from. This is where the actual problem with cookies comes in. When a website receives a request, it cannot distinguish whether the action is initiated by the user or not. It looks for the cookie and, if the cookie is available, it deliberately performs the action as if the user initiated it. This can be explained by using an example.
Consider that a user “John” browses through a legitimate website “www.example.com” and has a valid cookie on his hard disk. Meanwhile, an attacker, “Crusoe,” embeds a link to perform some delete action of “www.example.com” in an image and posts it on a site known as “www.exploit.com.” When the user John visits “www.exploit.com,” the webpage loads the image and in turns gives a delete request to “www.example.com.” When the web server receives the request, it looks for the cookie. It then finds John’s cookie, interprets this as a valid request, and performs the delete action.
Session fixation attacks are based on application level. In this type of attacks, an attacker impels the user to use the attacker’s or another’s session ID. This can be done by using the cookie’s browser directive path, hence the user pretends to be someone else. Using this method, an attacker can urge the user to log in as the attacker on various application levels.
In order to carry out a cross-site scripting exploit, an attacker has to place the exploit in a cookie. Then the exploit vector will fetch the payload from the cookie and the exploitation is carried out. This type of attack will become difficult if the cookie has already been set; in this case, the attacker has to control the first cookie in the cookie string and only then can the attack be carried out.
Cookie tossing attack
Cookie tossing is one of the major types of attack on cookies and can be explained as follows. Consider a user visits “www.example.com” and receives the domain cookie. The next time the user browses the same site, the cookie is sent to the web server. Now the problem is that the cookie doesn’t contain any path or domain name. So if an attacker crafts a subdomain cookie and sends it along with a legitimate cookie, the web server accepts both cookies. There is no rule in the browser to send the domain cookie first and hence it may choose the subdomain cookie and send it first. And if the malicious subdomain cookie is the first one received by the web server, it will take it as a valid one, and that cookie value will provide the session for the user. The web server cannot validate which is the legitimate cookie, because the cookie attributes, such as domain path secure and HttpOnly attributes, are not sent to it.
Cookie overflow attack
In this type of attack, a parent domain cookie can be replaced by subdomain cookie by using a Jscript in the subdomain. Browsers have a limit on the number of cookies to set and browsers like Chrome don’t verify whether the stored cookies are from a domain or a subdomain. It simply stores the cookies that are given to it. The replaced subdomain cookies will not be of HttpOnly or secure type. Now, after storing the subdomain cookie, an attacker can change the expiry date of the cookie and the entire cookie will be useless. Now the attacker can craft a new malicious cookie and forward it to the web server. And there is no method; a web server can detect whether the cookie is in the secure or HttpOnly category. Thus an attack can be carried out by fabricated cookies.
Finding Cookies in IE
Tools>Internet Options>Settings>Temporary Internet files and History settings>View files
A persistent cookie is stored on the hard disk of the user’s computer, so it can be viewed and edited by using default text editors or word processors. Cookies can also be viewed from the DOS command line or by using Notepad, but the cookie is very likely to become corrupted if not saved in DOS text format. It is difficult to decipher the contents of a cookie and it is safer not to edit the cookie.
Also, a cookie can be deleted without any problem. Almost all web browsers provide options to delete the cookies and it can also be done manually by navigating to the cookie folder. When cookies are deleted, the user preferences and session information are deleted and the user appears as new to the web server.
Websites like YouTube use persistent cookies and these cookies are passed to the user’s computer as soon as they visit the YouTube website. Whether the user plays the video or not, YouTube writes a cookie to the user’s hard disk to track the user’s interest and, in turn, to provide the related results to the user.
Criticism from privacy activists forced YouTube to change the privacy rules and the site now boasts that they are not tracking visitors who are not playing videos. But now a newly implemented cookie-lite feature in YouTube continues to set long-lasting Flash cookies on the user’s hard disk even when a user does not click play to watch a video. And, in the case of Flash cookies, it is possible that they will remain on the user’s computer indefinitely, as there is no expiration date. Cookies were accompanied with a lot of misconceptions and delusions from their debut on the Internet and those still exist. Cookies were known as tracking tools only for the purpose of advertising. They were also thought to be used for spamming purpose and for junk emails and pop-ups. An interesting misconception was that cookies acts like malware and even that they can delete data from computers.
In fact, cookies do produce some issues. They can be altered by malicious users since it is stored on the local machine. Cookies can also be used to steal sessions of another user and hence can commit fraudulent acts. They can also be used for tracking the surfing history of a user. This data can be sold to advertising agencies, which in turn results in junk emails and advertisements. However, tallying advantages and disadvantages, cookies stand as one of great inventions on the Internet side.
Now let’s see how we can hijack a session with the help of cookies. Below is a website that is vulnerable to cookie hijacking. A valid user logs in using Chrome:
Spencer741 got logged in.
Now sniff the network packets using Wireshark and filter by the http.cookie field:
Look for a GET request and search for the cookies.
Right click Cookie>Copy>Bytes>Printable text only:
Now that we have the cookie, let’s inject it into another browser and see whether we can continue to use the logged in-profile. Here I have used the Greasemonkey plug-in that comes with Firefox (I believe other plug-ins like cookiemanager and firebug can also be used). Once you installed the Greasemonkey plug-in you should search for a cookie injector script for installation over Greasemonkey. Now you are ready to go. Open Firefox and press Alt+C to inject the copied cookie value.
Refresh the browser and you will see Spencer741 logged in:
- Use the https method of authentication wherever possible.
- Even if the cookies are stolen, developers should come up with codes that check the source address and referrer of the authenticated user periodically. If there is a mismatch, the session need to be closed suddenly.
- The expiry time of the cookie that is allocated from the web server needs to be shortened.