Cookie Tampering

Today, I found a very nice article on cookie Tampering, like to share with you all.

Cookies are technically small pieces of text that are sent to the Web client browser by a server and intended to be sent back to the server, unchanged, each time it accesses the same server or another server in the same domain. Cookies are used for authentication, tracking, maintaining state over stateless HTTP, as well as maintaining specific information about the user such as their site preferences, etc. The minimum size of a cookie is a name-value pair.

Cookies were originally developed for use in Web applications that used online or virtual shopping baskets. Cookies allowed for the contents of the basket to be changed, based on the user's actions and tracked items in the basket between browser sessions.

Cookies are also used when users log in to a Web site. Users enter their username and password into a login page and, if they are authenticated, a cookie is saved that allows the Web site to know the users are already logged in as they navigate around the site. This permits them access to any functionality that may be available only to logged-in users, probably the primary use of cookies at this time.

Another use of cookies is to save user preferences for a site so that the site presentation and functionality can be personalized, based on the preferences of the user.

Cookies are used to track user actions across the site or domain. There are also some third-party cookies that allow for tracking across multiple sites. Most tracking done within a site or domain is done to gather usage data for that site. Tracking over multiple sites is done by advertising companies to build user profiles to allow for more targeted marketing.

Cookies are destroyed at the point the user closes the browser unless a deletion date has been set. If a deletion date has been set, the cookie will be destroyed on that date instead. The cookies that have deletion dates are called persistent cookies.

Cookies are supposed to be sent only to the server that set them or another server in the same Internet domain. However, a Web page in one domain may contain images or components that are referenced on a page in the original domain but which are stored on a server in another domain. When these components are retrieved, cookies can be set for the second domain. These are called third-party cookies.

There are some privacy and security concerns around the use (and misuse) of cookies and that has caused some legislation to be enacted in the United States and the European Union. It is also important to know that the only real restriction on cookies is a maximum of 300 at a time, which is respected by most browser manufacturers. The site can create one cookie or a lot of cookies - the number is truly up to the site in question and its needs.

Cookie Risks

Cookie Theft

Cookies are supposed to be sent only between the Web browser and the server or servers in the same domain that set the cookie. But, if the cookie is being sent over an ordinary HTTP connection, it is visible to anyone across the network using a packet sniffer. This means cookies really cannot contain sensitive information. This is sometimes overcome by using HTTPS to encrypt the connection, but that's not the solution because it only solves one of the problems associated with having sensitive data stored in cookies.

For example, cross-site scripting can be used to send cookies to servers that should not be receiving that data. Encryption does not help stop this cookie theft, which is often done with a simple snippet of HTML posted to a site that users can be tricked into clicking on, and which sends their cookie for that site to a location that the attacker specifies. Because the request is coming from the same domain intended for the cookie, there are no problems. These cookies can then be exploited by connecting to the same site using the stolen cookies, thus spoofing the original owner of the cookie.

Cookie Poisoning

Cookies are supposed to be sent back to the server unchanged, but attackers can modify the value of a cookie before sending them back to the server. This is typically done to carry out some sort of attack against the server that relates to some sort of data contained in the cookie. For example, if a cookie contains the price per item for something in the shopping basket, a change to this value in the cookie may cause the server to charge the user a lower price for that item. This process of modifying a cookie before it is sent back to the server is called cookie poisoning. Sometimes, cookie poisoning is used after cookie theft.

Most Web sites only store a randomly generated unique session identifier in the cookie, and everything else is stored on the server. This pretty much eliminates the threat of cookie poisoning.

Cookie Inaccuracies

Even outside of deliberate cookie tampering, there are aspects to how cookies are used in some situations that cause cookies to carry inaccurate data on which to base sensitive transactions.

One issue is that separate people using the same computer, browser, and user account will unavoidably share cookies. Another is that if a single user uses multiple browsers, multiple computers, or multiple user accounts, it means that the user will have multiple sets of cookies.

Cross-Site Cooking

Despite the fact that each site is supposed to have its own set of cookies and to not be able to alter or set cookies for any other site, there are some browser flaws that cause cross-site cooking vulnerabilities and allow malicious sites to break this rule.

This is similar to cookie poisoning, but instead of the attacker attacking the site itself, the attacker is now attacking non-malicious users with vulnerable browsers.

Many browsers have a flaw in how they deal with overly relaxed cookie domains. They are supposed to require a two-dot specification for all domains under the following top-level domains:

• .com
• .edu
• .net
• .org
• .gov
• .mil
• .int

This is supposed to prevent the setting of a cookie for a subdomain like .com. So, the actual intent is that if you wish to set a cookie on a .com site, you need to specify ".mysite.com" as the two-dot name. This breaks when you get to the international naming system for some domains like .com.au or .com.de. In some browsers, it's possible for a cookie to be set for the entire.com.au (for example) domain.

Another problem is how some browsers deal with periods. There is typically no check to see whether there is anything between the periods or if there is a trailing period being used to override the local domain search path. This means that a cookie can be set for ".com.," which then sends the user to https://www.mywebsite.com./

This address is not the "real" one, but how many users will care about the training period? Probably not very many. Even some seasoned users may not be adequately suspicious.

The third issue is that attackers can force cookies on random visitors, which are then relayed to a third-party site by setting IN A record and then redirecting users to the third-party site.

Anatomy of an Exploit

Cookie Theft

The attacker posts an auction that includes a link to what is advertised to be additional pictures or information about the object in the auction. Instead, when users click on the link, their cookie for the auction Web site is sent to the attacker's server, where a CGI script logs the information. Now the attacker can look through the list of cookies and pick some of the most recent cookies to use to try to log in to the auction site and spoof the user.

Cookie Poisoning

The attacker visits an E-commerce site and adds an expensive item to his shopping cart. Then, the user examines the cookie stored on his system from that site to see whether the cookie includes the total cost of the items in the attacker's cart.

The attacker then modifies the cookie on his system to change the total to be $5.00 and resolves the cookie. Then, the user returns to the E-commerce site and checks his cart to see that the total is now $5.00 and proceeds to order the items for the false price.

Cross-Site Cooking

The attacker crafts a cookie for the domain ".com.uk" and sets up a Web site to distribute the cookie. Then, the attacker posts a link to his Web site on various bulletin boards or via e-mail, and when the users click on the link, they are given the attacker's crafted cookie that can then overwrite or disrupt the real business they do with Web sites in that international domain.

Real-World Examples

Cookie Theft

A cookie theft vulnerability was reported in January 2005 in the Froogle (Google, Inc., Mountain View, California) comparison shopping service. Although the details reported are sketchy, it appears that malicious Java-Script in URL points to Froogle. Once a user clicks that link, the JavaScript executes a redirect to a malicious Web site, which then steals the user's Google (Google, Inc., Mountain View, California) cookie. This stolen cookie apparently contained the username and password for the "Google Accounts" centralized log in service, information that is used by multiple Google services.

Cross-Site Cooking

At the moment, cross-site cooking is a proof of concept that demonstrates the vulnerability and hasn't emerged in the wild.

Test Techniques

Black-Box Testing

The first thing you need to do is know just what cookies are being created by the application and when. But all cookies are not kept as created. Some are modified by the application as it runs, and you need to know when and how the cookies are modified.

As a black-box tester, you really need to explore the application, track what cookies are being set where, and exactly what they contain. Then, delete or modify the cookie, and see where the system is looking for the data from the cookies. You need to see where the application modifies the cookies.

I generally start with a spreadsheet and have the page name on the left, a column for the date and time obtained, and then the contents of the cookies on the right, so I can compare them and the track changes. You should make multiple passes through the product with different user identities to give you a good amount of data to examine, and always include as many user states as you can (logged in, not logged in, a variety of user permission levels, etc.).

Analyze the Gathered Cookies

Once you have some data gathered, you need to examine the cookies you have gathered to try to get an idea of what they are supposed to tell the server or store. I typically start making notes on my spreadsheet if I think I see patterns or can make educated guesses at the cookie's contents or intent. In essence, you are trying to reverse-engineer the cookies. The major items to look for are:

• Predictability: By looking at several samples of the cookies, can you detect a pattern in the format or makeup of the cookies? There can be obviously predictable formats that are made clear by the use of delimiters or labels. There can also be hints in the name of the cookie itself. What changes in the cookies were issued from different sessions? For different users? What causes the cookie to be modified?
• Sensitive data storage: See if you can determine or guess what data is being stored in this cookie. Sometimes the labels help, but sometimes you can make educated guesses from hints of format, content, etc.
• Secure flag: Is the secure flag set? This would indicate the cookie is only supposed to be sent over a secure connection and may indicate the cookie contains sensitive data.
• Expiration data: If a cookie holds session information, it should either have a very short expiration date or no expiration, so that it will be deleted when the browser session is closed. If the cookie is meant to contain non-sensitive information, it may have a longer expiration date.

Compare to Documentation

Just because you are doing black-box testing does not mean that you cannot seek out any documentation on what the individual cookies are supposed to do and contain.

If there is any documentation available, compare that to your spreadsheet of notes and guesses and see if any issues are immediately obvious. Disparities can emerge between documentation and reality, and there may be cases where security measures (secure flag and expiration date) are not in a place where they should be. These tested cookies become the first to manipulate and explore for vulnerabilities, as described in the next step.

Modify Cookies

Now you need to start experimenting with the cookies to see if you can find vulnerabilities. If you have documentation to use, you can start with the ones you marked as most interesting. Otherwise, you can start wherever you think the most risk is.

Start by modifying one field of one cookie at a time. If you have found a pattern to the cookie, test both inside and outside the pattern.

Naturally, cookies with one or more pieces of data in clear text are the easiest to modify, but to experiment with other cookies and cookie fields, too.

Don't stay within the field size the real cookie is using. It may be possible to create an overflow, and that should be explored as well.

Don't stay within the apparent data type of the cookie's field. The server should be checking all incoming data and validating type before use.

Write down the results of each attempt and listen to your intuition when it comes to potential vulnerabilities.

Cookie Misuse

Don't forget to try other cookie uses that go beyond cookie tampering. Try testing as if you had stolen someone else's valid cookie.

White-Box Testing

White-box testing of cookie vulnerabilities uses the same basic theories, but because you have direct insight into the code that saves and reuses the cookies, you don't have to carry out the somewhat tedious task of reverse-engineering the cookie itself.

For more information: https://www.infosectoday.com/Articles/Cookie_Tampering.htm