NYCPHP Meetup

[Chris Shiflett]

--- George Webb <gw.nyphp at gwprogramming.com> wrote:
> Security:  assuming that SSL is *not* in use, the cookie data can
> be seen by third parties, as we all know.

Good point about SSL. That does indeed mitigate many security concerns.
However, it does not address concerns about browser vulnerabilities.

Because a simple flaw could cause a browser to send cookies to unauthorized
sites, there is still a risk. IE versions 4.0, 5.0, 5.5, and 6.0 have all had
major security flaws that allow anyone to read any cookie from any domain, and
often these flaws expose cookies with the "secure" directive set.

IE 4.0 and 5.0:
http://www.peacefire.org/security/iecookies/

IE 5.5 and 6.0:
http://www.solutions.fi/iebug/

> But some data does not need to be secure

Another excellent point. Sites such as Google use cookies to allow users to set
preferences without having to log in or establish any sort of account. So,
cookies can actually help to *improve* a user's privacy and/or anonymity,
despite their bad reputation. :-)

> Later when a user enters their personal information such as addresses,
> security seems to become more important.

Right. So, at some point you're going to want to concern yourself with
security. Of course, cookies aren't inherently insecure, else any system which
uses them would be easily compromised. You just want to make cookie theft
useless for the attacker (methods of doing this are probably worthy of an
article of some sort).

> So my question is, for a shopping cart application, what user data
> items really need to be secure?

As the developer, you are by far the most qualified person to answer that.

> Efficiency: as Chris knows since he wrote the book on HTTP, the
> HTTP cookie specifications (both Netscape's as well as the
> "version 2") allow for such cookie data to be transported among
> only a subset of viewed pages on a web site. Therefore, in this
> same shopping cart example, the application can efficiently direct
> the HTTP client (web browser) to send the cookie data to only the
> URLs that will need to see it.

True, and this is a good example of applying your creativity to make cookies
work for what you are trying to do. But, is it worth the effort, when there
might be a method you can use to diminish all unnecessary traffic as well as
allow yourself more flexibility on the server-side to access any of the
client's data at any time? That is up to you, but cookies were intended as a
state management mechanism and not really a session management mechanism.

When you do not actually need to maintain a session (Google's user preferences,
perhaps a user's shopping cart while they are still shopping, etc.), cookies
are probably fine.

> Another efficiency issue relates to the size of the HTTP cookies.
> To this end we could specially format and even compress or pack the
> user data into a smaller byte-representation. For example, an
> uncompressed "cart contents" cookie with three line items might look
> like this:
> 
> 1|PJ00111|c:blue;s:small|1|PJ00103|c:orange;s=small|8|ACC00101|s:5|
> 
> The server can then do product lookup queries on each of these
> three items to build a more readable or detailed list

This is similar to looking up a client's data based on the unique identifier.
It seems to be a similar problem with the exception that the client data is
more volatile.

> I would really like to make HTTP cookies do the work that we normally
> impose on central databases, because then we can scale a server cluster
> linearly, simply by adding more hardware.

There are many creative ideas out there for addressing this problem. You could
use different hostnames much like you mentioned using different cookies paths.
You could implement a more intelligent "sticky sessions" mechanism. Another
option might be to look into using msession, since it allows you to use
sessions in a cluster without a central database. In the end, whatever you're
most comfortable with is probably going to be what gets the job done.

Hope that helps.

Chris

=====
Become a better Web developer with the HTTP Developer's Handbook
http://httphandbook.org/