When user switching is configured insecurely (allowing switching from an anonymous user), Actuator's `AuthenticationAuditListener` will NPE when exiting the switch

[Darkvater]

Our application has an anonymous landing page that allows one to impersonate multiple users. The first impersonation works, the second in the same session fails because of an NPE.

SwitchUserFilter tries to exit the impersonated user before doing the next impersonation. As the previous user is anonymous the originalUser will be NULL (SwitchUserFilter:284 is not executed as obj is a string with value "anonymousUser") and as such the
audit listener fails with an NPE (AuthenticationAuditListener:106).

This is using spring-boot 1.5.7 and corresponding spring-security 4.2.3 but looking at the code this is still there in the latest 1.5.18 release.
A potential workaround is to have no audit listener, or a custom one.

Note: will provide simple example later

[snicoll]

@Darkvater the template has a "do not copy/paste" mention so please don't do it. I've edited your comment to remove it.

Thanks for providing a sample.

[Darkvater]

test-scenario.zip

Please find a simple test scenario attached using spring boot 2.0.5.RELEASE. You get an NPE when trying to impersonate a second time. Comment MyApplication:41 to disable the custom listener and see that impersonation fails. For this it is crucial that the user is unauthenticated (eg. anonymous)
While writing this test case I have also found out that the scenario is only reproducible if "spring-boot-starter-actuator"-s are added to the project; without it things work just fine.

###Notes:###

• it is crucial that impersonation happens from an otherwise unauthenticated state
• the SwitchUserFilter is added after the AnonymousAuthenticationFilter (MyApplication:58), otherwise it is not even possible to impersonate as things blow up with an NPE at creating the event (SwitchUserFilter.java:240)
• maybe this is not the way that impersonation is supposed to be wired up?

[wilkinsona]

Thanks for the sample. Unfortunately, it's not clear to me how to use it to reproduce the problem.

Looking at the code, I've figured out that the entry point is http://localhost:8080/landing.html. From there, I can successfully impersonate all three users without an NPE occurring. You've said that it's "crucial that impersonation happens from an otherwise unauthenticated state" but I'm not sure what you mean by that or how to achieve it. AFAIK, I haven't authenticated. The only thing I have that's provided any state is the JSESSION cookie but deleting that will mean I'm working in a different session and you said in the opening description that "the second in the same session fails because of an NPE".

If you'd like us to spend some more time investigating, can you please take the time to provide the precise steps that must be followed to reproduce the problem.

[Darkvater]

Hi wilkinsona, apologies for the unclear instructions.

Steps to reproduce:

• compile project and run spring boot app MyApplication
• start up your browser and go to http://localhost:8080/landing.html
• open the link "impersonate user1" in a new tab, it will say USER1 as a successful switch user will forward you to http://localhost:8080/whoami showing the logged in user's credentials
• go back to the landing page tab and open the link "impersonate user2" in a new tab, it will say USER2

at this point everything works because a custom authentication audit listener is wired up

• go to your editor and comment out the bean definition at MyApplication:41 (public AbstractAuthenticationAuditListener noopListener())
• restart the application and try the same steps as previously
• see that when trying to do the second impersonation it will fail and there will be an exception on the server.

Note: the same can be achieved using curl by calling the impersonation endpoints (http://localhost:8080/login/impersonate?username=user1) directly, just ensure that the session cookie returned by the first call is used in the second.

[wilkinsona]

Thanks. I've reproduced the problem now. It's a bug in Actuator's AuthenticationAuditListener. When you switch from being anonymous to a user and then exit that switch, the targetUser of the AuthenticationSwitchUserEvent will be null as the original authentication, AnonymousAuthenticationToken that we're switching back to has a principal that is a String rather than a UserDetails.

[wilkinsona]

Having said the above, please note that allowing user switching by an anonymous user is a security risk and ignores the recommendations in the javadoc for SwitchUserFilter where it says:

This filter assumes that the user performing the switch will be required to be logged in as normal (i.e. as a ROLE_ADMIN user). The user will then access a page/controller that enables the administrator to specify who they wish to become (see switchUserUrl).
Note: This URL will be required to have appropriate security constraints configured so that only users of that role can access it (e.g. ROLE_ADMIN).

We can look at making Actuator's AuthenticationAuditListener more robust so that it tolerates an AuthenticationSwitchUserEvent with a null targetUser, but I would strongly recommend updating your security configuration to align with the recommendations quoted above.