SEC-1068: same login session but login 2 different users simultaneously #1319

Closed
spring-issuemaster opened this Issue Dec 29, 2008 · 4 comments

1 participant

@spring-issuemaster

steveneo (Migrated from SEC-1068) said:

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

@spring-issuemaster

Luke Taylor said:

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.

@spring-issuemaster

Luke Taylor said:

No further information. Closing.

@spring-issuemaster

Michael Stevens said:

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.

@spring-issuemaster

Ramin B said:

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

@spring-issuemaster spring-issuemaster added this to the 3.0.0 M1 milestone Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment