server push and cookies

[Bryan McQuade]

Hi,

We're looking at implementing server push in mod_spdy now.

The way we do this is to kick off a new Apache request generator that
processes the request for the pushed stream. The pushed stream
inherits request headers from the associated stream.

This mostly works fine however cookies are not scoped in exactly the
same way as the same origin policy (same origin cares only about
scheme hostname port whereas cookies also may care about path) so it's
possible for a valid server push to have different cookies from its
associated stream. For instance imagine I have a cookie A with
hostname www.foo.com and path /foo/bar

Imagine that the associated stream at /foo/bar/baz does a server push
for /other/resource.

In this case it seems that the original cookie A should not be
propagated to the generator/handler for the pushed stream, since its
path does not match. It seems especially undesirable to propagate the
cookie in server environments where /foo/bar/baz and /other/resource
are processed by different systems that aren't supposed to be able to
see each other's cookies.

However I do not think that the server has any knowledge of cookie
scope; the Cookie request header IIRC doesn't include the cookie path,
etc.

So I'm curious how SPDY wants to proceed here. One option would be to
say that pushed streams never inherit cookies, and that the associated
stream is responsible for explicitly specifying all cookies for the
pushed stream at the time the pushed stream is initiated on the
server. This delegates the cookie security scoping problem to the
server, which is the system that does best understand whih cookies are
allowed on which path prefixes. Another would be to say that pushed
streams inherit all cookies of the associated stream (this is the
current wording in the spec as I understand it: "For this reason,
browsers MUST be careful to inherit request headers from the
associated stream for the push. This includes the 'Cookie' header.")
even though we know that if the same stream was initiated by the
client, the cookies might be different due to cookie path scoping.

I am not an HTTP security expert but on first glance I do worry that
we run the risk of leaking cookies outside of their scoped path if we
continue to implement the current policy.

What is the best way to proceed here?

Thanks,
Bryan

[Mike Belshe]

It's good you're observing this behavior - you definitely must not pass cross-path cookies to pushed resources.

You could:

   - disallow pushes for content not within the same path

   - disallow cookies for pushed content (works fine for a lot of static content)

   - not pass the cookie to the pushed resource handling

   - filter based on path for the pushed resource handling

Pushes are app-specific, only the app really knows when to do a push.  Because you can't transparently do pushes, it doesn't seem problematic to me to have a few server-side restrictions here.  In fact, different server implementors may offer different features for how this would work.

Mike

[James A. Morrison]

Mike, if I'm reading this correctly, you are suggesting that the
spec not specify what to do with cookies, but servers could
implement 3 and/or 4.

--
Thanks,
Jim
http://phython.blogspot.com

[Mike Belshe]

On Fri, Jan 27, 2012 at 11:40 AM, James A. Morrison <jim.mo...@gmail.com> wrote:

Mike, if I'm reading this correctly, you are suggesting that the
spec not specify what to do with cookies, but servers could
implement 3 and/or 4.

Correct. 

It seems to me that if this occurred it would simply be a server bug.

mike