The U.S. Department of Energy
Computer Incident Advisory Capability

Internet Cookies

March 12, 1998 23:00 GMT
Number I-034

PROBLEM:     Cookies are short pieces of data used by web servers to help
             identify web users. The popular concepts and rumors about what a
             cookie can do has reached almost mystical proportions,
             frightening users and worrying their managers.
PLATFORM:    Any platform that can use a modern web browser.
DAMAGE:      No damage to files or systems. Cookies are only used to identify
             a web user though they may be used to track a user's browsing
SOLUTION:    No files are destroyed or compromised by cookies, but if
             you are concerned about being identified or about having your web
             browsing traced through the use of a cookie, set your browser to
             not accept cookies or use one of the new cookie blocking
             packages. Note that blocking all cookies prevents some online
             services from working. Also, preventing your browser from
             accepting cookies does not make you an anonymous user, it just
             makes it more difficult to track your usage.
VULNERABILITY  The vulnerability of systems to damage or snooping by using
ASSESSMENT:    web browser cookies is essentially nonexistent. Cookies can
               only tell a web server if you have been there before and can
               pass short bits of information (such as a user number) from the
               web server back to itself the next time you visit. Most cookies
               last only until you quit your browser and then are destroyed.
               A second type of cookie known as a persistent cookie has an
               expiration date and is stored on your disk until that date.
               A persistent cookie can be used to track a user's browsing
               habits by identifying him whenever he returns to a site.
               Information about where you come from and what web pages you
               visit already exists in a web server's log files and could also
               be used to track users browsing habits, cookies just make
               it easier.

                              Internet Cookies

The popular rumors about web cookies describe them as programs that can scan
your hard drive and gather information about you including: passwords, credit
card numbers, and a list of the software on your computer. None of this is
close to the truth. A cookie is a short piece of data, not code, which is sent
from a web server to a web browser when that browser visits the server's site.
The cookie is stored on the user's machine, but it is not an executable
program and cannot do anything to your machine.

Whenever a web browser requests a file from the web server that sent it a
cookie, the browser sends a copy of that cookie back to the server along with
the request. Thus a server sends you a cookie and you send it back whenever
you request another file from the same server. In this way, the server knows
you have visited before and can coordinate your access to different pages on
its web site. For example, an Internet shopping site uses a cookie to keep
track of which shopping basket belongs to you. A server cannot find out your
name or e-mail address, or anything about your computer using cookies.

Normally, cookies are only sent back to the server that originally sent them
to the browser and to no one else. A server can set the domain attribute for a
cookie so that any server in the same Internet subdomain as the computer that
sent the cookie will have the cookie sent along with a file request. This is
so those larger sites that utilize multiple servers can coordinate their
cookies across all the servers. The domain path can not be set to send cookies
to a subdomain outside of the subdomain where the server resides.

A cookie is sent to a browser by including a line with the following syntax in
the header of an HTML document. Note that the header is removed from the
document before the browser displays it. Thus, you will not see the header
lines if you execute the View, Source or View, Document Source commands in
your browser.

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

Here the upper case names are strings the server can set.

NAME=VALUE is the name of the cookie and its VALUE. This is the data that the
web server wants passed back to it when a browser requests another page.

DATE is an attribute that determines how long the cookie persists on your
system. If there is no expiration date, the cookie is stored in memory only
and expires at the end of the current session (that is, when you quit the web
browser). If the DATE attribute is in the future, the cookie is a persistent
cookie and is saved in a file. Only persistent cookies can be used to track a
user at more than one site. Setting the date for an existing cookie to be some
day in the past deletes the cookie.

DOMAIN_NAME is an attribute that contains the address of the server that sent
the cookie and that will receive a copy of this cookie when the browser
requests a file from that server. It defaults to the server that set the
cookie if it is not explicitly set in the Set-Cookie: line. DOMAIN_NAME may be
set to equal the subdomain that contains the server so that multiple servers
in the same subdomain will receive the cookie from the browser. This allows
larger web sites to coordinate multiple servers in the same subdomain. For
example, if the DOMAIN_NAME equals then machines named,, and would
all receive the cookie from the browser. The value of DOMAIN_NAME is limited
such that only hosts within the indicated subdomain may set a cookie for that
subdomain and the subdomain name is required to contain at least two or three
dots in it. Two dots are required if the top level domain is: .COM, .EDU,
.NET, .ORG, .GOV, .MIL, or .INT. Three dots are required for any other domain.
This is to prevent the subdomain from being set to something like .COM, the
subdomain of all commercial machines.

PATH is an attribute that is used to further refine when a cookie is sent back
to a server. When the PATH attribute is set, a cookie is only sent back to the
server if both the DOMAIN_NAME and the PATH match for the requested file.

secure is an attribute that specifies that the cookie is only sent if a secure
channel (https) is being used.

What Information Can A Server Get From A Browser

When a browser sends a request to a server, it includes its IP address, the
type of browser you are using, and the operating system of your computer. This
information is usually logged in the server's log file. A cookie sent along
with the request can add only that information, which is contained in the
cookie and which, was originally sent to the browser by the same server. Thus,
there is no additional personal information explicitly sent to the server by
allowing cookies.

Cookies and shopping Sites

As mentioned above, cookies are used by Internet shopping sites to keep track
of you and your shopping cart. When you first visit an Internet shopping site,
you are sent a cookie containing the name (ID number) of a shopping cart. Each
time you select an item to purchase, that item is added to the shopping cart.
When you are done with your shopping, the checkout page lists all the items in
the shopping cart tied to that cookie. Without cookies, you would have to keep
track of all the items you want to buy and type them into the checkout page or
buy each item, one at a time.

Another method is for the shopping site to send a separate cookie containing
the item number to your browser whenever you select an item to purchase. Your
browser sends all those cookies along with the request for the checkout page.
The checkout page uses the cookies to make a list of the items you want to

Cookies and Custom Home Pages

Another use of cookies is to create customized home pages. A cookie is sent to
your browser for each of the items you expect to see on your custom home page.
Whenever you request your custom home page your cookies are sent along with
the request to tell the server which items to display. Without cookies, a
server would require you to identify yourself each time you visit the custom
page so it knows what items to display. The server would also have to store
the custom page settings for every visitor.

Cookies and Buying Habits

One of the less admirable uses of cookies, and the one that is causing all the
controversy, is its use as a device for tracking the browsing and buying
habits of individual web users. On a single web site or a group of web sites
within a single subdomain, cookies can be used to see what web pages you visit
and how often you visit them. This information is also in the server's log
files and so the use of a cookie here does not increase a server's ability to
track you, it just makes it easier.

On multiple client sites being serviced by a single marketing site, cookies
can be used to track your browsing habits on all the client sites. The way
this works is a marketing firm contracts with multiple client sites to display
its advertising. The client sites simply put an <IMG> tag on their web pages
to display the image containing the marketing firm's advertisement. The tag
does not point to an image file on the client's machine but contains the URL
of the marketing firm's advertisement server and includes the URL of the
client's page. Thus when you open a page on the client's site the
advertisement you see was actually obtained from the advertising firm's site.

The advertising firm sends a cookie along with the advertisement, and that
cookie is sent back to the advertising firm the next time you view any page
containing one if its advertisements. If many web sites support the same
advertising firm, that firm will be able to track your browsing habits from
page to page within all the client sites. They will not be able to see what
you do with the pages you view; they will only know which pages you are
viewing, how often you view them, and the IP address of your computer. This
information can be used to infer the things you are interested in and to
target advertising to you based on those inferences.

NOTE: A URL is a Uniform Resource Locator, which is a string containing the
type of resource, IP address of the server machine containing the resource,
and the path to the resource on the server. When you access a web page, the
URL is what you type in the address field of the web browser. For example: is a URL for the CIACHome.html
document, which is an http document, on the server in the /ciac

Examining Persistent Cookies Already On Your System

Persistent cookies are stored in different places on your system depending on
which web browser and browser version you are using. Netscape stores all its
persistent cookies in a single file named cookies.txt on the PC or magiccookie
on the Macintosh. Both files are in the Netscape directory. You can open and
edit this file with a text editor and delete any cookies that you don't want
to keep or delete the file itself to get rid of all of your cookies.

Internet Explorer stores persistent cookies in separate files named with the
user's name and the domain name of the site that sent the cookie. For example:
yourname@ciac.txt. The cookie files are stored in /Windows/cookies or in
/Windows/profiles/<username>/cookies directories, where <username> is replaced
with the user's login name. If your operating system directory is not named
Windows (such as Winnt for Windows NT) then look in that directory instead of
the Windows directory. You can delete any of these files you do not want to

You can open these files to see where they came from and what information they
contain. For example, the following are the contents of an Internet Explorer
cookie file.


This particular cookie file was named orvis@java.txt. The file name is made up
of the username (orvis) and the last part of the domain (java). The text
"Counter_Cookie" is the name of the cookie and 7 is its value. The URL is the
domain attribute and the numbers contain the date and other cookie attributes.
This particular cookie implements a page counter that lists how many times you
have visited a particular page. Whenever you visit that page, this cookie is
sent along with the page request. The server then knows that this is the
eighth (7 + 1) time you visited the page and inserts that number into the web
page. It then increments the value of the cookie from 7 to 8 and sends it back
to the browser along with the requested page. The new cookie replaces the old
one so the next time you visit the number 8 is sent to the server. See the
example in the "Cookies, VBScript, JavaScript, and Java" section below to see
this page in action.

Preventing Any Cookies from being Placed On Your System

You can prevent any cookies from being sent to your system using the browser
options. In Internet Explorer 4.0, choose the View, Internet Options command,
click the Advanced tab and click the Disable All Cookie Use option. In
Netscape 4.0, choose the Edit, Options command, click on Advanced and click
the Disable Cookies option. After that, no cookies will be stored on your
system. You will need to turn cookies back on if you want to use any online
services that require them. You can also choose the option to prompt you
before accepting a cookie, but at many sites you will be continually closing
the warning dialog box.

If you are using earlier versions of Netscape or Internet Explorer, you can
require that the browser warn you before accepting a cookie, but it cannot
block all cookies. At a busy shopping site, acknowledging all the warnings can
get really tedious. There are some other methods for fooling your browser into
not accepting a cookie discussed in the cookie web pages listed at the end of
this bulletin.

Cookie Blocking Software

Several companies are offering special software packages that work with your
web browser to control who can send you a cookie. In these packages, you
designate which sites can send you a cookie and which can not, alleviating the
need to turn cookie use on and off by hand. If you want to use cookies in some
instances and not in others, one of these packages may make things easier.

Several packages are listed at the following sites:

Cookies, VBScript, JavaScript, and Java

Programs written in VBScript, JavaScript, and Java that are attached to a web
page can read and store cookies on your system. The limitations on these
cookies are the same as cookies sent to your browser by the server that sent
you the program. Cookies created by these programs can only pass information
from one page to the next.

The following site demonstrates a page counter using JavaScript.

More Cookie Information

The following web sites are just a few of the sites that specialize in cookie

Yahoo:  search for "cookie".

Netscape's cookie specification:

Netscape's cookie security FAQ

Cookie Central:


CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.

CIAC services are available to DOE, DOE contractors, and the NIH. CIAC
can be contacted at:
    Voice:    +1 510-422-8193
    FAX:      +1 510-423-8002
    STU-III:  +1 510-423-2604

For emergencies and off-hour assistance, DOE, DOE contractor sites,
and the NIH may contact CIAC 24-hours a day. During off hours (5PM -
8AM PST), call the CIAC voice number 510-422-8193 and leave a message,
or call 800-759-7243 (800-SKY-PAGE) to send a Sky Page. CIAC has two
Sky Page PIN numbers, the primary PIN number, 8550070, is for the CIAC
duty person, and the secondary PIN number, 8550074 is for the CIAC
Project Leader.

Previous CIAC notices, anti-virus software, and other information are
available from the CIAC Computer Security Archive.

   World Wide Web:
                        (or -- they're the same machine)
   Anonymous FTP:
                        (or -- they're the same machine)
   Modem access:        +1 (510) 423-4753 (28.8K baud)
                        +1 (510) 423-3331 (28.8K baud)

CIAC has several self-subscribing mailing lists for electronic
1. CIAC-BULLETIN for Advisories, highest priority - time critical
   information and Bulletins, important computer security information;
2. SPI-ANNOUNCE for official news about Security Profile Inspector
   (SPI) software updates, new features, distribution and
3. SPI-NOTES, for discussion of problems and solutions regarding the
   use of SPI products.

Our mailing lists are managed by a public domain software package
called Majordomo, which ignores E-mail header subject lines. To
subscribe (add yourself) to one of our mailing lists, send the
following request as the E-mail message body, substituting
ciac-bulletin, spi-announce OR spi-notes for list-name:

E-mail to or
        subscribe list-name
  e.g., subscribe ciac-bulletin

You will receive an acknowledgment email immediately with a confirmation
that you will need to mail back to the addresses above, as per the
instructions in the email.  This is a partial protection to make sure
you are really the one who asked to be signed up for the list in question.

If you include the word 'help' in the body of an email to the above address,
it will also send back an information file on how to subscribe/unsubscribe,
get past issues of CIAC bulletins via email, etc.

PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing
communities receive CIAC bulletins.  If you are not part of these
communities, please contact your agency's response team to report
incidents. Your agency's team will coordinate with CIAC. The Forum of
Incident Response and Security Teams (FIRST) is a world-wide
organization. A list of FIRST member organizations and their
constituencies can be obtained via WWW at

This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.

LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC)

I-024: CGI Security Hole in EWS1.1 Vulnerability
I-025A: Windows NT based Web Servers File Access Vulnerability
I-026: Vulnerability in ssh-agent
I-027B: HP-UX Vulnerabilities (CUE, CDE, land)
I-028: Vulnerabilities in CDE
I-029: IBM AIX Telnet Denial-of-Service Vulnerability
I-030: SunOS volrmmount (1) Vulnerability
I-031A: WindowsNT-95 Attacks on DOE Sites
I-032: Sun Solaris Vulnerabilities (vacation, dtaction)
I-033: Sun Solaris Vulnerabilities (ndd, rpc.cmsd)