Session ids in cookies are no more secure than session ids in URLs -- they are just as susceptible to snooping even though they are not physically visible. If attacks via session id are an important issue for you, you should be using SSL instead.
App servers do indeed sometimes have settings to enable or disable various approaches to session management -- check the config docs for your server. Craig On Thu, 14 Nov 2002, Tom Wadzinski wrote: > Date: Thu, 14 Nov 2002 18:05:15 -0500 > From: Tom Wadzinski <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Disabling jsessionid parameter in Struts forms > > > From Craig McClanahan: > > The "jsessionid" path parameter is indeed added by the call that > Struts > > automatically makes to response.encodeURL() when setting up URLs for > you. > > Without this automatic feature, you'd have to call encodeURL() > yourself in > > order to ensure that your application works when your client does not > have > > cookies enabled. > >... > > There is no configuration parameter to turn this off, and there won't > be. > > The important principle you should get used to is that the actual > contents > > of the request URL is pretty meaningless in a web application based on > > Model 2 design patterns. You're far better training yourself (and > your > > users) to ignore the URL completely rather than obsessing over the > > detailed contents. > > What are of concern to site maintainers are the security implications of > passing the jsessionid in the URL. > > Consider the following scenarios (assuming user has cookies disabled): > > 1) The "Referer" header now contains the jsessionid. An example exploit > on this would be on a struts-based web email site. A malicious 3rd > party sends an html email to a user which contains an html link back to > the 3rd party's site. The user opens the email in the struts-based web > client and clicks the link. The malicious 3rd party now has the session > id and can impersonate the user, as long as the session hasn't timed > out. Note that the referer header is sent on https-to-https links as > well in most if not all browsers, so using SSL doesn't solve the > problem. > > > 2) User A wants to share a struts-based link with User B. They copy the > URL they are on and send it to User B. User B clicks the link and is > inadvertently logged in as User A, as long as the session hasn't timed > out. > > > So, a site that wishes to avoid these risks might impose a "cookies must > be enabled" rule. This rule is commonly imposed by major web sites - > mail.yahoo.com, for example. Note: I'm not suggesting that this is the > reason that yahoo chose to require cookies, but it establishes the fact > the enforcing a "cookies only" policy is common today. > > My understanding (and I'd be pleased to be wrong) is that with > non-customized Struts, imposing a rule like this and keeping the > jsessionid always out of the URL is not possible. This seems > restrictive, and perhaps should be re-evaluated. > > > > One part I'm not clear on is whether or not this can be solved at the > App Server level. Perhaps if the app server doesn't honor the > jsessionid parameter as a session establishment method, this might be a > way around the problem. Though even there, it seems in scenario 1 above > that the malicious 3rd party would still receive the jsessionid, because > struts will send it regardless of app server settings. The malicious > 3rd part could then forge a cookie containing the jsessionid, and they'd > still be able to impersonate the user by passing the id in via a cookie. > > Regards, > Tom Wadzinski > > > -- > To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org> > > -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
