[Javascript] Can I Give Myself a Cookie ?

David T. Lovering dlovering at gazos.com
Tue Apr 22 10:06:59 CDT 2003


Well.  I hardly know how to respond.

With regards to session cookies, I think Brad and I are sufficiently close
to agreement that there is little point in dissension.  Warm and fuzzy,
that's me.

However, with regard to persistent cookies -- boy is he wrong!

First, off detecting cookies is no biggie.  A cookie is stored on a file
in what is (for the most part) a standard directory.  Any generic "list
directory" command pointed at such a directory will spout gazillions of
cookies.  For example, one default cookie directory in WindowsXP which is
often used for both persistant and session cookies is

C:\Documents and Settings\<MyUserName>\Cookies

Mind you, every application and/or URL that uses cookies may opt to put them
in a different place, so in point of actual fact they are scattered all over
your machine.  Go ahead -- look in your primary cookie directory -- if you
are running on a standard Windows late-model OS you'll typically have several
hundred of these babies floating around at any given time.

The structure of a cookie is defined quite nicely in the McGraw-Hill book
named (appropriately) "Cookies".  First published in 1998, it runs about $11.00
new.

The "standard" way of using a cookie is to reference the URL you are calling from,
and ask nicely for the cookies associated with it.  If you want to see if the
web page you are on has any cookies associated with it, just type the following
into the location bar:

javascript:alert(document.cookie.replace(/;/g, "\n"))

If you want a more automatic way of doing things, something like the following
script will work:

<script language="JavaScript">
<!--
  function cookieMonster() {
    var cookies = document.cookie.split(";");
    var HTML = "";
    for (var i=0; i<cookies.length; i++) {
      HTML += cookies[i] + "<br>\n";
    }
    document.write(HTML);
  }
// -->
<script>

Of course, one can have secure, non-secure, site-specific, and site-open cookies
also.  Javascript has a number of other useful cookie commands which should be
examined.

However (!!!) a cracker doesn't bother with these niceties.  He simply sucks up
the raw cookies (not using the warm and fuzzy document.cookie directives), and
parses them.  The average cookie is built something along these lines:

<cookie designator>#<client-ip-address>-nnnnnnnnn.nnnnnnnnn::<cipher-key>#<server-ip/URL>#<encoded pair 1>#
<encoded pair 2># ... #<encoded pair N>#*#

Although my copy of "Cookies" is on loan to somebody, I seem to recall that the nnnnnnnnn.nnnnnnnnn jazz is
the expiration date.  It's been a while since I poked a cookie, so my memory is probably a bit fuzzy.  Also,
there are some slight variations on what the cipher-key block contains, so expect some switch/case structures.

However, as the vast majority of cookies use the same or similar rotating-bit XOR encoding scheme, a number of
generic exploits are posted for taking apart 128B keys on-the-fly.  Knowing how many cookie pairs there are,
the number of octets in each, and the cipher-key (as well as the client/server info which are often used in
generating the hash which builds the encryption key itself) are all grist to the hacker's mill.

I won't provide you with the code to break the encryption -- unfortunately that is all too easy to come by nowadays, and I have no particular desire to sojourn in Leavenworth.  Suffice to say, if you're the sort of ganiff that wants to find this stuff,
you'll find it -- homeland security nazis or no.  [insecure.org, freshmeat.net, www.hoobie.net, and plenty of newer sites are all good places to start your personal path to perdition].

Each pair is of the form "name=value", so after you and your favorite black-arts code have finished having your
way with the decryption process you might arrive at something like the following:

AMEX#
<preamble>:
cardholder=John%20Smith
cardnumber=1234%209876%205678%200987
expdate=0405
#*#

I've been told that some exploits can spoof the client-ip-address and the server blocks, thereby making it much
more straight-forward to extract the cookie pairs.  You'll still have to use the designated decryption scheme, but
hey! every little bit helps.

Anyway, please feel free to review the literature on cookies at the exploit sites, and I suspect you'll understand
why I'm a little leery about betting my livelihood on the absolute unbreakability of my resident cookies.

-- Dave Lovering


"T. Bradley Dean" wrote:
> 
> David T. Lovering wrote:
> >A web site that you visit could just as well
> >scan ALL your cookies for lightly encoded objects,
> 
> Web sites only have access to cookies they write. A web site would not be
> able to "scan ALL your cookies".
> 
> Used properly and responsibly (for example, to store a user id number which
> correlates to information about a user stored server site) cookies are a
> safe and convenient way to store user data.
> 
> ~Brad
> 
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript


More information about the Javascript mailing list