Go to main post
Definition of Cookie
A cookie is a piece of text that a Web server can store on a user's hard disk. Cookies allow a Web site to store information on a user's machine and later retrieve it. The pieces of information are stored as name-value pairs. [Source]
Thanks to Internet cookies, you can specify your personal preferences of features that a web site may offer, such as to display the current weather conditions of the city you live in or to automatically enter your user name and password if one is required for that particular web site. Then, each time you visit that web site in the future, it automatically recalls your preferences. These types of cookies are called first-party cookies.
There are also session cookies, which are temporary cookies that exist only while you are currently visiting a web site. Once you leave that web site, the cookie is removed.
When a web site remembers your preferences, it does so by saving that information on the web site's computer, and then assigns that information a unique identification tag. The web site places only the identification tag information on your computer, using a very small text file with a unique name. The next time you visit that web site, it checks to see if you have this text file on your computer, and if so, what identification tag it contains.[Source]
The exact location of cookies on the computer depends on your web browser. For example:
IE (Internet Explorer 7) Cookies Location
1. Open IE7, go to Tools(Menu)-> Internet Options.
2. In the General tab, in the Browsing history section, click the Settings button.
3. The “Temporary Internet Files and History Settings” dialog appears.
4. Click the View Files button. Explorer will open, showing you the IE7 cookies and temporary files.
Windows XP Cookies Location
C:\Documents and Settings\[username]\Cookies\
Uses of Cookies
Cookies are 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.
Cookies are also used 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 can also be used to track user actions across the site or domain. [Source]
Google uses cookies to improve your online experience, including the display of more relevant ads. See here questions like - How does Google use cookies to serve ads? Etc.
Does Yahoo! use cookies?
Cookie Testing
Disabling Cookies
What happens to the Web site if all cookies are disabled? Start by closing all instances of your browser and deleting all cookies from your PC set by the site under test. The cookie file is kept open by the browser while it’s running, so you must close the browser to delete the cookies. Closing the browser also removes any per-session cookies in memory.
Disable all cookies and attempt to use the site’s major features and functions. Most of the time, you will find that these sites won’t work when cookies are disabled. This isn’t a bug, but rather a fact of life: disabling cookies on a site that requires cookies (of course!) disables the site’s functionality. Can the user perform any operations on the site? Is it obvious to the Web site user that he must have cookies enabled to use the site? Is the Web server recognizing that its attempts to set cookies are failing? If so, does it send a page to the user stating, in plain language, that cookies must be enabled for the site to work? Or can the user frustratingly attempt the same operation many times in a row without a clue as to why the site isn’t working?
Selectively Rejecting Cookies
What happens to the site if some cookies are accepted and others are rejected? Start by deleting all cookies from your PC set by the site under test and set your browser’s cookie option to prompt you whenever a Web site attempts to set a cookie. Exercise the site’s major functions. You will be prompted for each and every cookie the site attempts to set. Accept some and reject others. (Analyze site cookie usage in advance and draw up a test plan detailing what cookies to reject/accept for each function.) How does the site hold up under this selective cookie rejection? As above, does the Web server detect that certain cookies are being rejected and respond with an appropriate message? Or does the site malfunction, crash, corrupt data, or misbehave in other ways?
Corrupting Cookies
Now’s our chance to really abuse the site under test! Exercise the site’s major features. Along the way, as cookies are created and modified, try things like
Altering the data in the persistent cookies. Since the per-session cookies are stored only in memory, they aren’t readily accessible for editing.
Selectively deleting cookies. Allow the cookie to be written (or modified), perform several more actions on the site, then delete that cookie. Continue using the site. What happens? Is it easy to recover? Any data loss or corrupted?
Cookie Encryption
The last cookie test I’ll mention is a simple one. While investigating cookie usage on the site you’re testing, pay particular attention to the meaning of the cookie data. Sensitive information like usernames and passwords should NOT be stored in plain text for all the world to read; this data should be encrypted before it is sent to your computer
For examples to above four points see Source
Black Box testing for Cookies
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.
You can 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 that you can compare them and the track changes.
You can Analyze the Gathered Cookies: 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?
See if you can determine or guess what data (Sensitive data storage) is being stored in this cookie. Sometimes the labels help, but sometimes you can make educated guesses from hints of format, content, etc.
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 nonsensitive information, it may have a longer expiration date.
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 place where they should be. These tested cookies become the first to manipulate and explore for vulnerabilities, as described in the next step.
Now you need to start experimenting with the cookies to see if you can find vulnerabilities. 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.
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 for Cookies
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 carry out the somewhat tedious task of reverse engineering the cookie itself. [Source]
More on Cookies
Cookie Test
Wikipedia - HTTP_cookie
Below link contains information like Stateless, Stateful Systems, The Stateless HTTP, To State or Not To State on the Web, Maintaining State with Cookies, Per-Session Cookies and Cookie Expiration, Cookie Detective Work, Cookie Usage by Amazon.com, What’s Inside a Cookie?, Amazon.com Cookie Analysis, Cookie Testing
Testwareinc
Below link contains information like Introduction to How Internet Cookies Work, Cookie Basics, How does cookie data move?, How do Web sites use cookies?, Problems with Cookies, Cookies on the Internet: Privacy Issues
How Stuff Works
Below link contains information like What is a Cookie?, How Cookies work., Are Cookies dangerous?, What information does a Cookie collect from you?, What information can a Cookie get from my computer?, Can a Cookie give my computer a virus?, Can a Cookie delete my hard drive?, Can I refuse to accept a Cookie?, What happens if I refuse to accept a Cookie?, Who can see my Cookies?, Can anything bad happen from Cookies?
Perlservices
SolutionBase: Understanding how cookies work
How do tracking Cookies work?
How internet cookies work?
Test cookie poisoning
HTTP_Cookies
How to use cookies part 1
How to use cookies part 2
How to use cookies part 3
Also See:
SQL Injection
Cross Site Scripting