FAQ

[Tomcat-users] Session Invalidate not working on HTTPS ( Tomcat 6.0.29 )

Andrea Corti
Nov 29, 2010 at 2:38 pm
Hi,
in order to avoid session fixation in the login phase of our application
we have to invalidate the session.
But we found the issue reported in the following bug (marked as solved)
related to Tomcat &.0.28:

https://issues.apache.org/bugzilla/show_bug.cgi?id=49598


I'm using tomcat 6.0.29 (under win XP and linux CentOS) where the issue is
marked as resolved but i can replicate it every time.

If it can be helpful i'm in a servlet in an https connection (without any
framework or similar).
I discovered that on http call the session is correctly renewed but on https
it is not.

Does there exist any way to avoid such issue?

I made the mistake to post it on bugzilla before posting here, sorry.

Follows an extract form a test servlet:
" HttpSession s = req.getSession();
if (s==null) {
System.out.println(mt+":Session is null");
} else {
System.out.println(mt+":Session id="+s.getId()+"\t
New="+s.isNew());
}
System.out.println("pre- invalidate");
s.invalidate();
System.out.println("post- invalidate: id="+s.getId());
s = req.getSession(true);
System.out.println("post- get new: id="+s.getId());
"



Thanks very much .

BR,
Andrea
reply

Search Discussions

9 responses

  • Christopher Schultz at Nov 29, 2010 at 4:57 pm
    Andrea,
    On 11/29/2010 9:37 AM, Andrea Corti wrote:
    In order to avoid session fixation in the login phase of our application
    we have to invalidate the session.
    As you may have noted, Tomcat has implemented this behavior and you
    shouldn't have to worry about it.
    But we found the issue reported in the following bug (marked as solved)
    related to Tomcat &.0.28:

    https://issues.apache.org/bugzilla/show_bug.cgi?id=49598
    That would be the one.
    I'm using tomcat 6.0.29 (under win XP and linux CentOS) where the issue is
    marked as resolved but i can replicate it every time.
    Okay, how are you replicating it and what are your results?
    If it can be helpful i'm in a servlet in an https connection (without any
    framework or similar).
    I discovered that on http call the session is correctly renewed but on https
    it is not.
    Interesting.
    Follows an extract form a test servlet:
    HttpSession s = req.getSession();
    if (s==null) {
    System.out.println(mt+":Session is null");
    } else {
    System.out.println(mt+":Session id="+s.getId()+"\t
    New="+s.isNew());
    }
    System.out.println("pre- invalidate");
    s.invalidate();
    System.out.println("post- invalidate: id="+s.getId());
    s = req.getSession(true);
    System.out.println("post- get new: id="+s.getId());
    Okay, what does the above servlet print when you access it via HTTP, and
    then access it via HTTPS?

    - -chris
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Andrea Corti at Nov 30, 2010 at 9:58 am
    2010/11/29 Christopher Schultz <chris@christopherschultz.net>
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Andrea,
    On 11/29/2010 9:37 AM, Andrea Corti wrote:
    In order to avoid session fixation in the login phase of our application
    we have to invalidate the session.
    As you may have noted, Tomcat has implemented this behavior and you
    shouldn't have to worry about it.
    But we found the issue reported in the following bug (marked as solved)
    related to Tomcat &.0.28:

    https://issues.apache.org/bugzilla/show_bug.cgi?id=49598
    That would be the one.
    I'm using tomcat 6.0.29 (under win XP and linux CentOS) where the issue is
    marked as resolved but i can replicate it every time.
    Okay, how are you replicating it and what are your results?
    If it can be helpful i'm in a servlet in an https connection (without any
    framework or similar).
    I discovered that on http call the session is correctly renewed but on https
    it is not.
    Interesting.
    Follows an extract form a test servlet:
    HttpSession s = req.getSession();
    if (s==null) {
    System.out.println(mt+":Session is null");
    } else {
    System.out.println(mt+":Session id="+s.getId()+"\t
    New="+s.isNew());
    }
    System.out.println("pre- invalidate");
    s.invalidate();
    System.out.println("post- invalidate: id="+s.getId());
    s = req.getSession(true);
    System.out.println("post- get new: id="+s.getId());
    Okay, what does the above servlet print when you access it via HTTP, and
    then access it via HTTPS?
    HTTP Output:
    POST:Session id=F5FAF6115F7BA37ECDA22299C9B3B4BC New=true
    pre- invalidate
    sessionDestroyed [F5FAF6115F7BA37ECDA22299C9B3B4BC] <-- this log is printed
    by a HttpSessionListener
    post- invalidate: id=F5FAF6115F7BA37ECDA22299C9B3B4BC
    sessionCreated [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed by
    a HttpSessionListener
    post- get new: id=36BA1CCC7AEC8A9808027D57B6A5A52A

    We can notice that the session id after the GetSession(true) is different
    from the previous one.

    HTTPS Output:
    POST:Session id=36BA1CCC7AEC8A9808027D57B6A5A52A New=false
    pre- invalidate
    sessionDestroyed [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed
    by a HttpSessionListener
    post- invalidate: id=36BA1CCC7AEC8A9808027D57B6A5A52A
    sessionCreated [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed by
    a HttpSessionListener
    post- get new: id=36BA1CCC7AEC8A9808027D57B6A5A52A

    In this case the session id is always the same!

    Can someone suggest a way to avoid such issue? I saw that between release 28
    and 29 the following class has been changed but i'm not able to debug it.
    java\org\apache\catalina\connector\Response.java (method
    addSessionCookieInternal)

    Thanks.

    Andrea











    - -chris
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.10 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iEYEARECAAYFAkzz210ACgkQ9CaO5/Lv0PA0gACeOXNvdinscHW4m2zogNdFrYA3
    qbcAnjrtZAJyjJIh/Hhq77B1ClkVnLdG
    =maAw
    -----END PGP SIGNATURE-----

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Konstantin Kolinko at Nov 30, 2010 at 1:56 pm

    Follows an extract form a test servlet:
    HttpSession s = req.getSession();
    if (s==null) {
    System.out.println(mt+":Session is null");
    } else {
    System.out.println(mt+":Session id="+s.getId()+"\t
    New="+s.isNew());
    }
    System.out.println("pre- invalidate");
    s.invalidate();
    System.out.println("post- invalidate: id="+s.getId());
    s = req.getSession(true);
    System.out.println("post- get new: id="+s.getId());
    Okay, what does the above servlet print when you access it via HTTP, and
    then access it via HTTPS?
    HTTP Output:
    POST:Session id=F5FAF6115F7BA37ECDA22299C9B3B4BC     New=true
    pre- invalidate
    sessionDestroyed [F5FAF6115F7BA37ECDA22299C9B3B4BC] <-- this log is printed
    by a HttpSessionListener
    post- invalidate: id=F5FAF6115F7BA37ECDA22299C9B3B4BC
    sessionCreated [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed by
    a HttpSessionListener
    post- get new: id=36BA1CCC7AEC8A9808027D57B6A5A52A

    We can notice that the session id after the GetSession(true) is different
    from the previous one.

    HTTPS Output:
    POST:Session id=36BA1CCC7AEC8A9808027D57B6A5A52A     New=false
    pre- invalidate
    sessionDestroyed [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed
    by a HttpSessionListener
    post- invalidate: id=36BA1CCC7AEC8A9808027D57B6A5A52A
    sessionCreated [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed by
    a HttpSessionListener
    post- get new: id=36BA1CCC7AEC8A9808027D57B6A5A52A

    In this case the session id is always the same!
    Do you, by a chance, have emptySessionPath=true on your Connector?
    I saw that between release 28
    and 29 the following class has been changed but i'm not able to debug it.
    java\org\apache\catalina\connector\Response.java (method
    addSessionCookieInternal)
    http://wiki.apache.org/tomcat/FAQ/Developing

    Best regards,
    Konstantin Kolinko

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Andrea Corti at Nov 30, 2010 at 2:17 pm
    Yes, I have emptySessionPath=true in connectors; is this the issue?

    Thanks for the link, now i'm trying to debug in order to find some more
    details for you experts.

    Thanks.

    2010/11/30 Konstantin Kolinko <knst.kolinko@gmail.com>
    Follows an extract form a test servlet:
    HttpSession s = req.getSession();
    if (s==null) {
    System.out.println(mt+":Session is null");
    } else {
    System.out.println(mt+":Session id="+s.getId()+"\t
    New="+s.isNew());
    }
    System.out.println("pre- invalidate");
    s.invalidate();
    System.out.println("post- invalidate: id="+s.getId());
    s = req.getSession(true);
    System.out.println("post- get new: id="+s.getId());
    Okay, what does the above servlet print when you access it via HTTP, and
    then access it via HTTPS?
    HTTP Output:
    POST:Session id=F5FAF6115F7BA37ECDA22299C9B3B4BC New=true
    pre- invalidate
    sessionDestroyed [F5FAF6115F7BA37ECDA22299C9B3B4BC] <-- this log is printed
    by a HttpSessionListener
    post- invalidate: id=F5FAF6115F7BA37ECDA22299C9B3B4BC
    sessionCreated [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed by
    a HttpSessionListener
    post- get new: id=36BA1CCC7AEC8A9808027D57B6A5A52A

    We can notice that the session id after the GetSession(true) is different
    from the previous one.

    HTTPS Output:
    POST:Session id=36BA1CCC7AEC8A9808027D57B6A5A52A New=false
    pre- invalidate
    sessionDestroyed [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed
    by a HttpSessionListener
    post- invalidate: id=36BA1CCC7AEC8A9808027D57B6A5A52A
    sessionCreated [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed by
    a HttpSessionListener
    post- get new: id=36BA1CCC7AEC8A9808027D57B6A5A52A

    In this case the session id is always the same!
    Do you, by a chance, have emptySessionPath=true on your Connector?
    I saw that between release 28
    and 29 the following class has been changed but i'm not able to debug it.
    java\org\apache\catalina\connector\Response.java (method
    addSessionCookieInternal)
    http://wiki.apache.org/tomcat/FAQ/Developing

    Best regards,
    Konstantin Kolinko

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Konstantin Kolinko at Nov 30, 2010 at 2:52 pm

    2010/11/30 Andrea Corti <ilgrandemazinger@gmail.com>:
    Yes, I have emptySessionPath=true  in connectors; is this the issue?
    In your logs, you have "sessionCreated" message, i.e. a session was
    created and thus the listener was notified, but the ID was reused.

    You can put a breakpoint in your listener to see where that comes from.

    -> "manager.createSession(getRequestedSessionId());" call in
    o.a.c.connector.Request.doGetSession(..)

    Thanks for the link, now i'm trying to debug in order to find some more
    details for you experts.

    Thanks.

    2010/11/30 Konstantin Kolinko <knst.kolinko@gmail.com>
    Follows an extract form a test servlet:
    HttpSession s = req.getSession();
    if (s==null) {
    System.out.println(mt+":Session is null");
    } else {
    System.out.println(mt+":Session id="+s.getId()+"\t
    New="+s.isNew());
    }
    System.out.println("pre- invalidate");
    s.invalidate();
    System.out.println("post- invalidate: id="+s.getId());
    s = req.getSession(true);
    System.out.println("post- get new: id="+s.getId());
    Okay, what does the above servlet print when you access it via HTTP, and
    then access it via HTTPS?
    HTTP Output:
    POST:Session id=F5FAF6115F7BA37ECDA22299C9B3B4BC     New=true
    pre- invalidate
    sessionDestroyed [F5FAF6115F7BA37ECDA22299C9B3B4BC] <-- this log is printed
    by a HttpSessionListener
    post- invalidate: id=F5FAF6115F7BA37ECDA22299C9B3B4BC
    sessionCreated [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed by
    a HttpSessionListener
    post- get new: id=36BA1CCC7AEC8A9808027D57B6A5A52A

    We can notice that the session id after the GetSession(true) is different
    from the previous one.

    HTTPS Output:
    POST:Session id=36BA1CCC7AEC8A9808027D57B6A5A52A     New=false
    pre- invalidate
    sessionDestroyed [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed
    by a HttpSessionListener
    post- invalidate: id=36BA1CCC7AEC8A9808027D57B6A5A52A
    sessionCreated [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed by
    a HttpSessionListener
    post- get new: id=36BA1CCC7AEC8A9808027D57B6A5A52A

    In this case the session id is always the same!
    Do you, by a chance, have emptySessionPath=true on your Connector?
    I saw that between release 28
    and 29 the following class has been changed but i'm not able to debug it.
    java\org\apache\catalina\connector\Response.java (method
    addSessionCookieInternal)
    http://wiki.apache.org/tomcat/FAQ/Developing

    Best regards,
    Konstantin Kolinko
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Andrea Corti at Nov 30, 2010 at 2:53 pm
    Hi, i discovered that (perhaps) the problem raise in the following rows in
    the Request class:

    // 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 (connector.getEmptySessionPath()
    && isRequestedSessionIdFromCookie()) {
    session = manager.createSession(getRequestedSessionId());
    } else {
    session = manager.createSession(null);
    }

    I have an empty sessionpath =true and the sessionid is stored in the
    jsessionid cookie so the code goes in the first if reusing the sessionid.
    I don't understand very well the comment in the code where it says "Attempt
    to reuse session id if one was submitted in a cookie"; is there any reason
    for this?
    Is it correct to comment this if statement in order to always call the
    createSession(null) or is there another way in order to workaround this?

    Thanks in advance.

    Andrea



    2010/11/30 Andrea Corti <ilgrandemazinger@gmail.com>
    Yes, I have emptySessionPath=true in connectors; is this the issue?

    Thanks for the link, now i'm trying to debug in order to find some more
    details for you experts.

    Thanks.

    2010/11/30 Konstantin Kolinko <knst.kolinko@gmail.com>
    Follows an extract form a test servlet:
    HttpSession s = req.getSession();
    if (s==null) {
    System.out.println(mt+":Session is null");
    } else {
    System.out.println(mt+":Session id="+s.getId()+"\t
    New="+s.isNew());
    }
    System.out.println("pre- invalidate");
    s.invalidate();
    System.out.println("post- invalidate: id="+s.getId());
    s = req.getSession(true);
    System.out.println("post- get new: id="+s.getId());
    Okay, what does the above servlet print when you access it via HTTP,
    and
    then access it via HTTPS?
    HTTP Output:
    POST:Session id=F5FAF6115F7BA37ECDA22299C9B3B4BC New=true
    pre- invalidate
    sessionDestroyed [F5FAF6115F7BA37ECDA22299C9B3B4BC] <-- this log is printed
    by a HttpSessionListener
    post- invalidate: id=F5FAF6115F7BA37ECDA22299C9B3B4BC
    sessionCreated [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is
    printed by
    a HttpSessionListener
    post- get new: id=36BA1CCC7AEC8A9808027D57B6A5A52A

    We can notice that the session id after the GetSession(true) is different
    from the previous one.

    HTTPS Output:
    POST:Session id=36BA1CCC7AEC8A9808027D57B6A5A52A New=false
    pre- invalidate
    sessionDestroyed [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is printed
    by a HttpSessionListener
    post- invalidate: id=36BA1CCC7AEC8A9808027D57B6A5A52A
    sessionCreated [36BA1CCC7AEC8A9808027D57B6A5A52A] <-- this log is
    printed by
    a HttpSessionListener
    post- get new: id=36BA1CCC7AEC8A9808027D57B6A5A52A

    In this case the session id is always the same!
    Do you, by a chance, have emptySessionPath=true on your Connector?
    I saw that between release 28
    and 29 the following class has been changed but i'm not able to debug it.
    java\org\apache\catalina\connector\Response.java (method
    addSessionCookieInternal)
    http://wiki.apache.org/tomcat/FAQ/Developing

    Best regards,
    Konstantin Kolinko

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Konstantin Kolinko at Nov 30, 2010 at 3:04 pm

    2010/11/30 Andrea Corti <ilgrandemazinger@gmail.com>:
    Hi, i discovered that (perhaps) the problem raise in the following rows in
    the Request class:

    // 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 (connector.getEmptySessionPath()
    && isRequestedSessionIdFromCookie()) {
    session = manager.createSession(getRequestedSessionId());
    } else {
    session = manager.createSession(null);
    }

    I have an empty sessionpath =true and the sessionid is stored in the
    jsessionid cookie so the code goes in the first if reusing the sessionid.
    I don't understand very well the comment in the code where it says "Attempt
    to reuse session id if one was submitted in a cookie"; is there any reason
    for this?
    Is it correct to comment this if statement in order to always call the
    createSession(null) or is there another way in order to workaround this?

    Thanks in advance.
    That will mean that every web application will use its unique value of
    sessionid. Thus you can never share sessionid between them.

    Effectively, that is not far away from just setting emptySessionPath="false".

    http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#Common_Attributes

    Best regards,
    Konstantin Kolinko

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Christopher Schultz at Nov 30, 2010 at 9:01 pm
    Konstantin,
    On 11/30/2010 10:03 AM, Konstantin Kolinko wrote:
    That will mean that every web application will use its unique value of
    sessionid. Thus you can never share sessionid between them.
    So it's a feature, not a bug :)

    Andrea, if the webapp changes the session id, it may break other
    applications that were relying on the session id /not/ to change. This
    only happens when "emptySessionPath" is set to true, which is usually
    only done when sessions are being shared across webapps.

    Konstantin, can you confirm that behavior is different if you are using
    single sign-on?

    - -chris
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Konstantin Kolinko at Nov 30, 2010 at 9:17 pm

    2010/12/1 Christopher Schultz <chris@christopherschultz.net>:
    Konstantin, can you confirm that behavior is different if you are using
    single sign-on?
    The single sign on is a separate cookie with its own life. The
    sessions live independently and have their own IDs.

    See o.a.c.authenticator.SingleSignOn

    Best regards,
    Konstantin Kolinko

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org

Related Discussions

Discussion Navigation
viewthread | post