Shiro
  1. Shiro
  2. SHIRO-351

Shiro Native Session implementation cannot extract JSESSIONID From URL if JSESSIONID is URL parameter (not HTTP parameter)

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.0
    • Fix Version/s: 1.2.2, 1.3.0
    • Component/s: Web
    • Labels:
      None
    • Environment:
      N/A

      Description

      The background for this issue is here:

      http://shiro-user.582556.n2.nabble.com/Shiro-Native-Sessions-quot-JSESSIONID-quot-or-quot-JSESSIONID-quot-td7367217.html

      In summary the issue is that Shiro supports extracting JSESSIONID from urls of this format:

      http://www.mycompany.com/myResource?JSESSIONID=ABCDEF

      but not of this format (this URL format is generated by HTTPServletResponse encodeURL method and is Servlet specification 2.5 compliant):

      http://www.mycompany.com/myResource;JSESSIONID=ABCDEF

      Shiro should be able to support both URL formats.

        Activity

        Hide
        Les Hazlewood added a comment -

        Fixed in 1.2.x branch (for the upcoming 1.2.2 release) and in trunk.

        This fix however does NOT support custom sessionId names - it only works with JSESSIONID. The problem is that the URL Rewriting logic in the ShiroHttpServletResponse does not have direct access to the SessionManager implementation to consult for the sessionIdName property. This requires a much deeper fix that should be implemented, but at a later date (probably 2.0).

        Show
        Les Hazlewood added a comment - Fixed in 1.2.x branch (for the upcoming 1.2.2 release) and in trunk. This fix however does NOT support custom sessionId names - it only works with JSESSIONID. The problem is that the URL Rewriting logic in the ShiroHttpServletResponse does not have direct access to the SessionManager implementation to consult for the sessionIdName property. This requires a much deeper fix that should be implemented, but at a later date (probably 2.0).
        Hide
        Maciej Matys added a comment -

        ShiroHttpServletResponse.encodeRedirectURL() and encodeURL() should add session id in servlet 2.5 compliant way so as a URI path parameter and session id name should be based on shiro configuration see DefaultWebSessionManager. getSessionIdName().
        Parsing URI path parameters should also be fixed in DefaultWebSessionManager.

        Show
        Maciej Matys added a comment - ShiroHttpServletResponse.encodeRedirectURL() and encodeURL() should add session id in servlet 2.5 compliant way so as a URI path parameter and session id name should be based on shiro configuration see DefaultWebSessionManager. getSessionIdName(). Parsing URI path parameters should also be fixed in DefaultWebSessionManager.
        Hide
        Gareth Collins added a comment - - edited

        Jim,

        I understand your point of view and we could go away and discuss implementation options for multiple devices, but it is kind of irrelevant to the problem at hand. The Servlet 2.5 spec, section SRV.7.1.4 states:

        "Web containers must be able to support the HTTP session while servicing HTTP requests from clients that do not support the use of cookies."

        This support is already there for Shiro native sessions. It just doesn't work correctly.

        I guess you could argue that this functionality should be removed rather than fixed. However, even if this functionality was removed from Shiro native sessions, the Shiro user would still be able to access this functionality by using Tomcat/Jetty sessions instead (as these containers are servlet 2.5 compliant)...so little would be achieved apart from hobbling Shiro native session functionality.

        Show
        Gareth Collins added a comment - - edited Jim, I understand your point of view and we could go away and discuss implementation options for multiple devices, but it is kind of irrelevant to the problem at hand. The Servlet 2.5 spec, section SRV.7.1.4 states: "Web containers must be able to support the HTTP session while servicing HTTP requests from clients that do not support the use of cookies." This support is already there for Shiro native sessions. It just doesn't work correctly. I guess you could argue that this functionality should be removed rather than fixed. However, even if this functionality was removed from Shiro native sessions, the Shiro user would still be able to access this functionality by using Tomcat/Jetty sessions instead (as these containers are servlet 2.5 compliant)...so little would be achieved apart from hobbling Shiro native session functionality.
        Hide
        Jim Manico added a comment -

        Which mobile device does not support cookies or HTTP Request headers? It
        may not be convenient, but I stand by keeping session information - or
        any sensitive data - out of a HTTP GET request, even over HTTPS.
        Especially for a security library or security community as sharp as
        Shiro!

        • Jim


        Jim Manico

        Connections Committee Chair
        Cheatsheet Series Product Manager
        OWASP Podcast Producer/Host

        jim@owasp.org
        www.owasp.org

        Show
        Jim Manico added a comment - Which mobile device does not support cookies or HTTP Request headers? It may not be convenient, but I stand by keeping session information - or any sensitive data - out of a HTTP GET request, even over HTTPS. Especially for a security library or security community as sharp as Shiro! Jim – Jim Manico Connections Committee Chair Cheatsheet Series Product Manager OWASP Podcast Producer/Host jim@owasp.org www.owasp.org
        Hide
        Gareth Collins added a comment -

        Cookies are definitely better though sometimes you need to support this because certain mobile devices/client APIs do not support cookies.
        For my implementation, this will be all over SSL and is not planned for use with a vanilla browser.

        Show
        Gareth Collins added a comment - Cookies are definitely better though sometimes you need to support this because certain mobile devices/client APIs do not support cookies. For my implementation, this will be all over SSL and is not planned for use with a vanilla browser.
        Hide
        Jim Manico added a comment -

        Just a polite note, Session Id's in URL's are a serious vulnerability
        (session rewriting). In general, GET request parameters should never
        contain sensitive data since they leak (bookmarks, proxy/web server
        logs, referrer headers, etc).

        Forgive me if this is already known or inappropriate. I'm new here.

        Aloha,


        Jim Manico

        Connections Committee Chair
        Cheatsheet Series Product Manager
        OWASP Podcast Producer/Host

        jim@owasp.org
        www.owasp.org

        Show
        Jim Manico added a comment - Just a polite note, Session Id's in URL's are a serious vulnerability (session rewriting). In general, GET request parameters should never contain sensitive data since they leak (bookmarks, proxy/web server logs, referrer headers, etc). Forgive me if this is already known or inappropriate. I'm new here. Aloha, – Jim Manico Connections Committee Chair Cheatsheet Series Product Manager OWASP Podcast Producer/Host jim@owasp.org www.owasp.org

          People

          • Assignee:
            Unassigned
            Reporter:
            Gareth Collins
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development