How To Perform Authentication Testing | Based on Owasp

In this session, I will discuss how to do testing on Authentication Testing that refers to OWASP.

Whats Authentication Testing ?

Authentication testing means to understand how the authentication works and then trying to use some of the bypasses in order to test whether it has been implemented properly or not. For example what are the ways an application is using to authenticate the user

There are 10 test checklists

1. Testing for Credentials Transported over an Encrypted Channel

Summary

Testing for credentials transport verifies that web applications encrypt authentication data in transit. This encryption prevents attackers from taking over accounts by sniffing network traffic. Web applications use HTTPS to encrypt information in transit for both client to server and server to client communications. A client can send or receive authentication data during the following interactions:

• A client sends a credential to request login
• The server responds to a successful login with a session token
• An authenticated client sends a session token to request sensitive information from the web site
• A client sends a token to the web site if they forgot their password

How to Test ?

Login
Find the address of the login page and attempt to switch the protocol to HTTP. For example, the URL for the forced browsing could look like the following: https://localhost:8080/wp-admin/.

If the login page is normally HTTPS, attempt to remove the “S” to see if the login page loads as HTTP.

Log in using a valid account while attempting to force the use of unencrypted HTTP. In a passing test, the login request should be HTTPS:

then Power On Intercept Proxy to view and change from HTTPS to HTTP whether it gives a response

send to Repeater

and try to change https to http, then check the response.

Notes: when changing https to http on the repeater when sending does not display any response, it means that the website is secure.

2. Testing for Default Credentials

Summary

Nowadays web applications often make use of popular Open Source or commercial software that can be installed on servers with minimal configuration or customization by the server administrator. Moreover, a lot of hardware appliances (i.e. network routers and database servers) offer web-based configuration or administrative interfaces.

Often these applications, once installed, are not properly configured and the default credentials provided for initial authentication and configuration are never changed. These default credentials are well known by penetration testers and, unfortunately, also by malicious attackers, who can use them to gain access to various types of applications.

Furthermore, in many situations, when a new account is created on an application, a default password (with some standard characteristics) is generated. If this password is predictable and the user does not change it on the first access, this can lead to an attacker gaining unauthorized access to the application.

The root cause of this problem can be identified as:

• Inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components, or leave the password as default for “ease of maintenance”.
• Programmers who leave back doors to easily access and test their application and later forget to remove them.
• Applications with built-in non-removable default accounts with a preset username and password.
• Applications that do not force the user to change the default credentials after the first log in.

How to Test ?

when finding the login page, try to access using default credentials such as admin:admin, admin:password, test:test, etc.

On the testphp.vulnweb.com website, the default credentials are test:test, you can see when you want to log in.

Note: This website is designed for practice testing and is vulnerable to hacking. In Real Cases, there is no message to provide credentials to enter the website unless you have registered.

3. Testing for Weak Lock Out Mechanism

Summary

Account lockout mechanisms are used to mitigate brute force attacks. Some of the attacks that can be defeated by using lockout mechanism:

• Login password or username guessing attack.
• Code guessing on any 2FA functionality or Security Questions.

Account lockout mechanisms require a balance between protecting accounts from unauthorized access and protecting users from being denied authorized access. Accounts are typically locked after 3 to 5 unsuccessful attempts and can only be unlocked after a predetermined period of time, via a self-service unlock mechanism, or intervention by an administrator.

Despite it being easy to conduct brute force attacks, the result of a successful attack is dangerous as the attacker will have full access on the user account and with it all the functionality and services they have access to.

How to Test ?

To evaluate the ability of the account locking mechanism to reduce forced password guesses, try an invalid login using the wrong password several times, before using the correct password to verify that the account is locked. An example test might be as follows:

1. Trying to log in with the wrong password 3 times.
2. Successfully log in with the correct password, thereby demonstrating that the lockout mechanism was not triggered after 3 incorrect authentication attempts.
3. Attempted to log in with the wrong password 4 times.
   Successfully logged in with the correct password, thus demonstrating that
4. The lockout mechanism was not triggered after 4 incorrect authentication attempts.
5. Tried to log in with the wrong password 5 times.

Log in using a example Account and then Power On Intercept Proxy to view or send to Intruder or Repeater

Positions

Payload Set 1

Payload set 2

and start Attack to Testing Weak Lock Out Mechanism

Note: This website is designed for practical testing and is vulnerable to hacking. Testing for Weak Locking Mechanisms is not applicable on this website, perhaps you can try other related websites.

4. Testing for Bypassing Authentication Schema

Summary

In computer security, authentication is the process of attempting to verify the digital identity of the sender of a communication. A common example of such a process is the log on process. Testing the authentication schema means understanding how the authentication process works and using that information to circumvent the authentication mechanism.

While most applications require authentication to gain access to private information or to execute tasks, not every authentication method is able to provide adequate security. Negligence, ignorance, or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the log in page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.

In addition, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that the user is already authenticated. This can be accomplished either by modifying the given URL parameter, by manipulating the form, or by counterfeiting sessions.

Problems related to the authentication schema can be found at different stages of the software development life cycle (SDLC), like the design, development, and deployment phases:

• In the design phase errors can include a wrong definition of application sections to be protected, the choice of not applying strong encryption protocols for securing the transmission of credentials, and many more.
• In the development phase errors can include the incorrect implementation of input validation functionality or not following the security best practices for the specific language.
• In the application deployment phase, there may be issues during the application setup (installation and configuration activities) due to a lack in required technical skills or due to the lack of good documentation.

How to Test ?

• Go to “Proxy” > “Options”, scroll down to the “Match and Replace” section, and click “Add”. Leave the match condition blank, but in the “Replace” field, enter:
• X-Custom-IP-Authorization: 127.0.0.1

• Burp Proxy will now add this header to every request you send.

and you can delete user, because you getting admin panel

5. Testing for Vulnerable Remember Password

Summary

Credentials are the most widely used authentication technology. Due to such a wide usage of username-password pairs, users are no longer able to properly handle their credentials across the multitude of used applications.

In order to assist users with their credentials, multiple technologies surfaced:

• Applications provide a remember me functionality that allows the user to stay authenticated for long periods of time, without asking the user again for their credentials.
• Password Managers — including browser password managers — that allow the user to store their credentials in a secure manner and later on inject them in user-forms without any user intervention.

How to Test ?

Access the lab to Tried Testing Vulnerable Remember Password

You can log in to your own account using the following credentials: wiener:peter

Submit the “Update email” form, and find the resulting request in your Proxy history.

result after Change Email :

Check request in Burpsuite

right-click on the request and select Engagement tools / Generate CSRF PoC. Enable the option to include an auto-submit script and click “Regenerate”.

Go to the exploit server, paste your exploit HTML into the “Body” section, and click “Store”.

To verify that the exploit works, try it on yourself by clicking “View exploit” and then check the resulting HTTP request and response.

click “Deliver to Victim”

6. Testing for Browser Cache Weaknesses

Summary

In this phase the tester checks that the application correctly instructs the browser to not retain sensitive data.

Browsers can store information for purposes of caching and history. Caching is used to improve performance, so that previously displayed information doesn’t need to be downloaded again. History mechanisms are used for user convenience, so the user can see exactly what they saw at the time when the resource was retrieved. If sensitive information is displayed to the user (such as their address, credit card details, Social Security Number, or username), then this information could be stored for purposes of caching or history, and therefore retrievable through examining the browser’s cache or by simply pressing the browser’s Back button.

How to Test ?

try to log into this website Used test:test and click Button Login

after login, try to logout and click Back Button menu in browser.

And was returned to the userinfo page.

7. Testing for Weak Password Policy

Summary

The most prevalent and most easily administered authentication mechanism is a static password. The password represents the keys to the kingdom, but is often subverted by users in the name of usability. In each of the recent high profile hacks that have revealed user credentials, it is lamented that most common passwords are still: 123456, password and qwerty.

How to Test ?

• What characters are permitted and forbidden for use within a password? Is the user required to use characters from different character sets such as lower and uppercase letters, digits and special symbols?

carlos:123456

not enforce the password policy on this website.

8. Testing for Weak Security Question Answer

Summary

Often called “secret” questions and answers, security questions and answers are often used to recover forgotten passwords (see Testing for weak password change or reset functionalities, or as extra security on top of the password.

They are typically generated upon account creation and require the user to select from some pre-generated questions and supply an appropriate answer. They may allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.Ideally, security questions should generate answers that are only known by the user, and not guessable or discoverable by anybody else. This is harder than it sounds. Security questions and answers rely on the secrecy of the answer. Questions and answers should be chosen so that the answers are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseudo-private.

How To Test ?

The majority of pre-generated questions are fairly simplistic in nature and can lead to insecure answers. For example:

• The answers may be known to family members or close friends of the user, e.g. “What is your mother’s maiden name?”, “What is your date of birth?”
• The answers may be easily guessable, e.g. “What is your favorite color?”, “What is your favorite baseball team?”
• The answers may be brute forcible, e.g. “What is the first name of your favorite high school teacher?” — the answer is probably on some easily downloadable lists of popular first names, and therefore a simple brute force attack can be scripted.
• The answers may be publicly discoverable, e.g. “What is your favorite movie?” — the answer may easily be found on the user’s social media profile page.

9. Testing for Weak Password Change or Reset Functionalities

Summary

The password change and reset function of an application is a self-service password change or reset mechanism for users. This self-service mechanism allows users to quickly change or reset their password without an administrator intervening. When passwords are changed they are typically changed within the application. When passwords are reset they are either rendered within the application or emailed to the user. This may indicate that the passwords are stored in plain text or in a decryptable format.

10. Testing for Weaker Authentication in Alternative Channel

Summary

Even if the primary authentication mechanisms do not include any vulnerabilities, it may be that vulnerabilities exist in alternative legitimate authentication user channels for the same user accounts. Tests should be undertaken to identify alternative channels and, subject to test scoping, identify vulnerabilities.

The alternative user interaction channels could be utilized to circumvent the primary channel, or expose information that can then be used to assist an attack against the primary channel. Some of these channels may themselves be separate web applications using different hostnames or paths.