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. 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.
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 ? If that doesn't convince you, you've won this argument. (Which doesn't mean you're right ;-) cheers, Roland Oleg Kalnichevski <[EMAIL PROTECTED]> 17.02.2005 12:04 Please respond to "HttpClient User Discussion" To HttpClient User Discussion <[email protected]> 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 <[EMAIL PROTECTED]> > 17.02.2005 11:28 > Please respond to > "HttpClient User Discussion" > > > To > HttpClient User Discussion <[email protected]> > 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 <[EMAIL PROTECTED]> > > 17.02.2005 11:10 > > Please respond to > > "HttpClient User Discussion" > > > > > > To > > HttpClient User Discussion <[email protected]> > > 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 <[EMAIL PROTECTED]> > > > 17.02.2005 10:31 > > > Please respond to > > > "HttpClient User Discussion" > > > > > > > > > To > > > HttpClient User Discussion <[email protected]> > > > 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
