Impersonation Failures

Several times in the last few weeks we have looked at applications that have significant issues with “impersonation” features.  What is impersonation?

an act of pretending to be another person for the purpose of entertainment or fraud.  (From Google.)

In practice, impersonation is a feature that is commonly implemented to allow Customer Support to “see what the user sees”.  Typically, it involves the support user effectively logging in as the actual user.  As such, as a feature it can be invaluable.

It can also go quite wrong.

We reviewed one application that allowed any user to impersonate any other user.  Only certain users should be able to perform impersonation.  This is an issue of authorization.  Rarely do we want regular users to be able to impersonate internal users.

It is almost a surprise if we see an application that has proper auditing around impersonation and actions during the impersonated session.

Things that should be auditable include:

• When the impersonation started and who initiated it.
• What actions were taken on behalf of the user by the impersonating user.
• When the impersonation stopped.

Extending on auditing just a bit, it is generally advisable that logging facilities record both the acting user and the logged in user.  Imagine that Joe wants to impersonate Matt’s account to help troubleshoot an issue.  All of the actions he takes should show changes to Matt’s data but there should also be a record that Joe is the acting / impersonating user.

This is also a good reminder that we often don’t need to show sensitive data, even to users themselves.  If we avoid showing specific sensitive data without an extra event (click), we can ensure that during impersonation sessions support personnel don’t see data that they don’t need to.

Another fail mode for impersonation is to have a common account with a “bypass” password, kind of like a shared super user for impersonation.  We’ve recently seen systems that allow users to get a bypass password/session and then do whatever they want without any audit trail as to what the users were looking at.  Using a shared user for this means that all of the audit trail will converge on a service account that we can’t now tie to a particular user.  It is always a good exercise to walk through negative abuse case scenarios and ensure that the information needed is being collected to make sense of them.

Let’s think about the risk model for a moment:

• Malicious internal user wants to collect information from application users
• Non-malicious internal user helps lots of people and ends up with their data on their system – then they become a victim of a phishing or other type of attack
• Malicious external user can elevate privileges by assuming another identity

Since impersonation is a way to bypass authentication and authorization, it should receive significant scrutiny.  If you have impersonation code, it may be worth reviewing code to ensure that only the users that you want to do it can, and that when they do their actions are tracked.