You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Martin O'Shea <ap...@dsl.pipex.com> on 2011/09/18 17:05:10 UTC
Session management issue with Tomcat
Hello
I have a situation where I'm using Tomcat 6.0.26 but the logging in / out of
the application is not authenticated via Tomcat's:
action='<%= response.encodeURL("j_security_check") %>' >
method.
The current system allows cookies to store userids which are used to show
recent lists on the homepage of the application. So for a session, a user's
userid can be read from the cookie and used to retrieve their details from
the database and store them in the session, and render the hompage with its
personalised recent list.
The user's id can also then be placed in the login username box with the
password stored in the session.
But, in a single browser session, if the first user logs out, and another
user logs in, the cookie is re-written with the new user's userid. But,
because this is all in one browser session, use of the browser's back button
allows the new user to access the profile details of the first user if the
first user visited the page before logging off.
No secure data is held in the system.
Can anyone suggest a way to change this? I am no expert on session
management.
Thanks.
Re: Session management issue with Tomcat
Posted by Pid <pi...@pidster.com>.
On 22/09/2011 13:56, Shanti Suresh wrote:
> Hi Martin,
>
> You will have to expire/invalidate the session in the code upon user logout. This way when the cookie comes in, there is no corresponding session-ID and the system will create a new session. Are you doing that already? Does that help?
>
> -Shanti
>
> On Sep 20, 2011, at 1:20 PM, Christopher Schultz wrote:
>
> Martin,
>
> On 9/18/2011 11:05 AM, Martin O'Shea wrote:
>>>> I have a situation where I'm using Tomcat 6.0.26 but the logging in
>>>> / out of the application is not authenticated via Tomcat's:
>>>>
>>>> action='<%= response.encodeURL("j_security_check") %>' >
>>>>
>>>> method.
>
> You mean to say that you are using your own authentication mechanism,
> right?
I think we should clarify what is really happening.
The code sample above implies authentication is occurring.
If authentication is successful, the userid is then stored in a cookie.
The OP states that cookie data is used to display personalised lists of
information.
Martin: how is the data being stored in a cookie - do you mean a custom
cookie, or are you referring to the cookie generated for the session?
Can you show a code sample of how the userid is retrieved from the cookie?
p
>>>> The current system allows cookies to store userids which are used
>>>> to show recent lists on the homepage of the application. So for a
>>>> session, a user's userid can be read from the cookie and used to
>>>> retrieve their details from the database and store them in the
>>>> session, and render the hompage with its personalised recent list.
>
> So, any remote user can provide a forged cookie to read anyone's
> "recent list" if they want? You might want to encrypt those cookies.
>
>>>> The user's id can also then be placed in the login username box
>>>> with the password stored in the session.
>
> So, you use an untrusted user id coming from a remote cookie to
> populate the user's username and password on a login page? Sounds like
> that's a problem.
>
>>>> But, in a single browser session, if the first user logs out, and
>>>> another user logs in, the cookie is re-written with the new user's
>>>> userid. But, because this is all in one browser session, use of the
>>>> browser's back button allows the new user to access the profile
>>>> details of the first user if the first user visited the page before
>>>> logging off.
>
> So, what you are saying is that the design of the web browser allows a
> second user to observe what the first user did by looking at the
> history and/or cache? There's not a lot you can do about that. You can
> send "no-cache" response headers to the browser, etc. but there's
> always a chance that the browser doesn't respect them, etc. and the
> history can be viewed.
>
> I'm not sure there's a way around that. Even if you use javascript to
> kill the window/tab, many browsers have a "re-open closed window/tab"
> that will resurrect the window/tab with the history in-tact, so you
> haven't bought anything there.
>
> I guess this is why you should be careful what you do from as public
> terminal, eh?
>
>>>> No secure data is held in the system.
>
> That's good, given the shaky security you've described here.
>
>>>> Can anyone suggest a way to change this? I am no expert on session
>>>> management.
>
> It's the browser that is the problem, not your session management. I
> think you need to instruct your users to completely exit the browser
> after they use your site if they value their privacy.
>
> -chris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> !DSPAM:4e78cb6c11371347337680!
>>
>>
>>
>
> --
> Shanti Suresh
> App Systems Analyst Lead
> Web Services, LSA Development
> University of Michigan
> Office: 734-763-4807
> shanti@umich.edu
> http://lsa.umich.edu/cms
>
>
>
>
>
>
Re: Session management issue with Tomcat
Posted by Pid <pi...@pidster.com>.
On 23/09/2011 19:47, Martin O'Shea wrote:
> I should have mentioned that as only one user can be logged into a browser
> session at any one time, they do have to log out for another user to log on.
> But the logging out process does not do any cookie handling or
> server-session invalidation.
The only way to execute a logout from FORM auth is session.invalidate();
p
> This last step maybe the missing link.
>
> -----Original Message-----
> From: Martin O'Shea [mailto:appy74@dsl.pipex.com]
> Sent: 22 Sep 2011 19 49
> To: 'Tomcat Users List'
> Subject: RE: Session management issue with Tomcat
>
> To answer your questions:
>
> Is there a reason this data is in a custom cookie, rather than the session,
> via setAttribute()?
>
> The cookie is dedicated and meant to be persistent. The idea is that a user
> is recognised by the system upon returning to the website after having been
> away for some time. Hence, the userid is stored in the cookie, so that when
> the user returns to the homepage, the homepage can read the cookie, and
> present that user's recent list on the page.
>
> What is the expiry time of the custom cookie?
>
> The cookie is set for a year.
>
> How exactly are you invalidating this other cookie, when you invalidate the
> session?
>
> I assume you mean Tomcat's session and not the browser's sessions. The
> Tomcat sessions are not being invalidated at the moment.
>
> The underlying principle here is that if multiple users use the same PC, and
> maybe even the same session in a browser, a single cookie is used to store a
> userid. Various system pages have a login facility and if invoked, the
> cookie is rewritten with the current user's id. But this is where the Back
> button issue occurs so it may be that session invalidation solve my
> problem.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
RE: Session management issue with Tomcat
Posted by Martin O'Shea <ap...@dsl.pipex.com>.
I should have mentioned that as only one user can be logged into a browser
session at any one time, they do have to log out for another user to log on.
But the logging out process does not do any cookie handling or
server-session invalidation.
This last step maybe the missing link.
-----Original Message-----
From: Martin O'Shea [mailto:appy74@dsl.pipex.com]
Sent: 22 Sep 2011 19 49
To: 'Tomcat Users List'
Subject: RE: Session management issue with Tomcat
To answer your questions:
Is there a reason this data is in a custom cookie, rather than the session,
via setAttribute()?
The cookie is dedicated and meant to be persistent. The idea is that a user
is recognised by the system upon returning to the website after having been
away for some time. Hence, the userid is stored in the cookie, so that when
the user returns to the homepage, the homepage can read the cookie, and
present that user's recent list on the page.
What is the expiry time of the custom cookie?
The cookie is set for a year.
How exactly are you invalidating this other cookie, when you invalidate the
session?
I assume you mean Tomcat's session and not the browser's sessions. The
Tomcat sessions are not being invalidated at the moment.
The underlying principle here is that if multiple users use the same PC, and
maybe even the same session in a browser, a single cookie is used to store a
userid. Various system pages have a login facility and if invoked, the
cookie is rewritten with the current user's id. But this is where the Back
button issue occurs so it may be that session invalidation solve my
problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session management issue with Tomcat
Posted by André Warnier <aw...@ice-sa.com>.
Just noticing something here, and ading my grain of salt :
Martin O'Shea wrote:
...
>
> The underlying principle here is that if multiple users use the same PC,
(with or without logging out/in ?)
and
> maybe even the same session in a browser, a single cookie is used to store a
> userid. Various system pages have a login facility and if invoked, the
> cookie is rewritten with the current user's id. But this is where the Back
> button issue occurs so it may be that session invalidation solve my
> problem.
>
I would tend to say that if multiple users use a PC, and they do not each login with their
own user-id, then the basic behaviour which you explain is to be expected.
These users share a single "user environment" on that PC, which includes the browser's
history, cookies, and much more that that under Windows (think "recent documents", desktop
etc..).
I am not sure that the issue then is at your application level or at the Tomcat level.
It is more at the general usage (and security) policies level.
Morality : don't do that.
If users do logout and login on that PC each with his own user-id, that issue would not
exist, because Windows keeps a separate "user profile" for each of these users, so they
would never share a cookie e.g.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session management issue with Tomcat
Posted by Pid <pi...@pidster.com>.
On 22/09/2011 19:49, Martin O'Shea wrote:
> To answer your questions:
>
> Is there a reason this data is in a custom cookie, rather than the
> session, via setAttribute()?
>
> The cookie is dedicated and meant to be persistent. The idea is that a user
> is recognised by the system upon returning to the website after having been
> away for some time. Hence, the userid is stored in the cookie, so that when
> the user returns to the homepage, the homepage can read the cookie, and
> present that user's recent list on the page.
>
> What is the expiry time of the custom cookie?
>
> The cookie is set for a year.
>
> How exactly are you invalidating this other cookie, when you
> invalidate the session?
>
> I assume you mean Tomcat's session and not the browser's sessions. The
> Tomcat sessions are not being invalidated at the moment.
>
> The underlying principle here is that if multiple users use the same PC, and
> maybe even the same session in a browser, a single cookie is used to store a
> userid. Various system pages have a login facility and if invoked, the
> cookie is rewritten with the current user's id. But this is where the Back
> button issue occurs so it may be that session invalidation solve my
> problem.
I don't understand...
How can a new user log in, if you're not logging out?
If you're using FORM auth, then you need a logout mechanism to do that,
and a logout mechanism requires you to invalidate the http session in
Tomcat.
p
RE: Session management issue with Tomcat
Posted by Martin O'Shea <ap...@dsl.pipex.com>.
To answer your questions:
Is there a reason this data is in a custom cookie, rather than the
session, via setAttribute()?
The cookie is dedicated and meant to be persistent. The idea is that a user
is recognised by the system upon returning to the website after having been
away for some time. Hence, the userid is stored in the cookie, so that when
the user returns to the homepage, the homepage can read the cookie, and
present that user's recent list on the page.
What is the expiry time of the custom cookie?
The cookie is set for a year.
How exactly are you invalidating this other cookie, when you
invalidate the session?
I assume you mean Tomcat's session and not the browser's sessions. The
Tomcat sessions are not being invalidated at the moment.
The underlying principle here is that if multiple users use the same PC, and
maybe even the same session in a browser, a single cookie is used to store a
userid. Various system pages have a login facility and if invoked, the
cookie is rewritten with the current user's id. But this is where the Back
button issue occurs so it may be that session invalidation solve my
problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session management issue with Tomcat
Posted by Pid * <pi...@pidster.com>.
Is there a reason this data is in a custom cookie, rather than the
session, via setAttribute()?
What is the expiry time of the custom cookie?
How exactly are you invalidating this other cookie, when you
invalidate the session?
p
On 22 Sep 2011, at 15:08, "Martin O'Shea" <ap...@dsl.pipex.com> wrote:
> OK. This is what the contents of a typical cookie on the system look like:
>
> 978937_19082010_1282218386857
> localhost/
> 1024
> 2913476352
> 30544688
> 1374261013
> 30177561
> *
>
> Where userid is 978937_19082010_1282218386857 matching the key of the user
> table in the database.
>
> The cookie is not encrypted.
>
> Code in the system to retrieve the cookie is:
>
> // Gets the value of a cookie.
> public static String getCookieValue(Cookie[] cookies, String cookieName)
> {
> String cookieValue = ("");
> Cookie cookie;
> boolean found = false;
> if (cookies != null) {
> for (int i = 0; i < cookies.length; i++) {
> cookie = cookies[i];
> if (cookieName.equals(cookie.getName())) {
> cookieValue = cookie.getValue();
> found = true;
> break;
> }
> if (found) {
> return cookieValue;
> }
> }
> }
> return cookieValue;
> }
>
> The cookieName parameter here is the name of the cookie which is myAppUser
>
> This all seems to work fine.
>
> -----Original Message-----
> From: Martin O'Shea [mailto:appy74@dsl.pipex.com]
> Sent: 22 Sep 2011 14 03
> To: 'Tomcat Users List'
> Subject: RE: Session management issue with Tomcat
>
> Shanti
>
> I was thinking that this was the problem and at the moment I have been
> trying to force the pages to reload from the server by using a filter to
> prevent browser caching as follows:
>
> try {
> HttpServletResponse hsr = (HttpServletResponse) response;
> hsr.setHeader("Cache-Control", "no-cache, no-store,
> must-revalidate"); // HTTP 1.1.
> hsr.setHeader("Pragma", "no-cache"); // HTTP 1.0.
> hsr.setDateHeader("Expires", 0); // Proxies.
> chain.doFilter(request, response);
> } catch (Throwable t) {
> ...
> }
>
> But the results are imperfect.
>
> Is this the sort of thing you mean?
>
> http://www.koelnerwasser.de/?p=11
>
> Or can you tell me what to do if I am wrong?
>
> Thanks
>
> Martin O'Shea.
>
>
>
> -----Original Message-----
> From: Shanti Suresh [mailto:shanti@umich.edu]
> Sent: 22 Sep 2011 13 57
> To: Tomcat Users List
> Subject: Re: Session management issue with Tomcat
>
> Hi Martin,
>
> You will have to expire/invalidate the session in the code upon user logout.
> This way when the cookie comes in, there is no corresponding session-ID and
> the system will create a new session. Are you doing that already? Does
> that help?
>
> -Shanti
>
> On Sep 20, 2011, at 1:20 PM, Christopher Schultz wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Martin,
>>
>> On 9/18/2011 11:05 AM, Martin O'Shea wrote:
>>> I have a situation where I'm using Tomcat 6.0.26 but the logging in /
>>> out of the application is not authenticated via Tomcat's:
>>>
>>> action='<%= response.encodeURL("j_security_check") %>' >
>>>
>>> method.
>>
>> You mean to say that you are using your own authentication mechanism,
>> right?
>>
>>> The current system allows cookies to store userids which are used to
>>> show recent lists on the homepage of the application. So for a
>>> session, a user's userid can be read from the cookie and used to
>>> retrieve their details from the database and store them in the
>>> session, and render the hompage with its personalised recent list.
>>
>> So, any remote user can provide a forged cookie to read anyone's
>> "recent list" if they want? You might want to encrypt those cookies.
>>
>>> The user's id can also then be placed in the login username box with
>>> the password stored in the session.
>>
>> So, you use an untrusted user id coming from a remote cookie to
>> populate the user's username and password on a login page? Sounds like
>> that's a problem.
>>
>>> But, in a single browser session, if the first user logs out, and
>>> another user logs in, the cookie is re-written with the new user's
>>> userid. But, because this is all in one browser session, use of the
>>> browser's back button allows the new user to access the profile
>>> details of the first user if the first user visited the page before
>>> logging off.
>>
>> So, what you are saying is that the design of the web browser allows a
>> second user to observe what the first user did by looking at the
>> history and/or cache? There's not a lot you can do about that. You can
>> send "no-cache" response headers to the browser, etc. but there's
>> always a chance that the browser doesn't respect them, etc. and the
>> history can be viewed.
>>
>> I'm not sure there's a way around that. Even if you use javascript to
>> kill the window/tab, many browsers have a "re-open closed window/tab"
>> that will resurrect the window/tab with the history in-tact, so you
>> haven't bought anything there.
>>
>> I guess this is why you should be careful what you do from as public
>> terminal, eh?
>>
>>> No secure data is held in the system.
>>
>> That's good, given the shaky security you've described here.
>>
>>> Can anyone suggest a way to change this? I am no expert on session
>>> management.
>>
>> It's the browser that is the problem, not your session management. I
>> think you need to instruct your users to completely exit the browser
>> after they use your site if they value their privacy.
>>
>> - -chris
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk54y0IACgkQ9CaO5/Lv0PAmLwCfRB69FXn1XUhPbMHQKD/Q/xAd
>> QssAoJMKQk4xudqoGJlf0vkhdLZCkFkp
>> =rYmn
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> !DSPAM:4e78cb6c11371347337680!
>>
>>
>>
>
> --
> Shanti Suresh
> App Systems Analyst Lead
> Web Services, LSA Development
> University of Michigan
> Office: 734-763-4807
> shanti@umich.edu
> http://lsa.umich.edu/cms
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Session management issue with Tomcat
Posted by Martin O'Shea <ap...@dsl.pipex.com>.
OK. This is what the contents of a typical cookie on the system look like:
978937_19082010_1282218386857
localhost/
1024
2913476352
30544688
1374261013
30177561
*
Where userid is 978937_19082010_1282218386857 matching the key of the user
table in the database.
The cookie is not encrypted.
Code in the system to retrieve the cookie is:
// Gets the value of a cookie.
public static String getCookieValue(Cookie[] cookies, String cookieName)
{
String cookieValue = ("");
Cookie cookie;
boolean found = false;
if (cookies != null) {
for (int i = 0; i < cookies.length; i++) {
cookie = cookies[i];
if (cookieName.equals(cookie.getName())) {
cookieValue = cookie.getValue();
found = true;
break;
}
if (found) {
return cookieValue;
}
}
}
return cookieValue;
}
The cookieName parameter here is the name of the cookie which is myAppUser
This all seems to work fine.
-----Original Message-----
From: Martin O'Shea [mailto:appy74@dsl.pipex.com]
Sent: 22 Sep 2011 14 03
To: 'Tomcat Users List'
Subject: RE: Session management issue with Tomcat
Shanti
I was thinking that this was the problem and at the moment I have been
trying to force the pages to reload from the server by using a filter to
prevent browser caching as follows:
try {
HttpServletResponse hsr = (HttpServletResponse) response;
hsr.setHeader("Cache-Control", "no-cache, no-store,
must-revalidate"); // HTTP 1.1.
hsr.setHeader("Pragma", "no-cache"); // HTTP 1.0.
hsr.setDateHeader("Expires", 0); // Proxies.
chain.doFilter(request, response);
} catch (Throwable t) {
...
}
But the results are imperfect.
Is this the sort of thing you mean?
http://www.koelnerwasser.de/?p=11
Or can you tell me what to do if I am wrong?
Thanks
Martin O'Shea.
-----Original Message-----
From: Shanti Suresh [mailto:shanti@umich.edu]
Sent: 22 Sep 2011 13 57
To: Tomcat Users List
Subject: Re: Session management issue with Tomcat
Hi Martin,
You will have to expire/invalidate the session in the code upon user logout.
This way when the cookie comes in, there is no corresponding session-ID and
the system will create a new session. Are you doing that already? Does
that help?
-Shanti
On Sep 20, 2011, at 1:20 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martin,
>
> On 9/18/2011 11:05 AM, Martin O'Shea wrote:
>> I have a situation where I'm using Tomcat 6.0.26 but the logging in /
>> out of the application is not authenticated via Tomcat's:
>>
>> action='<%= response.encodeURL("j_security_check") %>' >
>>
>> method.
>
> You mean to say that you are using your own authentication mechanism,
> right?
>
>> The current system allows cookies to store userids which are used to
>> show recent lists on the homepage of the application. So for a
>> session, a user's userid can be read from the cookie and used to
>> retrieve their details from the database and store them in the
>> session, and render the hompage with its personalised recent list.
>
> So, any remote user can provide a forged cookie to read anyone's
> "recent list" if they want? You might want to encrypt those cookies.
>
>> The user's id can also then be placed in the login username box with
>> the password stored in the session.
>
> So, you use an untrusted user id coming from a remote cookie to
> populate the user's username and password on a login page? Sounds like
> that's a problem.
>
>> But, in a single browser session, if the first user logs out, and
>> another user logs in, the cookie is re-written with the new user's
>> userid. But, because this is all in one browser session, use of the
>> browser's back button allows the new user to access the profile
>> details of the first user if the first user visited the page before
>> logging off.
>
> So, what you are saying is that the design of the web browser allows a
> second user to observe what the first user did by looking at the
> history and/or cache? There's not a lot you can do about that. You can
> send "no-cache" response headers to the browser, etc. but there's
> always a chance that the browser doesn't respect them, etc. and the
> history can be viewed.
>
> I'm not sure there's a way around that. Even if you use javascript to
> kill the window/tab, many browsers have a "re-open closed window/tab"
> that will resurrect the window/tab with the history in-tact, so you
> haven't bought anything there.
>
> I guess this is why you should be careful what you do from as public
> terminal, eh?
>
>> No secure data is held in the system.
>
> That's good, given the shaky security you've described here.
>
>> Can anyone suggest a way to change this? I am no expert on session
>> management.
>
> It's the browser that is the problem, not your session management. I
> think you need to instruct your users to completely exit the browser
> after they use your site if they value their privacy.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk54y0IACgkQ9CaO5/Lv0PAmLwCfRB69FXn1XUhPbMHQKD/Q/xAd
> QssAoJMKQk4xudqoGJlf0vkhdLZCkFkp
> =rYmn
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> !DSPAM:4e78cb6c11371347337680!
>
>
>
--
Shanti Suresh
App Systems Analyst Lead
Web Services, LSA Development
University of Michigan
Office: 734-763-4807
shanti@umich.edu
http://lsa.umich.edu/cms
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Session management issue with Tomcat
Posted by Martin O'Shea <ap...@dsl.pipex.com>.
Shanti
I was thinking that this was the problem and at the moment I have been
trying to force the pages to reload from the server by using a filter to
prevent browser caching as follows:
try {
HttpServletResponse hsr = (HttpServletResponse) response;
hsr.setHeader("Cache-Control", "no-cache, no-store,
must-revalidate"); // HTTP 1.1.
hsr.setHeader("Pragma", "no-cache"); // HTTP 1.0.
hsr.setDateHeader("Expires", 0); // Proxies.
chain.doFilter(request, response);
} catch (Throwable t) {
...
}
But the results are imperfect.
Is this the sort of thing you mean?
http://www.koelnerwasser.de/?p=11
Or can you tell me what to do if I am wrong?
Thanks
Martin O'Shea.
-----Original Message-----
From: Shanti Suresh [mailto:shanti@umich.edu]
Sent: 22 Sep 2011 13 57
To: Tomcat Users List
Subject: Re: Session management issue with Tomcat
Hi Martin,
You will have to expire/invalidate the session in the code upon user logout.
This way when the cookie comes in, there is no corresponding session-ID and
the system will create a new session. Are you doing that already? Does
that help?
-Shanti
On Sep 20, 2011, at 1:20 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martin,
>
> On 9/18/2011 11:05 AM, Martin O'Shea wrote:
>> I have a situation where I'm using Tomcat 6.0.26 but the logging in /
>> out of the application is not authenticated via Tomcat's:
>>
>> action='<%= response.encodeURL("j_security_check") %>' >
>>
>> method.
>
> You mean to say that you are using your own authentication mechanism,
> right?
>
>> The current system allows cookies to store userids which are used to
>> show recent lists on the homepage of the application. So for a
>> session, a user's userid can be read from the cookie and used to
>> retrieve their details from the database and store them in the
>> session, and render the hompage with its personalised recent list.
>
> So, any remote user can provide a forged cookie to read anyone's
> "recent list" if they want? You might want to encrypt those cookies.
>
>> The user's id can also then be placed in the login username box with
>> the password stored in the session.
>
> So, you use an untrusted user id coming from a remote cookie to
> populate the user's username and password on a login page? Sounds like
> that's a problem.
>
>> But, in a single browser session, if the first user logs out, and
>> another user logs in, the cookie is re-written with the new user's
>> userid. But, because this is all in one browser session, use of the
>> browser's back button allows the new user to access the profile
>> details of the first user if the first user visited the page before
>> logging off.
>
> So, what you are saying is that the design of the web browser allows a
> second user to observe what the first user did by looking at the
> history and/or cache? There's not a lot you can do about that. You can
> send "no-cache" response headers to the browser, etc. but there's
> always a chance that the browser doesn't respect them, etc. and the
> history can be viewed.
>
> I'm not sure there's a way around that. Even if you use javascript to
> kill the window/tab, many browsers have a "re-open closed window/tab"
> that will resurrect the window/tab with the history in-tact, so you
> haven't bought anything there.
>
> I guess this is why you should be careful what you do from as public
> terminal, eh?
>
>> No secure data is held in the system.
>
> That's good, given the shaky security you've described here.
>
>> Can anyone suggest a way to change this? I am no expert on session
>> management.
>
> It's the browser that is the problem, not your session management. I
> think you need to instruct your users to completely exit the browser
> after they use your site if they value their privacy.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk54y0IACgkQ9CaO5/Lv0PAmLwCfRB69FXn1XUhPbMHQKD/Q/xAd
> QssAoJMKQk4xudqoGJlf0vkhdLZCkFkp
> =rYmn
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> !DSPAM:4e78cb6c11371347337680!
>
>
>
--
Shanti Suresh
App Systems Analyst Lead
Web Services, LSA Development
University of Michigan
Office: 734-763-4807
shanti@umich.edu
http://lsa.umich.edu/cms
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session management issue with Tomcat
Posted by Shanti Suresh <sh...@umich.edu>.
Hi Martin,
You will have to expire/invalidate the session in the code upon user logout. This way when the cookie comes in, there is no corresponding session-ID and the system will create a new session. Are you doing that already? Does that help?
-Shanti
On Sep 20, 2011, at 1:20 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martin,
>
> On 9/18/2011 11:05 AM, Martin O'Shea wrote:
>> I have a situation where I'm using Tomcat 6.0.26 but the logging in
>> / out of the application is not authenticated via Tomcat's:
>>
>> action='<%= response.encodeURL("j_security_check") %>' >
>>
>> method.
>
> You mean to say that you are using your own authentication mechanism,
> right?
>
>> The current system allows cookies to store userids which are used
>> to show recent lists on the homepage of the application. So for a
>> session, a user's userid can be read from the cookie and used to
>> retrieve their details from the database and store them in the
>> session, and render the hompage with its personalised recent list.
>
> So, any remote user can provide a forged cookie to read anyone's
> "recent list" if they want? You might want to encrypt those cookies.
>
>> The user's id can also then be placed in the login username box
>> with the password stored in the session.
>
> So, you use an untrusted user id coming from a remote cookie to
> populate the user's username and password on a login page? Sounds like
> that's a problem.
>
>> But, in a single browser session, if the first user logs out, and
>> another user logs in, the cookie is re-written with the new user's
>> userid. But, because this is all in one browser session, use of the
>> browser's back button allows the new user to access the profile
>> details of the first user if the first user visited the page before
>> logging off.
>
> So, what you are saying is that the design of the web browser allows a
> second user to observe what the first user did by looking at the
> history and/or cache? There's not a lot you can do about that. You can
> send "no-cache" response headers to the browser, etc. but there's
> always a chance that the browser doesn't respect them, etc. and the
> history can be viewed.
>
> I'm not sure there's a way around that. Even if you use javascript to
> kill the window/tab, many browsers have a "re-open closed window/tab"
> that will resurrect the window/tab with the history in-tact, so you
> haven't bought anything there.
>
> I guess this is why you should be careful what you do from as public
> terminal, eh?
>
>> No secure data is held in the system.
>
> That's good, given the shaky security you've described here.
>
>> Can anyone suggest a way to change this? I am no expert on session
>> management.
>
> It's the browser that is the problem, not your session management. I
> think you need to instruct your users to completely exit the browser
> after they use your site if they value their privacy.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk54y0IACgkQ9CaO5/Lv0PAmLwCfRB69FXn1XUhPbMHQKD/Q/xAd
> QssAoJMKQk4xudqoGJlf0vkhdLZCkFkp
> =rYmn
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> !DSPAM:4e78cb6c11371347337680!
>
>
>
--
Shanti Suresh
App Systems Analyst Lead
Web Services, LSA Development
University of Michigan
Office: 734-763-4807
shanti@umich.edu
http://lsa.umich.edu/cms
Re: Session management issue with Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin,
On 9/18/2011 11:05 AM, Martin O'Shea wrote:
> I have a situation where I'm using Tomcat 6.0.26 but the logging in
> / out of the application is not authenticated via Tomcat's:
>
> action='<%= response.encodeURL("j_security_check") %>' >
>
> method.
You mean to say that you are using your own authentication mechanism,
right?
> The current system allows cookies to store userids which are used
> to show recent lists on the homepage of the application. So for a
> session, a user's userid can be read from the cookie and used to
> retrieve their details from the database and store them in the
> session, and render the hompage with its personalised recent list.
So, any remote user can provide a forged cookie to read anyone's
"recent list" if they want? You might want to encrypt those cookies.
> The user's id can also then be placed in the login username box
> with the password stored in the session.
So, you use an untrusted user id coming from a remote cookie to
populate the user's username and password on a login page? Sounds like
that's a problem.
> But, in a single browser session, if the first user logs out, and
> another user logs in, the cookie is re-written with the new user's
> userid. But, because this is all in one browser session, use of the
> browser's back button allows the new user to access the profile
> details of the first user if the first user visited the page before
> logging off.
So, what you are saying is that the design of the web browser allows a
second user to observe what the first user did by looking at the
history and/or cache? There's not a lot you can do about that. You can
send "no-cache" response headers to the browser, etc. but there's
always a chance that the browser doesn't respect them, etc. and the
history can be viewed.
I'm not sure there's a way around that. Even if you use javascript to
kill the window/tab, many browsers have a "re-open closed window/tab"
that will resurrect the window/tab with the history in-tact, so you
haven't bought anything there.
I guess this is why you should be careful what you do from as public
terminal, eh?
> No secure data is held in the system.
That's good, given the shaky security you've described here.
> Can anyone suggest a way to change this? I am no expert on session
> management.
It's the browser that is the problem, not your session management. I
think you need to instruct your users to completely exit the browser
after they use your site if they value their privacy.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk54y0IACgkQ9CaO5/Lv0PAmLwCfRB69FXn1XUhPbMHQKD/Q/xAd
QssAoJMKQk4xudqoGJlf0vkhdLZCkFkp
=rYmn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org