Re: Cookies

[Ryan Permeh <Ryan () EEYE COM>]

cookies are standardized, but the content of them is not.

some rules of thumb for web designers using cookies:
1. try to make them cryptographically secure via strong hashes. This stops
most offensive cookie based session hijack attempts.  Often cookies don't
really contain much actual information, but serve as session tags for a
backend on a web server (ie: your name, home address, and email address are
not actually within a cookie).  Even if you choose to push actual data to
the client via cookies, you can crypt it at send and decrypt it at receive.
This puts trust in your key values and your algorithms, so be careful.
Remember that there are tons of ways for an attacker to read your scripts,
if you aren't careful.  This precludes housing the key data directly in the
script or within the web root.

2. consider "remembering" bad cookie attacks aand blocking ips that exceed a
threshhold value of say 10 an hr.  This may not be feasible on a heavily
used web server due to the load that it can incur, but technologies like
mod_perl and other cgi program cacheing systems can help.

3. Always remember that cookie data, like all data, is taintable.  use the
same common sense in parse operations against cookie data as you would
against any type of inputed data.  (You ARE checking your form input for
taint/poison aren't you?)

4. depending on your application, you might be able to just avoid cookies.
Depending on the situation, there are more sane ways of doing most things
that cookies can do(Url rewritting, hidden form variables, etc).  I have yet
to see a browser that allows you to turn off either of those
technologies.(PS, those could both be vulnerable to session hijacking
without proper precaution, so be careful with those as well).


Just a couple ideas for the people who implement cookies out there.  Cookies
are not a bad technology, and can serve a useful purpose in web
design/Implementation if they are used smartly.
(or you could be like me and decide that static HTML is a viable solution =)


Signed,
Ryan
eEye Digital Security Team
http://www.eEye.com
----- Original Message -----
From: "netsec [davidv]" <netsec () GFI COM>
To: <VULN-DEV () SECURITYFOCUS COM>
Sent: Tuesday, August 08, 2000 1:12 AM
Subject: Re: Cookies


Recently at a local ISP while invetigating how he uses cookies i was really
shocked when is aw that by just changing the a variable integer stored in a
cookie you will immediatly be someone else for the webserver.  Now if the
ISP
has a web management for the particular user then there will be big
problems.

However (pls. correct me if im wrong) the cookie format fields is not an
actual
standard by the webserver as regards to the data stored, most probably it is
the
programmer who programmes the format of the cookie in his own way.  So we
cannot
have a common template of a cookie which you can say this is exploitable,
this is
not!

It all boils down to the way a specific programmer decides to program.

Please correct me if im wrong.

David Vella

> -----Original Message-----
> From: Denis Ducamp [mailto:Denis.Ducamp () HSC FR]
> Sent: Sunday, August 06, 2000 11:30 PM
> To: VULN-DEV () SECURITYFOCUS COM
> Subject: Re: Cookies
>
>
> On Sun, Aug 06, 2000 at 10:20:58AM -0400, George wrote:
> > A few friends of mine were discussing the possibility of a
> custom crafted
> > cookie replacing a valid cookie on a client machine being
> used to exploit
> > the web server that placed the first cookie on the client.
> >
> > Has anyone looked at the possibility of editing a cookie to search
> > for/exploit buffer overflows in the server side code that
> reads cookies? If
>
> In the web server itself : no
>
> In an http application : no with a buffer overflow but yes to access
> application privileges.
>  The more often, the cookie is used to remember the login
> with which you
>   authenticated. Change that cookie and you are someone else :-( !
>  Other times, that cookie is used to remember which part of
> the web site
>   you may access : change that cookie and you may access
> anywhere :-( !
>
> Often the cookie is obfuscated with a pseudo cryptographic
> algorythm à la
> xor using a short fixed length key.
>
> > there is any information on this sort of technique I would
> appreciate a
> > pointer.
>
> Don't know such a public document.
>
> Denis Ducamp.
>
> --
> Denis.Ducamp () hsc fr -- Hervé Schauer Consultants -- http://www.hsc.fr/



GFI - Security & communications products for Windows NT/2000
http://www.gfi.com

**********************************************************
This mail was content checked for malicious code or viruses
by Mail essentials. Mail essentials for Exchange/SMTP is an
email security, content checking & anti-virus gateway that
removes all types of email-borne threats before they can affect
your email users. Spam, viruses, dangerous attachments & offensive
content can be removed before they reach your mail server.
In addition it has server-based email encryption, disclaimers
and other email features.
***********************************************************

In addition to Mail essentials, GFI also produces the FAXmaker
fax server product range & LANguard internet access control &
intrusion detection. For more information on our products please
visit http://www.gfi.com