[Javascript] Can I Give Myself a Cookie ?

[David T. Lovering]

Chris Tifer has made some excellent points, of which I'll follow up
briefly.

Yes, the primary peril of cookies is felt if someone gains access to your
machine and can snoop files -- including cookies.

Yes, the code snippets I provided are intended to show the cookies for
the current site.  However, just going to a site and running the script
(without actually filling out any forms, etc.) may be enlightening to
someone who didn't realize they had any cookies from that source.

However, there are perfectly good JavaScript methods for listing a
directory's contents (including those that contain cookies), and using
an iframe with a src="<path/cookiefilename>" can work quite nicely as
a raw cookie viewer, irrespective of which site the client is actually
attached to.  Simply spinning this back to the server of an illicit
site will provide a snapshot of the cookie's contents, providing the
instigator learns how to hide his Javascript/Active-X widget from the
hapless victim, and presuming he has the ready means to decrypt the
stuff he snatches.

Active-X is not the only scripting language which will do this sort of
thing.  Most tricks that I've seen active-X do can be done with either
JavaScript (yay!), Java (yay!), or PHP, and sometimes with raw VB/VBE.
Admittedly, Java gives very little purchase on a client's machine because
of the stringent limitations on what kind of resources the JVM can
access.  Sometimes the code is tortuous and illogical, and involves mirroring
back through the server, but crackers are remarkably inventive beasties.

In particular, I agree with Chris' comment about the appropriate use of
cookies.  As long as you don't stash your credit-card info, your bank
account info, etc. in a cookie, you have relatively little to fear.  If
you restrict yourself to only permitting session cookies to exist on
your machine, you'll have even less to fear.  And let's remember -- cookies
are extremely useful for storing form history during a long session with
many form refresh cycles.  (Providing you don't exceed their 4K length
limits).  And for the REALLY paranoid, flushing your cookies at the end of
every day gives you even more security (and heightened annoyance when you
can't remember all the passwords, etc. that were stored in them).

-- Dave Lovering

Again, my thanks to Chris for his enlightened comments.  

Chris Tifer wrote:
> 
> > 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.
> 
> So really, you're more worried about someone getting access to your
> computer, not somebody using an exploit to expose cookies through
> the browser, because unless you allow someone to install an Active-X
> object, I don't see how cookies will be reported to any outside domains.
> 
> > 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"))
> 
> But you know why this works, right? Because it's accessing the CURRENT
> domain's
> cookies, not any outside of the domain.
> 
> > 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>
> 
> I'm willing to bet that you won't be able to list the cookies from anyone's
> domain except yours.
> 
> > 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>#*#
> 
> While storing Cookies is of course more convenient to a hacker, if someone's
> good
> enough to get into your machine, I doubt they're only good enough to look in
> one
> directory - your cookie directory. They'd likely have the ability to check
> ANYTHING
> out on your computer and scan it for numbers that match CC # patterns.
> 
> You're right. It's not good to store sensitive data in cookies, but it's
> fairly
> safe to store some sort of identifying value so the site can look you up
> easily enough
> and using that info, the site's ownders can search for your information in
> their DB.
> 
> In short, I would never store CC info in a cookie.
> 
> Chris Tifer
> 
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript