Introduction

Authentication, as OWASP states, is the process of verifying that an individual, entity, or website is who it claims to be. Authentication in the context of web applications is commonly performed by submitting a username or ID and one or more items of private information that only a given user should know.

For the following, we’ll walk through some of the main authentication vulnerability tests. With each one, we will provide a methodology breakdown of how to test, remediate, and help properly exploit.

OWASP ASVS Methodologies for Authentication Testing

Testing for Credentials Transported over an Encrypted Channel

How to Test:

• Intercept the request during a sensitive process on the application via Burp or any other web proxy such as Login, Account Creation, Password Reset, Change Password, etc.

• Observe that the registration request is sent over HTTP.

• Observe if any sensitive information has been sent via HTTP.

• If the traffic is not over HTTP, remove the letter ‘S’ from HTTPS and sent the request again. Observe if the request is sent over HTTP.

Vulnerabilities:

• Weak Registration Implementation over HTTP.

Remediation:

• Use HTTPS for the whole website.

• Implement HSTS and redirect any HTTP to HTTPS.

Testing for Default Credentials

How to Test:

• Check for the application name and version online for default credentials. For instance, you can check these websites:

• routerpasswords.com

• cirt.net/passwords

• If you cannot find the application name in these websites, test for the most common usernames (such as admin, administrator, root, system, guest, operator, or super) and passwords (password, pass123, password123, admin, or guest).

Vulnerabilities:

• Using Default Credentials.

• Weak Password Policy.

• Password Cracking for Common/Weak Passwords when Password Policy is Weak.

Remediation:

• Change the default credentials for applications or network devices after the initial setup.

Testing for Weak Lock Out Mechanism

How to Test:

• Go to the login page and send the unsuccessful login attempt request to Burp Intruder.

• Change the password values for brute force as random values.

• Observe that the response to the 20 or 30th request doesn’t change and the account is not locked.

• If CAPTCHA is in place, assess the weaknesses on it to bypass.

Vulnerabilities:

• No Rate Limiting on a Form.

• No Rate Limiting or Captcha on Login Page.

Remediation:

• Apply account unlock mechanisms (rate limiting or CAPTCHA) depending on the risk level.

Testing for Bypassing 2FA

How to Test:

• Test if the 2-factor authentication code can be used multiple times.

• Test if 2-factor authentication code can be brute-forced.

• Send multiple credentials in JSON body for passwords using an array such as:

{“username” : “xxx”,”password” : [ “aaa”, “bbb”, “ccc”, …]}

Vulnerabilities:

• 2-Factor Authentication (2FA) Bypass.

• Missing brute-force protection for two-factor authentication.

• Weak 2FA Implementation.

• CAPTCHA Bypass — X-Forwarded-For.

Remediation:

• Make sure that the 2-factor authentication code can be used only 1 time and randomly generated each time.

Testing for Browser Cache Weaknesses

How to Test:

• Review if the application stores sensitive information on the client-side.

• Review if access can occur without authorization.

Remediation:

Implement HTTP headers such as:

• Cache-Control: no-cache, no-store.

• Expires: 0

• Pragma: no-cache

• Cache-Control: must-revalidate, max-age=0, s-maxage=0

Testing for Weak Password Policy

How to Test:

• Determine how strong the password policy is by evaluating the length, complexity, reuse, and aging requirements of passwords.

• Observe that it’’ possible to set common passwords, such as password or 123456.

Vulnerabilities:

• Weak Password Policy.

Remediation:

• Introduce additional authentication controls (i.e. two-factor authentication) or introduce a strong password policy.

Testing for Weak Password Change or Reset Functionalities

How to Test:

• Assess the weaknesses in the forgot password token.

• Remove the forgot-password-token and send the request again.

• Add the X-Forwarded-Host with your own server and observe that the password reset URL has been sent to your server.

• Check if the old password requested to complete the change.

Vulnerabilities:

• Password reset broken logic.

• Password reset poisoning via middleware.

Remediation:

• The password change or reset function is a sensitive function and requires some form of protection, such as requiring users to re-authenticate or presenting the user with confirmation screens during the process.

Testing for Other Misconfigurations

How to Test:

• Test for Username/Email Address Enumeration by writing an existing username/email address with the wrong password to observe the error message.

• Test if password confirmation is necessary with the actions such as change email address, change password, delete account, manage 2FA.

• Test for Lack of Email Verification by checking during the registration process, an email verification is necessary.

Vulnerabilities:

• Username/Email Address Enumeration.

• Lack of Verification Email.

Remediation:

• Return generic error messages throughout the application.

• Verify the email during the registration process.

• Confirm the password in important account-related actions.

If you’re looking for a more detailed walk-through on Authentication, check out my latest video:

References:

• Please refer to the Cobalt Pentest Wiki for more information on each findings PoC: Vulnerability Wiki
• OWASP Latest: Application Security Testing, 04-Authentication Testing
• Authentication Cheat Sheet