comments inline > -----Original Message----- > From: Tom Wadzinski [mailto:twadzins@;yahoo.com] > Sent: Thursday, November 14, 2002 3:05 PM > 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.
This is so easy to implement yourself it barely even bears discussing. Create an abstract Action super-class, check to see if cookies are enabled, and if they aren't, block access and give the user an error message to that effect. You could have written it in the time you composed this email. > > > > 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. No, they wouldn't, because Struts only appends the session id if cookies are disabled. If the app. server require cookies to be enabled for a session, then this will never happen because the user will be unable to log in (with cookies disabled) in the first place. > > 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>
