Re: Disabling jsessionid parameter in Struts forms

[Tom Wadzinski <tw...@yahoo.com>]

>  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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Disabling jsessionid parameter in Struts forms

["Craig R. McClanahan" <cr...@apache.org>]

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 <tw...@yahoo.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> 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:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>