A question that often arises when considering what authenticated roles to include for application security/penetration testing is whether administrative roles should be included. After all, should it not be assumed that an attacker with an administrative role could do major damage to the application and its stakeholders regardless of vulnerabilities that might be present? Of course, the answer to this is yes, but there are two important considerations that this perspective ignores. Let’s explore these.
There exists a wide range of common application vulnerabilities that can be used against privileged application roles even where attackers lack access to those roles. Some examples include cross-site scripting, cross-site request forgery, and the wide range of issues that fall under the category of privilege escalation. While these vulnerabilities can often be exploited by underprivileged roles targeting admin users, they are not always trivial to discover or validate from this perspective. Penetration testing of the administrative role gives skilled testers the opportunity to easily discover sensitive functionality and explore how it behaves, identifying and validating vulnerabilities that exist across this privileged functionality. While it may be possible to discover these issues from an underprivileged role, this approach may be more time consuming and less reliable. Assuming an attacker will not exploit administrative functionality simply because they do not know of it is relying on security through obscurity.
The common assumption that an administrative application user is expected to and ought to have unbounded privileges is not appropriate. Clearly identifying the extent to which admin users can impact the application and infrastructure can inform development towards better implementation of the principle of least privilege and other best practices. Consider the following example seen in practice: a multi-tenant application that supported admin users from different organizations. In this application, there existed a feature to run a virus scanner on the system of the admin user’s choice. Unfortunately, the feature did not protect against command injection, permitting any admin user to run arbitrary commands on the underlying operating system. As a result, an admin user could break the isolation assumed to exist between different organizations. Fixing this issue substantially reduced the risk posed by the compromise of a single admin user belonging to any tenant organization. Through the testing process, there were additional issues discovered relating to best practices and defense in depth strategies that would mitigate the impact of such attacks.
As with all application penetration testing, engagements should be conducted in non-production environments where adverse events that may result from testing will not impact a critical system or application. This is especially true for admin accounts, where a single function call can have a devastating impact on the application and its users. While testing activities can be restricted to safely avoid impact, such restrictions may substantially limit the results.
Naturally, admin functionality tends to be vast. Inclusion of an admin account can substantially increase the amount of effort required for our security specialists to adequately cover all functions and features. Our sales consultants and security specialists can work with you to determine whether testing of administrative functionality makes sense for you and whether it ought to be a priority.