hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: cookie paths (was: Can someone please explain what these errors mean?)
Date Thu, 17 Feb 2005 12:30:42 GMT
On Thu, Feb 17, 2005 at 01:12:47PM +0100, Roland Weber wrote:
> Hi Oleg,
> 
> Amazon controls all their applications :-) Seriously, when
> you deploy web modules on a single host, you have to
> take care that these modules interact well. For co-hosting,
> you better use different host names.

Think of session cookies. Most of browsers do not include the path
attribute when sending cookies to the server. If the scheme you 
are suggesting were correct a servlet engine would not be able to 
distinguish session ids of individual web applications


> If you want to prevent the kind of cross-path-cooking
> attack you describe, that has to happen on the server.
> The browser/client will never be able to tell whether two
> paths belong to different applications or to different parts
> of the same application.

They can't and they are not supposed to. They just have to follow the
cookie spec. This is precisely the reason for disallowing cookie with a
more genetric path attribute, eg "/app1/stuff", originating from a URL
like "/app/stuff/morestuff/myapp.asp".

> 
> Ok, one last example. You write a servlet and deploy it
> with servlet mapping /app1/*. That means all requests
> below /app1/ end up being served by that same servlet.
> Surely, you would expect the servlet to be able to set
> a cookie for /app1, even if the request URI is
> /app1/with/extra/information/and/some ?

No, I would not. I have been acting Evil Cookie Ayatollah for quite a
while already ;-) 

Please do take a look at the Netscape draft:

 path=PATH
     The path attribute is used to specify the subset of URLs in a
     domain for which the cookie is valid. If a cookie has already
     passed domain matching, then the pathname component of the URL is
     compared with the path attribute, and if there is a match, the
     cookie is considered valid and is sent along with the URL request.
     The path "/foo" would match "/foobar" and "/foo/bar.html". The path
     "/" is the most general path.

RFC 2109 meant to say pretty much the same

> 
> If that doesn't convince you, you've won this argument.
> (Which doesn't mean you're right ;-)

I have no problem with being proven wrong. I can err as any mortal human.

Cheers,

Oleg


> 
> cheers,
>   Roland
> 
> 
> 
> 
> 
> Oleg Kalnichevski <olegk@apache.org> 
> 17.02.2005 12:04
> Please respond to
> "HttpClient User Discussion"
> 
> 
> To
> HttpClient User Discussion <httpclient-user@jakarta.apache.org>
> cc
> 
> Subject
> Re: cookie paths (was: Can someone please explain what these errors mean?)
> 
> 
> 
> 
> 
> 
> Cmon, Roland
> 
> You SERIOUSLY would not mind /evil-russian-mafia application sending
> session cookies to /goodie-goodie-american-co application co-hosted on
> the same server WITHOUT Goodie Goodie American Co consent? ;-)
> 
> Think twice next time you place an order on Amazon.
> 
> 
> On Thu, Feb 17, 2005 at 11:50:07AM +0100, Roland Weber wrote:
> > Hi Oleg,
> > 
> > you are allowed to disagree ;-)
> > 
> > If /app1 and /app2 want to share a session, the session cookie
> > must be set with path "/" by either of them. 
> 
> What if one of them does not?
> 
> If they don't want
> > to share a cookie, they set it with their own prefix /app1 or /app2.
> > 
> > If cookies collide by name, RFC 2965 says (page 12, top) that
> > the one with the more specific path must come first in the
> > header. So the cookie "MYOMY" with path /app1 will be found
> > before the cookie "MYOMY" with path /. That helps to resolve
> > collissions between cookies with different paths.
> > 
> > To pick up your interpretation, if /app1 was allowed to set a
> > cookie for /app1/whatever/, how is it supposed to receive that
> > cookie ever again?
> 
> By specifying /app1 as a cookie path attribute. Please take a look at
> the original Netscape cookie draft. It is slightly more human readable
> than those RFC that take a PhD Stanford to interpret. See examples given
> in the draft
> 
> http://wp.netscape.com/newsref/std/cookie_spec.html
> 
> Oleg the Evil Cookie Ayatollah 
> 
> The prefix condition in my interpretation
> > makes sure that the one who sets a cookie will always be
> > allowed to get it back.
> > 
> > cheers,
> >   Roland
> > 
> > 
> > 
> > 
> > 
> > Oleg Kalnichevski <olegk@apache.org> 
> > 17.02.2005 11:28
> > Please respond to
> > "HttpClient User Discussion"
> > 
> > 
> > To
> > HttpClient User Discussion <httpclient-user@jakarta.apache.org>
> > cc
> > 
> > Subject
> > Re: cookie paths (was: Can someone please explain what these errors 
> mean?)
> > 
> > 
> > 
> > 
> > 
> > 
> > Roland,
> > With all due respect allow me to disagree. I see it absolutely the other
> > way around.
> > 
> > Since we talk examples, consider the following: you have two web apps 
> > hosted by the same web server with different URL prefixes
> > 
> > /app1
> > /app2
> > 
> > I seriously doubt you'd want a cookie set by /app1 to be sent tp /app2
> > 
> > Cheers,
> > 
> > Oleg
> > 
> > 
> > On Thu, Feb 17, 2005 at 11:19:46AM +0100, Roland Weber wrote:
> > > Hi Oleg,
> > > 
> > > then I was misinterpreting you. Let's put in some examples:
> > > 
> > > > RFC 2109
> > > > 
> > > > <quote>
> > > > 4.3.2  Rejecting Cookies
> > > > 
> > > > To prevent possible security or privacy violations, a user agent 
> > rejects
> > > > a cookie (shall not store its information) if any of the following 
> is
> > > > true:
> > > > 
> > > > * The value for the Path attribute is not a prefix of the 
> request-URI.
> > > > 
> > > > </quote>
> > > 
> > > request-URI:    /Canada/whatever.asp
> > > Path attribute: /
> > > 
> > > The Path attribute "/" of the received cookie is a prefix of the 
> > > request-URI
> > > "/Canada/whatever.asp" from where it is set, so the cookie will not be 
> 
> > > rejected.
> > > 
> > > In other words, a servlet can set cookies with a path shorter than
> > > it's own, but not longer than or different from it's own.
> > > 
> > > cheers,
> > >   Roland
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Oleg Kalnichevski <olegk@apache.org> 
> > > 17.02.2005 11:10
> > > Please respond to
> > > "HttpClient User Discussion"
> > > 
> > > 
> > > To
> > > HttpClient User Discussion <httpclient-user@jakarta.apache.org>
> > > cc
> > > 
> > > Subject
> > > Re: cookie paths (was: Can someone please explain what these errors 
> > mean?)
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Roland,
> > > 
> > > I still think the wording of the RFCs implies that "/Canada/" 
> > > matches "/" but not the other way around. A cookie with a path 
> attribute
> > > "/Canada" can be set at the URL "/", but not visa versa.
> > > 
> > > Oleg
> > > 
> > > 
> > > On Thu, Feb 17, 2005 at 10:43:51AM +0100, Roland Weber wrote:
> > > > Hi Oleg,
> > > > 
> > > > speaking from a string perspective, "/" is a prefix of both,
> > > > "/Canada" and "/Canada/whatever.asp". RFC 2965 mentions
> > > > string-matching for paths on top of page 2.
> > > > 
> > > > cheers,
> > > >   Roland
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Oleg Kalnichevski <olegk@apache.org> 
> > > > 17.02.2005 10:31
> > > > Please respond to
> > > > "HttpClient User Discussion"
> > > > 
> > > > 
> > > > To
> > > > HttpClient User Discussion <httpclient-user@jakarta.apache.org>
> > > > cc
> > > > 
> > > > Subject
> > > > Re: cookie paths (was: Can someone please explain what these errors 
> > > mean?)
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > RFC 2109
> > > > 
> > > > <quote>
> > > > 4.3.2  Rejecting Cookies
> > > > 
> > > > To prevent possible security or privacy violations, a user agent 
> > rejects
> > > > a cookie (shall not store its information) if any of the following 
> is
> > > > true:
> > > > 
> > > > * The value for the Path attribute is not a prefix of the 
> request-URI.
> > > > 
> > > > </quote>
> > > > 
> > > > Please correct me if I am wrong but the first point implies that a 
> CGI
> > > > at the url "/Canada/whatever.asp" may only set cookies with path
> > > > starting with "/Canada/". Am I misreading the RFC?
> > > > 
> > > > Evil Comrade Oleg (a.k.a cookie ayatollah)
> > > > 
> > > > 
> > > > On Thu, Feb 17, 2005 at 10:17:47AM +0100, Roland Weber wrote:
> > > > > Hi Oleg,
> > > > > 
> > > > > > A cookie with "/" path attribute may not be
> > > > > > set from a URL other than "/". 
> > > > > 
> > > > > my understanding is that a cookie with path "/" may be set from 
> any 
> > > URL 
> > > > > with
> > > > > path prefix "/". RFC 2109 mentions the prefix requirement in 
> section 
> > 
> > > > 4.3.2
> > > > > on page 6. So does RFC 2965 in section 3.3.2 on page 8. Unlike 
> with 
> > > > domain
> > > > > names, there is no "reach" restriction that would prevent a 
> servlet 
> > at
> > > > > /where/ever/it/may/reside to set a cookie for / on that host, 
> which 
> > > > would
> > > > > be the same as setting a cookie without any path at all.
> > > > > 
> > > > > cheers,
> > > > >   Roland
> > > > 
> > > > 
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: 
> httpclient-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: 
> > httpclient-user-help@jakarta.apache.org
> > > > 
> > > > 
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: 
> httpclient-user-help@jakarta.apache.org
> > > 
> > > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


Mime
View raw message