Re: Let's talk about HTTPS Everywhere

[Dave Sherohman <dave@sherohman.org>]

On Thu, Jan 20, 2011 at 03:26:31PM +0000, Camaleón wrote:
> In regards to "http cookie hijacking" the first and foremost a programmer 
> would ask himself is "do we really need to *constantly* generate a write/
> read operations of the cookies for *all* the tasks?".

Unfortunately, if the site is to exist within a single base URI, yes, we
do need to *constantly* read cookies.  That's the way browsers work - if
the browser holds any cookies related to a given URI, it will send those
cookies on *every* request to that URI.  The cookies are not requested
on a per-fetch basis by the server.

The only way around this is to have separate "/public" and
"/authenticated" spaces within your app's URI space and set all cookies
to apply only to the "/authenticated" space.  This isn't a viable
solution these days, however, as it means that documents in the
"/public" space will have absolutely no access to any information
regarding the user or his session, so it won't be able to do things that
users have become accustomed to, such as showing who you're logged in as
(or even whether you're logged in at all, making any "login" or "logout"
links within the "/public" space problematic, at best).

(Well, OK, there is one other way around it:  Discard the stateless HTTP
protocol and replace it with a protocol based on persistent connections
so that you don't have to fake persistence by using cookies to
re-identify yourself every time you talk to the server, but there's no
way that's happening any time soon.)

> If the data, that now is being exchanged between the server and user's 
> computer by means of cookies, is to be stored in the server itself in a 
> database, most of theses attacks could be prevented.

Any decent site will only use a single cookie containing a random
session ID and store all additional data on the server itself, keyed to
that ID.  In this (extremely common) scenario, the only thing being
exchanged between the server and the user's computer by means of cookies
is this identification token; storing it solely on the server and not
repeatedly exchanging it would mean that the server is not able to
identify the user.

-- 
Dave Sherohman