10 Most Common Security Issues Found in Login Functionalities

During penetration testing and vulnerability assessment, the login functionalities are often encountered in some way or another. Most of the time, they are public-facing login portals where any user can attempt to log in to gain access to their accounts; on the other hand, sometimes, these login panels are restricted to specific users. The login functionality acts as a gateway that you need to unlock successfully to further access the application to its full potential. From a threat actor’s perspective, the login functionality is the main barrier to gain an initial foothold. Hence, it is essential from a penetration tester’s perspective to ensure that the login functionality implemented in the application is robust and secure against all types of vulnerabilities and misconfigurations.

This blog will discuss the common vulnerabilities or misconfigurations that a threat actor can exploit on login functionality and some remediations around it. For this purpose, we will be following the mindmap as mentioned above:

Vulnerability Test Cases

Default Credentials

Often, on the admin panels, third party software integrations, etc., that come with a pair of default credentials are left as it is. This may allow an attacker to enumerate the third party service and look for its default credentials. These credentials are usually privileged admin users and may allow an attacker to gain a complete foothold in the application.

Default Credentials List: https://github.com/danielmiessler/SecLists/tree/master/Passwords/Default-Credentials

For example, an admin panel using default credentials such as “admin:admin” is easy to guess and may allow an attacker to gain access to the respective admin panel as the highest privileged user.

Remediation: To remediate this issue, the developers need to ensure that the default credentials are disabled/changed and a strong pair of non-guessable credentials are enforced.

User Enumeration

There are multiple scenarios where when a user provides an invalid username, the application responds with a verbose error message stating that the user doesn’t exist. There are other ways to identify this as well, such as:

1. Error Message: Difference in the error message when a valid/invalid user name is provided.
2. Timing Difference: Difference in server response timing when a valid/invalid user name is provided.
3. Application-Specific Behaviour: In specific scenarios, there may be behaviour patterns that are specific to the application’s implemented login flow, and it may require additional observation to conclude if a user exists or not.

These issues may allow a threat actor to enumerate all the valid user’s of the application and further use them to perform targeted attacks such as brute-forcing and social engineering.

Remediation: To remediate this issue, the developers need to implement proper handling so that the application doesn’t reveal any verbose error message on a valid/invalid username. Only a generic message is displayed. Similarly, the timing difference should not be significant enough to allow user enumeration.

Missing Brute-Force Protection

Most of the time, the login pages are accessible to the world, and the application allows any user to register and log in. In this chance, a user might have used a weak or guessable password increase. Suppose an application allows a user to attempt login irrespective of the failed attempts and fails to block the attempt. In that case, it may give a threat actor a window of opportunity to perform a brute-force attack and guess the password of the victim user. 

Bypass Methods: Often the application implementation a rate limiting or captcha mechanism to restrict the brute-force attempts, however, there are multiple methods to bypass this implementation including but not limited to: 

1. Using the various HTTP Request Headers such as below mentioned. You can find Top Headers in the dataset from Project Resonance Wave 2.
   • X-Originating-IP: 127.0.0.1
   • X-Forwarded-For: 127.0.0.1
   • X-Remote-IP: 127.0.0.1
   • X-Remote-Addr: 127.0.0.1
   • X-Client-IP: 127.0.0.1
   • X-Host: 127.0.0.1
   • X-Forwared-Host: 127.0.0.1
2. Using null bytes (%00) in the vulnerable parameters
3. Sending the request without captcha parameter
4. Adding fake parameters with the same “key”:”value”
5. Limiting the threads or checking for race conditions
6. Changing user-agents, cookies, and IP address
7. Using IP rotation Burp Extensions to bypass IP based restrictions

To test this issue, simply use Burp’s Intruder feature or any custom brute-force script with a password wordlist of 200 passwords having an actual password in the list. Suppose the application doesn’t restrict the invalid attempts and provides a successful response on a valid password. In that case, it is an indication that the application doesn’t implement any sort of brute-force protection.

Remediation: To remediate this issue a developer may implement rate-limiting or CAPTCHA as an anti-automation mechanism. 

Credentials Over Unencrypted Channel

If the application accepts the credentials and logs in a user over an unencrypted communication channel, i.e. over HTTP protocol instead of HTTPS, the communication is vulnerable to man in the middle attack. An attacker may be able to sniff in the network and steal sensitive information.

Remediation: To remediate this issue, the developers need to strictly enforce HTTPS so that the application doesn’t communicate over HTTP. As a best practice, the developers should implement HSTS headers across all the subdomains as well.

Additionally, implementing Secure Flag on the session cookies that were fetched after login over HTTPS, ensures that the cookies are not stolen over the unencrypted channel. The secure flag protects cookies to be stolen over an unencrypted channel or via attacks like man-in-the-middle attack.

Cross-Site Scripting

The login pages may also be vulnerable to cross-site scripting under multiple scenarios. However, these are generally authenticated but can still be used to perform malicious actions such as redirecting a user to an attacker-controlled website and social engineering them to get hold of their credentials.

Let’s assume an application having a login page reflects the invalid username in the error message. This username is also present in the URL like: www.something.com/login/?user=harsh; now, an attacker may attempt to execute a reflected type of cross-site scripting in the user parameter by sending a malicious javascript payload. 

Remediation: To remediate this issue the developers can implement a proper input validation and sanitising on the input fields and not reflect user-supplied input in the error messages.

Additionally, implementing a HTTPOnly flag on the session cookies can protect sensitive cookies from being stolen using scripting attacks.

Parameter Pollution & Mass Assignment

A simple security misconfiguration may allow an attacker to bypass the authentication and gain unauthorised access to the victim user’s account. In this attack scenario, an attacker may attempt to bind multiple values to the same key or define various key-value pairs, i.e. using multiple usernames in username parameters or using multiple username parameters themselves. The way a server processes this may allow an attacker to access another user’s account.

Remediation: To remediate this issue, the developers need to ensure that the application discards the use of multiple key-value pairs and only accepts one at a time to avoid this attack. Also, developers would need to check if any additional parameter is added to the original request and discard all the additional parameters, accepting the originally supplied parameters only. 

SQL/NoSQL/LDAP/XML Injection

This is one of the most common attacks that comes to one’s mind when we talk about login functionality. Based on the implementation used in the login functionality, an attacker may attempt to bypass it by injecting SQL/NoSQL/LDAP/XML injection payloads and gain access to the victim’s account.

Remediation: To remediate this issue, the developers must ensure that the user-supplied input is validated correctly and security best practices for implementing database queries are followed. You can find a detailed guide at: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

Sensitive Information Disclosure

While performing a login action, it is often observed that some applications store the credentials in response or the javascript files. An attacker may attempt to identify a way to extract the credentials from the response or javascript files. Also, in some cases, the application access may show additional information that may belong to other users or the application server itself and may help further exploitation.

Remediation: To remediate this issue, the developers must ensure that the application doesn’t cache or store sensitive information such as credentials in an insecure place such as server response or javascript files.

Response Manipulation

Often, it is observed that the application returns “success”:false or “success”:true or similar responses when an invalid vs a valid set of credentials is supplied. However, if the application is not performing the server-side validation properly, it is possible to manipulate the response; for example, changing the “success”:false to “success”:true may allow an attacker to gain unauthorised access to the victim’s access account. This attack mainly results in success where the authentication token or cookie generation logic lies at the client-side, which is a bad practice.

Similarly, in many scenarios, the application also uses different response status codes such as 403, 200, etc. It is possible to change the status code from 403 to 200 to bypass the restriction and attempt to gain successful access to the victim’s account.

Remediation: To remediate this issue, the developers need to make sure that the server-side validation is in place and any attempts of client-side manipulation are discarded.

Authentication Bypass

In certain situations, it is impossible to bypass the authentication directly. Still, it is possible to access some specific endpoints or pages by directly navigating to them or in any other way possible. This allows an attacker to bypass the restrictions of required authentication and allows an unauthorised attacker to access those functionalities.

For Example: An unauthenticated attacker performs a directory enumeration and identifies an endpoint /goto/administrator/ which is directly accessible to him without any restrictions.

Remediation: To remediate this issue, developers would be required to ensure that all the authenticated endpoints are adequately placed behind the authentication and a proper authorisation check is implemented.

Bonus: Cross-Site Request Forgery (with a twist)

Usually, most applications are vulnerable to log in based CSRF issues, but there is no security impact in general. Thats’s what you are thinking, right? However, when an application utilizes the Single Sign-On method, the login CSRF comes in handy. This may allow an attacker to connect the victim user’s account to an attacker-controlled entity and can further be used to steal sensitive information or perform malicious actions. 

Example Report: https://hackerone.com/reports/171398

Remediation:  To remediate this issue, the developers must ensure that the state parameter is implemented and appropriately validated.

Apart from the above-mentioned vulnerabilities in the login page, several other vulnerabilities arise when third party integrations are used for authentication such as SAML, OAuth2.0 or other third party services. However, these authentication mechanisms are themselves a vast topic to understand and explore. We will soon be coming up with a separate series on Single Sign On (SSO) and JWT related attack vectors.