Take implementing access controls against administrative functionality around user management as an example. Ultimately this issue boils down to an access control issue and you would think it is an easy one to solve, but how these impersonate functions work is a little bit of a, how should I say it, Inception film plot? Let me explain.Īccess controls aka authorization - either your name is on the list and you’re coming into the club or your name is not and you’ll have to move on (to the pub down the road). Whenever I hear about an impersonation feature existing in an application, I get those spidey hacker senses tingling because more often than not, I am able to abuse these and use them as a direct path to vertical privilege escalation through arbitrary account takeover. In this instance, the feature is often kept in as a legacy thing, no longer used or referenced in the UI, but handlers exist in the code, and you’ll only find out about its existence by references in the JavaScript code or old CSS relating to UI elements. I’ve also seen this functionality over the years created solely by development teams so that they can quickly switch users (and roles) to assist with development of an application, without having to keep authenticating every second. This feature allows support teams to see the application as the user would see it, often in relation to following a user journey in the context of that user, in order to see the same error message a user is receiving with a view to resolving the issue.

A user impersonation feature typically allows a privileged user, such as an administrator, but typically these days, support teams, to sign into an application as a specific user without needing to know the user’s password.

Download spidey for free