In this session, I will discuss a little about what identity management testing Based on OWASP.
There are 5 checklists available, namely :
- Test Role Definitions
- Test User Registration Process
- Test Account Provisioning Process
- Testing for Account Enumeration and Guessable User Account, and the Last
- Testing for Weak or Unenforced Username Policy
let’s unpack the practical examples and applications
1. Test Role Definitions
Summary
Applications have several types of functionalities and services, and those require access permissions based on the needs of the user. That user could be:
- an administrator, where they manage the application functionalities.
- an auditor, where they review the application transactions and provide a detailed report.
- a support engineer, where they help customers debug and fix issues on their accounts.
- a customer, where they interact with the application and benefit from its services.
In order to handle these uses and any other use case for that application, role definitions are setup (more commonly known as RBAC). Based on these roles, the user is capable of accomplishing the required task
Test Objectives
- Identify and document roles used by the application.
- Attempt to switch, change, or access another role.
- Review the granularity of the roles and the needs behind the permissions given.
How to Testing ?
Roles Identification
When testing role definitions, the first thing we have to test is the correct user privilege level for the user type on the platform which is usually shared between users and admins. Users are usually not allowed login access that should be restricted to administrators only which would be vertical privilege escalation or should not be able to perform operations on behalf of other users with the same privilege level which would be horizontal privilege escalation.
for example, I tried on wordpress
If we visit the user creation page, as an administrator we can add a new user
I’m trying to add a new user, and trying to log in, if you already log into wordpress using Admin,,, please logout……
if you have entered your username and password, and trying to create or add new users, you will get the following message:
why does this happen?
Because ordinary users do not have Admin Privilege Escalation to access the page.
2. Test User Registration Process
Summary
Some websites offer a user registration process that automates (or semi-automates) the provisioning of system access to users. The identity requirements for access vary from positive identification to none at all, depending on the security requirements of the system. Many public applications completely automate the registration and provisioning process because the size of the user base makes it impossible to manage manually. However, many corporate applications will provision users manually, so this test case may not apply.
Test Objectives
- Verify that the identity requirements for user registration are aligned with business and security requirements.
- Validate the registration process.
How to Testing ?
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?
Try to view HTTP History on Burpsuite proxy
Try to log into website used credential already registered
and the account registration process is successfully login.
3. Test Account Provisioning Process
Summary
The provisioning of accounts presents an opportunity for an attacker to create a valid account without application of the proper identification and authorization process.
Test Objectives
- Verify which accounts may provision other accounts and of what type.
Example :
Another test to perform its valuating for user enable to Register multiple time on the website with multiple account and how black hats can usually register multiple accounts for spamming and other malicious activities on the site and a large number of fake accounts can damage a business’s image and also create financial disruption due to wasted database space
let’s try to create the test1 user account again with test as the password
Before you press the register button, make sure you have configured burpsuite first, in this session I will not provide a tutorial on how to tampering connection data. And then, enable the Proxy “Intercept is on” and click the register button.
send to Repeater and try create 2 or 3 new Users.
if we look at this all it seems to have managed to create 1 to 3 new accounts.
Successfully log in using the account that was created earlier.
lack of validation and lack of chatcha in the form should raise a red flag.
Think about blackhats who crash cloud hosting websites by creating hundreds or even thousands of test accounts for the purpose of mining e.g. cryptocurrencies. Most cloud hosting companies have implemented strong SMS and captcha authentication and entirely removed the concept of test accounts from their business model to mitigate this problem.
the problem we just talked about can be even worse if the account provisioning is done automatically depending on the user’s company security policy may be provided manually depending on the policy set by the website administrator owner or cannot provide other administrative accounts.
Add positions and set Payload like this :
and Start Attacks
Boom, 50 new account created
4. Testing for Account Enumeration and Guessable User Account
Summary
The scope of this test is to verify if it is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for brute force testing, in which the tester verifies if, given a valid username, it is possible to find the corresponding password.
Test Objectives
- Review processes that pertain to user identification (e.g. registration, login, etc.).
- Enumerate users where possible through response analysis.
How to Test
The tester knows nothing about the specific application, username, application logic, error messages on log in page, or password recovery facilities. If the application is vulnerable, the tester receives a response message that reveals, directly or indirectly, some information useful for enumerating users.
Example :
Try to use an account username and password that doesn’t exist it tells us that the username is wrong.
It is much easier to count existing accounts in this way if just telling us that the password and username combination is wrong would be more difficult.
We can try the admin with the wrong password and it will confirm that the username exists, so it’s just a matter of forcing the password using tools like WPScan, hydra, or so forth.
5. Testing for Weak or Unenforced Username Policy
Summary
User account names are often highly structured (e.g. Joe Bloggs account name is jbloggs and Fred Nurks account name is fnurks) and valid account names can easily be guessed.
Test Objectives
- Determine whether a consistent account name structure renders the application vulnerable to account enumeration.
- Determine whether the application’s error messages permit account enumeration.
How to Test
- 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.
Remediation
Ensure the application returns consistent generic error messages in response to invalid account name, password or other user credentials entered during the log in process.
Thankyou for All, and </To be Shadow>
