3.0 Identity Management Testing
3.1 Test Role Definitions
Roles Identification
The tester should start by identifying the application roles being tested through any of the following methods:
Application documentation.
Guidance by the developers or administrators of the application.
Application comments.
Fuzz possible roles:
cookie variable (e.g.
role=admin
,isAdmin=True
)account variable (e.g.
Role: manager
)hidden directories or files (e.g.
/admin
,/mod
,/backups
)switching to well known users (e.g.
admin
,backups
, etc.)
Switching to Available Roles
After identifying possible attack vectors, the tester needs to test and validate that they can access the available roles.
Some applications define the roles of the user on creation, through rigorous checks and policies, or by ensuring that the user’s role is properly protected through a signature created by the backend. Finding that roles exist doesn’t mean that they’re a vulnerability.
Review Roles Permissions
After gaining access to the roles on the system, the tester must understand the permissions provided to each role.
A support engineer shouldn’t be able to conduct administrative functionalities, manage the backups, or conduct any transactions in the place of a user.
An administrator shouldn’t have full powers on the system. Sensitive admin functionality should leverage a maker-checker principle, or use MFA to ensure that the administrator is conducting the transaction. A clear example on this was the Twitter incident in 2020.
3.2 Test User Registration Process
Verify that the identity requirements for user registration are aligned with business and security requirements:
Can anyone register for access?
Are registrations vetted by a human prior to provisioning, or are they automatically granted if the criteria are met?
Can the same person or identity register multiple times?
Can users register for different roles or permissions?
What proof of identity is required for a registration to be successful?
Are registered identities verified?
Validate the registration process:
Can identity information be easily forged or faked?
Can the exchange of identity information be manipulated during registration?
3.3 Test Account Provisioning Process
Determine which roles are able to provision users and what sort of accounts they can provision.
Is there any verification, vetting and authorization of provisioning requests?
Is there any verification, vetting and authorization of de-provisioning requests?
Can an administrator provision other administrators or just users?
Can an administrator or other user provision accounts with privileges greater than their own?
Can an administrator or user de-provision themselves?
How are the files or resources owned by the de-provisioned user managed? Are they deleted? Is access transferred?
3.4 Testing for Account Enumeration and Guessable User Account
HTTP Response Message (different responses)
Testing for Valid Credentials
Testing for Valid User with Wrong Password
Testing for a Nonexistent Username
Other Ways to Enumerate Users
Analyzing the Error Code Received on Login Pages
Analyzing URLs and URLs Re-directions
http://www.foo.com/err.jsp?User=baduser&Error=0
http://www.foo.com/err.jsp?User=gooduser&Error=2
URI Probing
403 Forbidden error code
404 Not found error code
Analyzing Web Page Titles
Invalid user
Invalid authentication
Analyzing a Message Received from a Recovery Facility
Invalid username: email address is not valid or the specified user was not found.
Valid username: Your password has been successfully sent to the email address you registered with.
Friendly 404 Error Message
Analyzing Response Times
Guessing Users
3.5 Testing for Weak or Unenforced Username Policy
Determine the structure of account names.
Evaluate the application’s response to valid and invalid account names.
Use different responses to valid and invalid account names to enumerate valid account names.
Use account name dictionaries to enumerate valid account names.
Last updated