You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Remy Maucherat <re...@apache.org> on 2005/02/07 17:11:06 UTC
[VOTE] Proposed API change to the Manager interface
Hi,
Unfortunately, I found two days ago that there was an issue with the
emptySessionPath feature I had introduced for Pluto. Browsing pluto-dev
archives today, it seems others found the problem even earlier.
The issue is that sessions are getting lost when using
emptySessionPath="true", unless the applications are first accessed
first using crossContext.
To address this, I propose simply reusing any session id presented by
the client. As an option, this could be done only if emptySessionPath is
true. I have tested it, and it works very well, addressing the problem
with emptySessionPath="true". I could not think of any security issue
this would cause (if the client submits a bogus insecure id, then he'll
be the one being impacted), since the undelying session objects would be
created and handled as usual. In "normal" more (emptySessionPath set to
false), this would save costly session id generation.
However, the problem is that I need to modify a method in the top level
Manager interface :(
public Session createSession()
must become:
public Session createSession(String sessionId)
(if sessionId is null, a new session id will be generated)
As the createSession() will no longer be used anywhere, and calling it
in old managers would create bad behavior, I propose removing it rather
than deprecating it.
Managers extending ManagerBase should work and compile as before with no
changes unless they override the createSession method.
Comments, votes ?
Rémy
ServletRequest to MBean Mapping
Posted by Jess Holle <je...@ptc.com>.
Is there any way to map from a javax.servlet.ServletRequest (from within
a filter or whatever) to the JMX data registered on this request by Tomcat?
I am trying to produce some servlet-engine independent MBeans to garner
a certain level of data in an independent fashion but would like to be
able to pluck out certain things from the corresponding Tomcat MBeans
where appropriate, e.g. to jump from ServletRequest to the request
processor to determine how many bytes are read and written by the
request without having to try to redo all of this myself (without direct
access to the buffers).
Ideas?
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Remy Maucherat <re...@apache.org>.
Peter Rossbach wrote:
> Hmm,
>
> I think that Remy's patch is working correct. But I think we must
> controll the jvmRoute
> from those client sessions id's (ManagerBase include this at a comment
> :-)).
> I must check my cluster failover szenarios. I can to that tomorrow.
Yes, I don't know if it is needed or not, so testing is useful.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Peter Rossbach <pr...@objektpark.de>.
Hmm,
I think that Remy's patch is working correct. But I think we must
controll the jvmRoute
from those client sessions id's (ManagerBase include this at a comment :-)).
I must check my cluster failover szenarios. I can to that tomorrow.
Peter
Rainer Jung schrieb:
>Both Cluster Managers (Delta and SimpleTcpReplication) extend ManagerBase
>but override createSession().
>
>Maybe Filip or Peter can check how to make them long-time compatible with
>your proposal?
>
>
>
>>Managers extending ManagerBase should work and compile as before with no
>>
>>
>changes unless they override the createSession method.
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Rainer Jung <to...@kippdata.de>.
Both Cluster Managers (Delta and SimpleTcpReplication) extend ManagerBase
but override createSession().
Maybe Filip or Peter can check how to make them long-time compatible with
your proposal?
> Managers extending ManagerBase should work and compile as before with no
changes unless they override the createSession method.
Re: [VOTE] Proposed API change to the Manager interface
Posted by Rainer Jung <to...@kippdata.de>.
Both Cluster Managers (Delta and SimpleTcpReplication) extend ManagerBase
but override createSession().
Maybe Filip or Peter can check how to make them long-time compatible with
your proposal?
> Managers extending ManagerBase should work and compile as before with no
changes unless they override the createSession method.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Remy Maucherat <re...@apache.org>.
Tim Funk wrote:
> If I read this correctly (big if), the solution could be a security
> problem. If I were a phisher, I might be able to send you an email with
> a link to that would redirect you to a tomcat server with the new
> configuration in question with a special id. If the user were to perform
> other actions of a confidential nature, the attacker could swoop in and
> impersonate that session.
>
> The phisher could easily be notified that the special session id was
> used and have a farm of wamr bodies ready to attack.
Yes, this could maybe be used like this (maybe we could simply prevent
URL session ids from being used for this purpose, which would likely
solve the issue - I hope you can't set a cookie on another host).
Obviously, if you're not using cookies for session tracking, then the
emptySessionPath attribute is useless anyway, so there's no bug ;)
The problem is that I see no other acceptable solution (a global list of
session id, which would be unbounded, would be bad, and introduce lots
of complexity - the API change might be still needed anyway).
What do you think ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> I'd be happier if this was conditional on emptySessionPath="true" (or
> otherwise could be disabled). Otherwise I have to trust that the browser
> doesn't have some JavaScript and/or IFrame bug that allows a Cookie to be
> sent.
I think it should be safe, but once in a while there's a vulnerability
allowing javascript access to the cookie store (in IE ;) ). We can
change that later once it is proven to be safe enough.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Monday, February 07, 2005 8:57 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
>Tim Funk wrote:
>> If I read this correctly (big if), the solution could be a security
>> problem. If I were a phisher, I might be able to send you an email with
>> a link to that would redirect you to a tomcat server with the new
>> configuration in question with a special id. If the user were to perform
>> other actions of a confidential nature, the attacker could swoop in and
>> impersonate that session.
>>
>> The phisher could easily be notified that the special session id was
>> used and have a farm of wamr bodies ready to attack.
>
>My patch at the moment is attached to the email for more detailed
>review. It no longer reuses session ids submitted in the URL (very good
>catch).
>
I'd be happier if this was conditional on emptySessionPath="true" (or
otherwise could be disabled). Otherwise I have to trust that the browser
doesn't have some JavaScript and/or IFrame bug that allows a Cookie to be
sent.
>Rémy
----------------------------------------------------------------------------
----
> Index:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Manager.java
> ===================================================================
> RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Man
ager.java,v
> retrieving revision 1.14
> diff -u -r1.14 Manager.java
> ---
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Manager.java
7 Sep 2004 20:57:02 -0000 1.14
> +++
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Manager.java
7 Feb 2005 16:49:28 -0000
> @@ -257,6 +257,7 @@
> */
> public void addPropertyChangeListener(PropertyChangeListener
listener);
>
> +
> /**
> * Get a session from the recycled ones or create a new empty one.
> * The PersistentManager manager does not need to create session data
> @@ -264,17 +265,22 @@
> */
> public Session createEmptySession();
>
> +
> /**
> * Construct and return a new session object, based on the default
> * settings specified by this Manager's properties. The session
> - * id will be assigned by this method, and available via the getId()
> - * method of the returned session. If a new session cannot be
created
> - * for any reason, return <code>null</code>.
> - *
> + * id specified will be used as the session id.
> + * If a new session cannot be created for any reason, return
> + * <code>null</code>.
> + *
> + * @param sessionId The session id which should be used to create the
> + * new session; if <code>null</code>, the session
> + * id will be assigned by this method, and available via the getId()
> + * method of the returned session.
> * @exception IllegalStateException if a new session cannot be
> * instantiated for any reason
> */
> - public Session createSession();
> + public Session createSession(String sessionId);
>
>
> /**
> Index:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Req
uest.java
> ===================================================================
> RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/con
nector/Request.java,v
> retrieving revision 1.18
> diff -u -r1.18 Request.java
> ---
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Req
uest.java 20 Nov 2004 21:10:47 -0000 1.18
> +++
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Req
uest.java 7 Feb 2005 16:49:29 -0000
> @@ -2196,7 +2196,14 @@
> (sm.getString("coyoteRequest.sessionCreateCommitted"));
> }
>
> - session = manager.createSession();
> + // Attempt to reuse session id if one was submitted in a cookie
> + // Do not reuse the session id if it is from a URL, to prevent
possible
> + // phishing attacks
> + if (isRequestedSessionIdFromCookie()) {
> + session = manager.createSession(getRequestedSessionId());
> + } else {
> + session = manager.createSession(null);
> + }
>
> // Creating a new session cookie based on that session
> if ((session != null) && (getContext() != null)
> Index:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Applicat
ionHttpRequest.java
> ===================================================================
> RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cor
e/ApplicationHttpRequest.java,v
> retrieving revision 1.24
> diff -u -r1.24 ApplicationHttpRequest.java
> ---
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Applicat
ionHttpRequest.java 15 Jan 2005 20:31:21 -0000 1.24
> +++
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Applicat
ionHttpRequest.java 7 Feb 2005 16:49:29 -0000
> @@ -529,13 +529,8 @@
> // Ignore
> }
> if (localSession == null && create) {
> - localSession =
context.getManager().createEmptySession();
> - localSession.setNew(true);
> - localSession.setValid(true);
> -
localSession.setCreationTime(System.currentTimeMillis());
> - localSession.setMaxInactiveInterval
> - (context.getManager().getMaxInactiveInterval());
> - localSession.setId(other.getId());
> + localSession =
> +
context.getManager().createSession(other.getId());
> }
> if (localSession != null) {
> localSession.access();
> Index:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/Manag
erBase.java
> ===================================================================
> RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ses
sion/ManagerBase.java,v
> retrieving revision 1.37
> diff -u -r1.37 ManagerBase.java
> ---
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/Manag
erBase.java 22 Nov 2004 14:50:23 -0000 1.37
> +++
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/Manag
erBase.java 7 Feb 2005 16:49:29 -0000
> @@ -727,15 +727,18 @@
> /**
> * Construct and return a new session object, based on the default
> * settings specified by this Manager's properties. The session
> - * id will be assigned by this method, and available via the getId()
> - * method of the returned session. If a new session cannot be
created
> - * for any reason, return <code>null</code>.
> - *
> + * id specified will be used as the session id.
> + * If a new session cannot be created for any reason, return
> + * <code>null</code>.
> + *
> + * @param sessionId The session id which should be used to create the
> + * new session; if <code>null</code>, a new session id will be
> + * generated
> * @exception IllegalStateException if a new session cannot be
> * instantiated for any reason
> */
> - public Session createSession() {
> -
> + public Session createSession(String sessionId) {
> +
> // Recycle or create a Session instance
> Session session = createEmptySession();
>
> @@ -744,15 +747,17 @@
> session.setValid(true);
> session.setCreationTime(System.currentTimeMillis());
> session.setMaxInactiveInterval(this.maxInactiveInterval);
> - String sessionId = generateSessionId();
> + if (sessionId == null) {
> + sessionId = generateSessionId();
> + }
> session.setId(sessionId);
> sessionCounter++;
>
> return (session);
>
> }
> -
> -
> +
> +
> /**
> * Get a session from the recycled ones or create a new empty one.
> * The PersistentManager manager does not need to create session data
> Index:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/Stand
ardManager.java
> ===================================================================
> RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ses
sion/StandardManager.java,v
> retrieving revision 1.27
> diff -u -r1.27 StandardManager.java
> ---
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/Stand
ardManager.java 22 Nov 2004 16:35:18 -0000 1.27
> +++
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/Stand
ardManager.java 7 Feb 2005 16:49:29 -0000
> @@ -278,7 +278,7 @@
> * @exception IllegalStateException if a new session cannot be
> * instantiated for any reason
> */
> - public Session createSession() {
> + public Session createSession(String sessionId) {
>
> if ((maxActiveSessions >= 0) &&
> (sessions.size() >= maxActiveSessions)) {
> @@ -287,7 +287,7 @@
> (sm.getString("standardManager.createSession.ise"));
> }
>
> - return (super.createSession());
> + return (super.createSession(sessionId));
>
> }
>
> Index:
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
r/session/DeltaManager.java
> ===================================================================
> RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catal
ina/cluster/session/DeltaManager.java,v
> retrieving revision 1.36
> diff -u -r1.36 DeltaManager.java
> ---
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
r/session/DeltaManager.java 22 Nov 2004 14:51:18 -0000 1.36
> +++
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
r/session/DeltaManager.java 7 Feb 2005 16:49:30 -0000
> @@ -235,8 +235,8 @@
> * @exception IllegalStateException if a new session cannot be
> * instantiated for any reason
> */
> - public Session createSession() {
> - return createSession(true);
> + public Session createSession(String sessionId) {
> + return createSession(sessionId, true);
> }
>
>
> @@ -247,7 +247,7 @@
> * @param distribute
> * @return
> */
> - public Session createSession(boolean distribute) {
> + public Session createSession(String sessionId, boolean distribute) {
>
> if ((maxActiveSessions >= 0) &&
> (sessions.size() >= maxActiveSessions)) {
> @@ -258,13 +258,16 @@
>
> // Recycle or create a Session instance
> DeltaSession session = getNewDeltaSession();
> - String sessionId = generateSessionId();
> -
> - synchronized (sessions) {
> - while (sessions.get(sessionId) != null) { // Guarantee uniqueness
> - duplicates++;
> + if (sessionId == null) {
> sessionId = generateSessionId();
> - }
> +
> + synchronized (sessions) {
> + while (sessions.get(sessionId) != null) { // Guarantee
uniqueness
> + duplicates++;
> + sessionId = generateSessionId();
> + }
> + }
> +
> }
>
> session.setNew(true);
> @@ -849,7 +852,8 @@
> if (log.isDebugEnabled())
> log.debug("Manager (" + name + ") received
session ("
> + msg.getSessionID() + ") created.");
> - DeltaSession session =
(DeltaSession)createSession(false);
> + DeltaSession session =
> +
(DeltaSession)createSession(msg.getSessionID(), false);
> // Q: Why inform all session listener a replicate
node?
> session.setId(msg.getSessionID());
> session.setNew(false);
>
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
Re: [PATCH] Re: StandardSession activate()/passivate() are broken
Posted by Jess Holle <je...@ptc.com>.
Also I notice that when PersistentManager is used that my
sessionDestroyed() method is called multiple times (twice actually)
whenever a session is being expired from store (i.e. upon removal of old
passivated session data).
I am patching (crudely) around this for now, but I thought I'd bring
this to everyone else's attention.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
[PATCH] Re: StandardSession activate()/passivate() are broken
Posted by Jess Holle <je...@ptc.com>.
Attached is a patch (against the latest 5.5.x source) that addresses
this issue.
--
Jess Holle
Jess Holle wrote:
> It appears that the activate() and passivate() routines of
> StandardSession are not functioning properly. [I've only tested
> 5.0.30, but 5.5.x seem to have identical erroneous code.]
>
> These methods /are /called, but do not fire appropriate
> HttpSessionEvent events. A comparison of these routines to tellNew()
> and expire() is rather telling.
>
> I plan to rework this code along the lines of tellNew() and expire()
> to get proper functionality
>
> --
> Jess Holle
StandardSession activate()/passivate() are broken
Posted by Jess Holle <je...@ptc.com>.
It appears that the activate() and passivate() routines of
StandardSession are not functioning properly. [I've only tested 5.0.30,
but 5.5.x seem to have identical erroneous code.]
These methods /are /called, but do not fire appropriate HttpSessionEvent
events. A comparison of these routines to tellNew() and expire() is
rather telling.
I plan to rework this code along the lines of tellNew() and expire() to
get proper functionality
--
Jess Holle
Re: [VOTE] Proposed API change to the Manager interface
Posted by Rainer Jung <to...@kippdata.de>.
I don't fully agree: we use F5 too, but:
1) I know many commercial sites (in germany), which do not use Cookies
(privacy reasons).
2) IP based stickyness does not work very well. In many scenarios you
will only be able to correctly route "most" of your clients. If you rely
on exact routing, IP-based will not suffice.
3) These are the reasons why I assume, that all balancers will support
routing decisions based on the jsessionid in the URI. So they already
have to support extracting routing information from the session id string.
So using the same jessionid string in the standard cookie will work in
most (all ?) situations / for most products.
Example: mod_jk does it like that:
/* Retrieve session id from the cookie or the parameter
*/
static char *get_sessionid(jk_ws_service_t *s)
{
char *val;
val = get_path_param(s, JK_PATH_SESSION_IDENTIFIER);
if (!val) {
val = get_cookie(s, JK_SESSION_IDENTIFIER);
}
return val;
}
and after that it does no longer matter, where the info comes from.
On the other hand: what's wrong about embedding the jmvRoute as a suffix
in the session id?
Rainer
Filip Hanik - Dev wrote:
> its not at all that complicated.
> This is how a big5 load balancer does it.
>
> A) it sets a cookie, and based on the cookie it load balances.
> B) if a cookie is not supported, it does a calculation based on the IP address, and stays sticky that way.
>
> No need to exchange any info in this scenario and very straight forward, and never goes wrong. The only time it goes wrong is for
> AOL users who can change gateway between HTTP and HTTPS
>
> Filip
>
> ----- Original Message -----
> From: "Rainer Jung" <to...@kippdata.de>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Tuesday, February 08, 2005 10:39 AM
> Subject: Re: [VOTE] Proposed API change to the Manager interface
>
>
> I'm afraid that change will have negative implications: The jvmRoute is
> used to enable routing decisions by balancing components. All these
> components usually support routing either COOKIE-based or URI-based.
>
> In the URI-based case it is more or less the only clean way to include
> the jvmRoute in the jsessionid, since the jsessionid is standardized, so
> all common balancing products know how to handle it.
>
> But then it is pretty common to assume the jsessionid and the cookie to
> have the same value. They are sort of two different ways to transport
> the same session information. So most balancer providers implement the
> routing decision features the same way, independant of the source of the
> session string.
>
> Splitting the jvmRoute from the session id in the cookie case will most
> likely make the situation for all implementers of balancers more complex
> and instable (e.g.: mod_jk).
>
> Of course we would all profit, if some JSR would standardize the way,
> distributed applications exchange routing information with the
> clients/balancers. As long as that's not the case it is very likely,
> that jvmRoute as a suffix of the session id has much better support from
> balancer providers.
>
> Rainer
>
> Filip Hanik - Dev wrote:
>
>
>>Remy Wrote:
>>
>>
>>>BTW, wouldn't it be better to set the route as a separate cookie, which
>>>would be a lot cleaner ? Was this ever considered ?
>>
>>
>>That would have been the obvious solution, the jvmRoute must have come from a dark basement somewhere :)
>>
>>Whatever the change you decide on, I'll be happy to implement it and test it for the cluster stuff
>>
>>Filip
>>
>>----- Original Message -----
>>From: "Remy Maucherat" <re...@apache.org>
>>To: "Tomcat Developers List" <to...@jakarta.apache.org>
>>Sent: Monday, February 07, 2005 11:34 AM
>>Subject: Re: [VOTE] Proposed API change to the Manager interface
>>
>>
>>
>>
>>>@@ -744,15 +747,17 @@
>>> session.setValid(true);
>>> session.setCreationTime(System.currentTimeMillis());
>>> session.setMaxInactiveInterval(this.maxInactiveInterval);
>>>- String sessionId = generateSessionId();
>>>+ if (sessionId == null) {
>>>+ sessionId = generateSessionId();
>>>+ }
>>
>>
>>I just noticed my patch needs something for jvmRoute handling
>>(basically, the session id which is recieved must be edited for the
>>right route). I'll fix that.
>>
>>BTW, wouldn't it be better to set the route as a separate cookie, which
>>would be a lot cleaner ? Was this ever considered ?
>>
>>Rémy
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Remy Maucherat <re...@apache.org>.
Rainer Jung wrote:
> I have the impression you fixed the jvmRoute in the new Session(-Id) in
> ManagerBase, but not in DeltaManager? Even when the context is
> distributable one might prefer to stick the session to the node where it
> now originates.
You mean the commented out code ? It would need to be cut & pasted to
the delta manager. I had it originally in both managers.
> Furthermore: I did not really understand the use case of emptySessionPath,
The use case is when something abuses cross context, such as a portlet
container.
> but want to indicate 2 problematic areas:
>
> 1) If the cookie contains an expired session(-id) then you would allow a
> new session to be started with the old id. That is not a naive security
> problem, because the session is empty, so authentication has to be done
> again etc.
It is still tied to the same user, and as you said the object will be
brand new. I don't understand why it is a problem.
> But there is a more complex threat: Security of webapps relies on the
> fact, that session ids are not easily guessable. Once you move into a
> situation where a user might use the same session id for a very long time
> (in fact different sessions) the id will loose it's security. Normally
> it's hard to find out the id of a user session while the session is still
> active. And the user can at every time end his session. If he is going to
> use the same Id for many sessions you have a much better chance to get
> knowledge about the id between sessions and then to just wait for a new
> session to begin.
That's what I thought at first, but I actually don't think it's a problem.
There was nothing preventing from using a session for a very long time
before, depending on the server settings. With the session space (128
bits) we are using, it does not matter, the ids will be unguessable as
soon as the random number generator is properly seeded.
And if you really care about security, use SSL ;)
> 2) There might be problems by putting an arbitrary string coming from an
> uncontrolled Cookie and using it as a session id inside tomcat. I don't
> know, if there is a way related to cross site scrpting or injection of
> malicious code for cookies (of course I know, that there is no scripting
> inside Cookies, but atackers are very ingenious nowadays). At least one
> should check the string for formal correctness (e.g. containing only
> letters and numbers or something similar).
Besides the cross scripting used with a URL, I am not aware of any valid
cookie which would cause problems. Invalid cookies will not be parsed.
A global session id list is needed to verify the submitted id exists
(across all contexts). I don't think such a list is worth it, though.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Rainer Jung <to...@kippdata.de>.
I have the impression you fixed the jvmRoute in the new Session(-Id) in
ManagerBase, but not in DeltaManager? Even when the context is
distributable one might prefer to stick the session to the node where it
now originates.
Furthermore: I did not really understand the use case of emptySessionPath,
but want to indicate 2 problematic areas:
1) If the cookie contains an expired session(-id) then you would allow a
new session to be started with the old id. That is not a naive security
problem, because the session is empty, so authentication has to be done
again etc.
But there is a more complex threat: Security of webapps relies on the
fact, that session ids are not easily guessable. Once you move into a
situation where a user might use the same session id for a very long time
(in fact different sessions) the id will loose it's security. Normally
it's hard to find out the id of a user session while the session is still
active. And the user can at every time end his session. If he is going to
use the same Id for many sessions you have a much better chance to get
knowledge about the id between sessions and then to just wait for a new
session to begin.
2) There might be problems by putting an arbitrary string coming from an
uncontrolled Cookie and using it as a session id inside tomcat. I don't
know, if there is a way related to cross site scrpting or injection of
malicious code for cookies (of course I know, that there is no scripting
inside Cookies, but atackers are very ingenious nowadays). At least one
should check the string for formal correctness (e.g. containing only
letters and numbers or something similar).
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Rainer Jung <to...@kippdata.de>.
Upgrading mod_jk would be possible (not too complicated), but I'm afraid
we are going to break other products we don't control the way we do with
mod_jk.
mod_jk is a good example to see, why it's not unlikely that changes
would be needed for other balancers.
Rainer
Remy Maucherat wrote:
> Filip Hanik - Dev wrote:
>
>> its not at all that complicated.
>> This is how a big5 load balancer does it.
>>
>> A) it sets a cookie, and based on the cookie it load balances.
>> B) if a cookie is not supported, it does a calculation based on the IP
>> address, and stays sticky that way.
>>
>> No need to exchange any info in this scenario and very straight
>> forward, and never goes wrong. The only time it goes wrong is for
>> AOL users who can change gateway between HTTP and HTTPS
>
>
> I don't think it's that complicated either, but it would still require
> an upgrade of mod_jk to work, so it's probably not an option :(
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev wrote:
> its not at all that complicated.
> This is how a big5 load balancer does it.
>
> A) it sets a cookie, and based on the cookie it load balances.
> B) if a cookie is not supported, it does a calculation based on the IP address, and stays sticky that way.
>
> No need to exchange any info in this scenario and very straight forward, and never goes wrong. The only time it goes wrong is for
> AOL users who can change gateway between HTTP and HTTPS
I don't think it's that complicated either, but it would still require
an upgrade of mod_jk to work, so it's probably not an option :(
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Filip Hanik - Dev <de...@hanik.com>.
its not at all that complicated.
This is how a big5 load balancer does it.
A) it sets a cookie, and based on the cookie it load balances.
B) if a cookie is not supported, it does a calculation based on the IP address, and stays sticky that way.
No need to exchange any info in this scenario and very straight forward, and never goes wrong. The only time it goes wrong is for
AOL users who can change gateway between HTTP and HTTPS
Filip
----- Original Message -----
From: "Rainer Jung" <to...@kippdata.de>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Tuesday, February 08, 2005 10:39 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
I'm afraid that change will have negative implications: The jvmRoute is
used to enable routing decisions by balancing components. All these
components usually support routing either COOKIE-based or URI-based.
In the URI-based case it is more or less the only clean way to include
the jvmRoute in the jsessionid, since the jsessionid is standardized, so
all common balancing products know how to handle it.
But then it is pretty common to assume the jsessionid and the cookie to
have the same value. They are sort of two different ways to transport
the same session information. So most balancer providers implement the
routing decision features the same way, independant of the source of the
session string.
Splitting the jvmRoute from the session id in the cookie case will most
likely make the situation for all implementers of balancers more complex
and instable (e.g.: mod_jk).
Of course we would all profit, if some JSR would standardize the way,
distributed applications exchange routing information with the
clients/balancers. As long as that's not the case it is very likely,
that jvmRoute as a suffix of the session id has much better support from
balancer providers.
Rainer
Filip Hanik - Dev wrote:
> Remy Wrote:
>
>>BTW, wouldn't it be better to set the route as a separate cookie, which
>>would be a lot cleaner ? Was this ever considered ?
>
>
> That would have been the obvious solution, the jvmRoute must have come from a dark basement somewhere :)
>
> Whatever the change you decide on, I'll be happy to implement it and test it for the cluster stuff
>
> Filip
>
> ----- Original Message -----
> From: "Remy Maucherat" <re...@apache.org>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Monday, February 07, 2005 11:34 AM
> Subject: Re: [VOTE] Proposed API change to the Manager interface
>
>
>
>>@@ -744,15 +747,17 @@
>> session.setValid(true);
>> session.setCreationTime(System.currentTimeMillis());
>> session.setMaxInactiveInterval(this.maxInactiveInterval);
>>- String sessionId = generateSessionId();
>>+ if (sessionId == null) {
>>+ sessionId = generateSessionId();
>>+ }
>
>
> I just noticed my patch needs something for jvmRoute handling
> (basically, the session id which is recieved must be edited for the
> right route). I'll fix that.
>
> BTW, wouldn't it be better to set the route as a separate cookie, which
> would be a lot cleaner ? Was this ever considered ?
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Rainer Jung <to...@kippdata.de>.
I'm afraid that change will have negative implications: The jvmRoute is
used to enable routing decisions by balancing components. All these
components usually support routing either COOKIE-based or URI-based.
In the URI-based case it is more or less the only clean way to include
the jvmRoute in the jsessionid, since the jsessionid is standardized, so
all common balancing products know how to handle it.
But then it is pretty common to assume the jsessionid and the cookie to
have the same value. They are sort of two different ways to transport
the same session information. So most balancer providers implement the
routing decision features the same way, independant of the source of the
session string.
Splitting the jvmRoute from the session id in the cookie case will most
likely make the situation for all implementers of balancers more complex
and instable (e.g.: mod_jk).
Of course we would all profit, if some JSR would standardize the way,
distributed applications exchange routing information with the
clients/balancers. As long as that's not the case it is very likely,
that jvmRoute as a suffix of the session id has much better support from
balancer providers.
Rainer
Filip Hanik - Dev wrote:
> Remy Wrote:
>
>>BTW, wouldn't it be better to set the route as a separate cookie, which
>>would be a lot cleaner ? Was this ever considered ?
>
>
> That would have been the obvious solution, the jvmRoute must have come from a dark basement somewhere :)
>
> Whatever the change you decide on, I'll be happy to implement it and test it for the cluster stuff
>
> Filip
>
> ----- Original Message -----
> From: "Remy Maucherat" <re...@apache.org>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Monday, February 07, 2005 11:34 AM
> Subject: Re: [VOTE] Proposed API change to the Manager interface
>
>
>
>>@@ -744,15 +747,17 @@
>> session.setValid(true);
>> session.setCreationTime(System.currentTimeMillis());
>> session.setMaxInactiveInterval(this.maxInactiveInterval);
>>- String sessionId = generateSessionId();
>>+ if (sessionId == null) {
>>+ sessionId = generateSessionId();
>>+ }
>
>
> I just noticed my patch needs something for jvmRoute handling
> (basically, the session id which is recieved must be edited for the
> right route). I'll fix that.
>
> BTW, wouldn't it be better to set the route as a separate cookie, which
> would be a lot cleaner ? Was this ever considered ?
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Filip Hanik - Dev <de...@hanik.com>.
Remy Wrote:
>BTW, wouldn't it be better to set the route as a separate cookie, which
>would be a lot cleaner ? Was this ever considered ?
That would have been the obvious solution, the jvmRoute must have come from a dark basement somewhere :)
Whatever the change you decide on, I'll be happy to implement it and test it for the cluster stuff
Filip
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Monday, February 07, 2005 11:34 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
> @@ -744,15 +747,17 @@
> session.setValid(true);
> session.setCreationTime(System.currentTimeMillis());
> session.setMaxInactiveInterval(this.maxInactiveInterval);
> - String sessionId = generateSessionId();
> + if (sessionId == null) {
> + sessionId = generateSessionId();
> + }
I just noticed my patch needs something for jvmRoute handling
(basically, the session id which is recieved must be edited for the
right route). I'll fix that.
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Remy Maucherat <re...@apache.org>.
> @@ -744,15 +747,17 @@
> session.setValid(true);
> session.setCreationTime(System.currentTimeMillis());
> session.setMaxInactiveInterval(this.maxInactiveInterval);
> - String sessionId = generateSessionId();
> + if (sessionId == null) {
> + sessionId = generateSessionId();
> + }
I just noticed my patch needs something for jvmRoute handling
(basically, the session id which is recieved must be edited for the
right route). I'll fix that.
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Remy Maucherat <re...@apache.org>.
Tim Funk wrote:
> If I read this correctly (big if), the solution could be a security
> problem. If I were a phisher, I might be able to send you an email with
> a link to that would redirect you to a tomcat server with the new
> configuration in question with a special id. If the user were to perform
> other actions of a confidential nature, the attacker could swoop in and
> impersonate that session.
>
> The phisher could easily be notified that the special session id was
> used and have a farm of wamr bodies ready to attack.
My patch at the moment is attached to the email for more detailed
review. It no longer reuses session ids submitted in the URL (very good
catch).
Rémy
Re: [VOTE] Proposed API change to the Manager interface
Posted by Tim Funk <fu...@joedog.org>.
If I read this correctly (big if), the solution could be a security problem.
If I were a phisher, I might be able to send you an email with a link to that
would redirect you to a tomcat server with the new configuration in question
with a special id. If the user were to perform other actions of a
confidential nature, the attacker could swoop in and impersonate that session.
The phisher could easily be notified that the special session id was used and
have a farm of wamr bodies ready to attack.
-Tim
Remy Maucherat wrote:
> To address this, I propose simply reusing any session id presented by
> the client. As an option, this could be done only if emptySessionPath is
> true. I have tested it, and it works very well, addressing the problem
> with emptySessionPath="true". I could not think of any security issue
> this would cause (if the client submits a bogus insecure id, then he'll
> be the one being impacted), since the undelying session objects would be
> created and handled as usual. In "normal" more (emptySessionPath set to
> false), this would save costly session id generation.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
> Right, that's what I tried at first. However, session tracking would
> break in mysterious ways whenever emptySessionPath is used if we did
> that. So I considered it was better to remove the method to signal some
> change is needed.
>
> That was my idea, but I'm ok with adding back the method in Manager (and
> ManagerBase) as deprecated if you still think it's better.
Yeah, I still think it's better. Marginally better and obviously not perfect,
but still better. If you want to add a comment to the old createSession()
version that session tracking might break in mysterious ways if
emptySessionPath is used, that's fine too. The important thing is we'll
deprecate it and maintain backwards compatibility for at least a few releases /
few months, then we can remove it altogether. (And I'll be +1 for that, always
preferring a cleaner interface myself)
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Proposed API change to the Manager interface
Posted by Remy Maucherat <re...@apache.org>.
Yoav Shapira wrote:
> Hi,
>
>>However, the problem is that I need to modify a method in the top level
>>Manager interface :(
>>
>>public Session createSession()
>>must become:
>>public Session createSession(String sessionId)
>>(if sessionId is null, a new session id will be generated)
>>
>>As the createSession() will no longer be used anywhere, and calling it
>>in old managers would create bad behavior, I propose removing it rather
>>than deprecating it.
>
> Why can't createSession() simply call createSession(null) ? That way we
> could deprecate it and preserve backwards compatibility, at least for a
> little while. I'm uneasy about simply breaking a major interface, one
> that's customized often by users.
Right, that's what I tried at first. However, session tracking would
break in mysterious ways whenever emptySessionPath is used if we did
that. So I considered it was better to remove the method to signal some
change is needed.
That was my idea, but I'm ok with adding back the method in Manager (and
ManagerBase) as deprecated if you still think it's better.
> Other than that, and given Tim's catch and your fix, I'm OK with this.
Ok.
The adjustment I mentioned in my last email to handle jvmRoute might not
be needed.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: [VOTE] Proposed API change to the Manager interface
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
>However, the problem is that I need to modify a method in the top level
>Manager interface :(
>
>public Session createSession()
>must become:
>public Session createSession(String sessionId)
>(if sessionId is null, a new session id will be generated)
>
>As the createSession() will no longer be used anywhere, and calling it
>in old managers would create bad behavior, I propose removing it rather
>than deprecating it.
Why can't createSession() simply call createSession(null) ? That way we
could deprecate it and preserve backwards compatibility, at least for a
little while. I'm uneasy about simply breaking a major interface, one
that's customized often by users.
Other than that, and given Tim's catch and your fix, I'm OK with this.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org