Re: Introducing a Session header...

>> But they were completely abused to carry anything
>> everywhere and the first issue is that JS has access to them.

>Aye. But to kill them we have to pull out their utility and provide
>easier tools for their users to work with.

Actually the main cookie issue is that their scope is fuzzy, so everyone
(server, intermediaries, user agents) applies heuristics to what has
access and when, resulting in very brittle configurations that are abused
just by stepping outside the heuristic writer assumptions (most often
without malicious thoughts). And because agents tend to be conservative
about the scope to avoid breakage, it was open to many abuses.

To have a reliable system you would need something like the following:

1. at the start of a stateful interaction the server (only actor that
knows it will need state) challenges the user agent for a new unique id,
and provides a unique state tag (short so it can not be abused for
anything else)

2. the user agent generates it following its own rules and sends it to the
server. Server gets no say in what ends up in the id (can only reject it
if not unique)

3. the server then tags anything related to this state with its tag (bank
logo is not stateful, even if sent over tls, it's ok for the user agent to
reuse it later in another tab)

4. it also explicitely tags the URLs over which it expects stateful answers

5. the user agent tags its use of those URLs with the id it provided at
the beginning of the interaction

6. if at any point server of user agent get any answer/request that
reference an unknown or stale tag/id (too old, node ip change , whatever)
they dump it (or request a retry with a 'good' id if you prefer). No one
is supposed to reuse anything tagged with an old session id.

7. multiple levels of state can exist at the same moment, but they are all
transient (secure clients refuse indefinite states)

That is more reliable and less open to abuses (and it prevents all the
breakage that occurs when some content is served from cache or a page is
reloaded). But it forces the server (not the client) to maintain what's
associated with a particular state and to define precisely the state
boundaries. So it's going to be more expensive for webapp authors. And
it's not going to be popular web application-side (but then reliable is
never cheap for the easy cases. Reliable forces everyone to pay the
difficult cases costs). Cookies are convenient just like global variables
in php were convenient till people realised they were too abuse-prone to
live.

(and this is not intended to be secure, just protect from the problems
that occur today when one part of the chain gets confused over what it can
reuse. For security you probably need to add more)

I'm quite sure that if such a mechanism existed today the EU would have
just banned cookie use altogether.

-- 
Nicolas Mailhot

Received on Friday, 20 July 2012 10:31:44 UTC