Spring Security
  1. Spring Security
  2. SEC-1068

same login session but login 2 different users simultaneously

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 2.0.4
    • Fix Version/s: 3.0.0 M1
    • Component/s: Core
    • Labels:
      None
    • Environment:
      Tomcat 6.0.14, CentOS linux, JDK 1.6, EHCache1.6 beta 1, Hibernate3.3.1.ga

      Description

      I am not 100% sure it is SpringSecurity bug as I can not reproduce this bug. It maybe caused by tomcat session management or EHCache... But I put it here just because it is very serious issue. I really need SS expert's help.... For the whole authentication process, very few part of my code is involved, almost all from SS configuration.

      My site is running on Internet and allow public register and login. Someday, while I login(or maybe remember-me auto login, I forgot detail), my user should be "admin". But I suddenly found my login user is another unknown guy(user name is "alexuser") !!!! I checked log, that guy is latest registered user, last login is 2 hour early than my login. I cannot point out if he chose remeber-me option. Between alexuser and me login, there aren't any login event.

      There are 2 login success events during my login. Log shows an exception between them, but I don't think this exception is very critical for this bug. The exception is thrown from a customized filter(CaptchaValidationProcessingFilter - see attachment), in line 1 of doFilter():
      String captchaResponse = request.getParameter("j_captcha_response");

      The attachment is my appliationContext-security.xml. I am using spring security 2.0.3. But my code is upgraded from acegi, so my configuration is still that bloat xml style.

      Log information as below, the first login event publish success event, but it does not continue - at least log displays "admin" did not continue to load its setting. It looks second login success event replaced first.

      Basically, I assume the real "alexuser" did not login simultaneously. It likes SpringSecurity API interrupt by that exception then goes somewhere pickup wrong user and do authentication again...

      Log
      ----------------------------------------------------------------------------------------
      2008-12-18 06:24:10,750 WARN [LoggerListener] Authentication event AuthenticationSuccessEvent: admin; details: org.springframework.security.ui.WebAuthenticationDetails@0: RemoteIpAddress: 60.242.146.122; SessionId: 1F63337DB300CA25A919E72CF52590C5
      2008-12-18 06:24:10,750 WARN [LoggerListener] Authentication event InteractiveAuthenticationSuccessEvent: admin; details: org.springframework.security.ui.WebAuthenticationDetails@0: RemoteIpAddress: 60.242.146.122; SessionId: 1F63337DB300CA25A919E72CF52590C5
      Dec 18, 2008 6:24:10 AM org.apache.tomcat.util.http.Parameters processParameters
      WARNING: Parameters: Character decoding failed. Parameter skipped.
      java.io.CharConversionException: EOF
      at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:83)
      at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:49)
      at org.apache.tomcat.util.http.Parameters.urlDecode(Parameters.java:412)
      at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:394)
      at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:346)
      at org.apache.catalina.connector.Request.parseParameters(Request.java:2470)
      at org.apache.catalina.connector.Request.getParameter(Request.java:1040)
      at org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:355)
      at com.mypackge.wiki.security.acegi.CaptchaValidationProcessingFilter.doFilter(CaptchaValidationProcessingFilter.java:59)
      at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
      at org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235)
      at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
      at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
      at org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:174)
      at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:236)
      at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:70)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198)
      at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at com.mypackage.wiki.webapp.filter.InstallFilter.doFilterInternal(InstallFilter.java:49)
      at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
      at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
      at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
      at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
      at java.lang.Thread.run(Thread.java:619)
      2008-12-18 06:24:10,821 WARN [LoggerListener] Authentication event AuthenticationSuccessEvent: alexuser; details: org.springframework.security.ui.WebAuthenticationDetails@0: RemoteIpAddress: 60.242.146.122; SessionId: 1F63337DB300CA25A919E72CF52590C5
      2008-12-18 06:24:10,822 WARN [LoggerListener] Authentication event InteractiveAuthenticationSuccessEvent: alexuser; details: org.springframework.security.ui.WebAuthenticationDetails@0: RemoteIpAddress: 60.242.146.122; SessionId: 1F63337DB300CA25A919E72CF52590C5
      2008-12-18 06:24:11,061 WARN [User] User alexuser does not have personal setting, using default one instead.
      2008-12-18 06:24:11,463 INFO [MarkupRenderEngineImpl] Render markup content takes: 1ms

      ----------------------------------------------------------------------------------------

        Activity

        Hide
        Luke Taylor added a comment -

        I'm afraid there's no real concrete evidence here of a critical bug. If you suspect ehcache then remove the user cache as it's not necessary. The user cache implementation is a simple username key lookup in ehcache.

        The stacktrace you show is coming from your own class and there is only one additional filter (the HttpSessionContextIntegrationFilter) in the stack above that. This does nothing other than clear the context in a finally block. I'm not aware of any circumstances which would justify the observation that

        "It likes SpringSecurity API interrupt by that exception then goes somewhere pickup wrong user and do authentication again... "

        There's nothing in the codebase that behaves that way.

        It's really impossible to say what is going on without more information or a debug log.

        Show
        Luke Taylor added a comment - I'm afraid there's no real concrete evidence here of a critical bug. If you suspect ehcache then remove the user cache as it's not necessary. The user cache implementation is a simple username key lookup in ehcache. The stacktrace you show is coming from your own class and there is only one additional filter (the HttpSessionContextIntegrationFilter) in the stack above that. This does nothing other than clear the context in a finally block. I'm not aware of any circumstances which would justify the observation that "It likes SpringSecurity API interrupt by that exception then goes somewhere pickup wrong user and do authentication again... " There's nothing in the codebase that behaves that way. It's really impossible to say what is going on without more information or a debug log.
        Hide
        Luke Taylor added a comment -

        No further information. Closing.

        Show
        Luke Taylor added a comment - No further information. Closing.
        Hide
        Michael Stevens added a comment -

        I came across this ticket in researching the same bug in our system, and even though the issue is closed, I wanted to add my comment in case it's useful for others experiencing the problem.

        We use Tomcat 6.0.13 and Spring Security 2.0.4, and we have seen numerous occurrences of this bug in our production system. We had an AJAX mechanism in place for the authentication request, and a typical occurrence looks like this:

        • User A logs in
        • A few minutes later, User B attempts to log in on the same server
        • A request is served by the container that contains User A's credentials (username/password) in request parameters, but with User B's IP address and session ID
        • Result is User B is logged in as User A

        Our AJAX mechanism was causing other problems, so we recently went with a conventional POST form request instead, and so far we have not seen the issue surface again. We still don't know why the problem was happening, but debug output so far suggests that the server sees the mixed request at the very top of the filter chain. This suggests (not confirmed) that if any Spring Security classes are collaborators in the bug we saw, it would have to be somewhere in the FilterChainProxy. Otherwise, the problem is in Tomcat container code, intermediate server hardware (firewall or load balancer), or (much less likely) client-side Javascript.

        Show
        Michael Stevens added a comment - I came across this ticket in researching the same bug in our system, and even though the issue is closed, I wanted to add my comment in case it's useful for others experiencing the problem. We use Tomcat 6.0.13 and Spring Security 2.0.4, and we have seen numerous occurrences of this bug in our production system. We had an AJAX mechanism in place for the authentication request, and a typical occurrence looks like this: User A logs in A few minutes later, User B attempts to log in on the same server A request is served by the container that contains User A's credentials (username/password) in request parameters, but with User B's IP address and session ID Result is User B is logged in as User A Our AJAX mechanism was causing other problems, so we recently went with a conventional POST form request instead, and so far we have not seen the issue surface again. We still don't know why the problem was happening, but debug output so far suggests that the server sees the mixed request at the very top of the filter chain. This suggests (not confirmed) that if any Spring Security classes are collaborators in the bug we saw, it would have to be somewhere in the FilterChainProxy. Otherwise, the problem is in Tomcat container code, intermediate server hardware (firewall or load balancer), or (much less likely) client-side Javascript.
        Hide
        Ramin B added a comment -

        Hi Michael and others, we actually came across a very similar situation in our production application this week. A user reported that once he logged in and performed a certain AJAX action, he was viewing another user's information.. as if he were that user. Very similar to what you described in your scenario Michael.

        It is interesting that you mention the Ajax part, because we make an Ajax request to the server to see if the current user is logged in before we allow them to perform certain other ajax-y functions. If wonder if those initial ajax authentication calls are the cause of our problems?

        Its a very strange bug and very difficult to reproduce. If you have any information regarding this issue, I would greatly appreciate your feedback.

        Here are some useful links I found on the net regarding this issue:

        http://www.ideyatech.com/2009/03/a-hidden-fatal-flaw-in-audit-logging-with-hibernate-and-acegi/
        http://securitytracker.com/alerts/2003/Jan/1006018.html

        Thanks

        Show
        Ramin B added a comment - Hi Michael and others, we actually came across a very similar situation in our production application this week. A user reported that once he logged in and performed a certain AJAX action, he was viewing another user's information.. as if he were that user. Very similar to what you described in your scenario Michael. It is interesting that you mention the Ajax part, because we make an Ajax request to the server to see if the current user is logged in before we allow them to perform certain other ajax-y functions. If wonder if those initial ajax authentication calls are the cause of our problems? Its a very strange bug and very difficult to reproduce. If you have any information regarding this issue, I would greatly appreciate your feedback. Here are some useful links I found on the net regarding this issue: http://www.ideyatech.com/2009/03/a-hidden-fatal-flaw-in-audit-logging-with-hibernate-and-acegi/ http://securitytracker.com/alerts/2003/Jan/1006018.html Thanks

          People

          • Assignee:
            Luke Taylor
            Reporter:
            steveneo
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: