The risk of compromised logins

When you log in to a website, your virtual identity is secured by the web server that generates a unique session ID for your connection. This session ID is used as a key throughout the period of your logged-in session. There is constant data exchange between your system and the web server, which, if unencrypted, can be easily intercepted. This will enable an attacker to hijack your session, forge the session ID or even steal your credentials. Session IDs are used in the format of cookies and URL endpoints. That is why Broken Authentication is always coupled with Session Management exploitation.

Broken authentication is quite often confused with Broken Access Control. The major difference is, while authentication is focused on validating your virtual identity, Access Control includes what privileges you should or should not be having after your login. Broken Access Control is another Top 10 OWASP vulnerability, through which unauthorized website visitors can view or gain control of admin panels, servers, or even critical databases, all through elevated privileges.

When access and identity controls are improperly designed and configured, web applications become more prone to Broken Authentication. The associated risk factors involve:

• Insecure storage of authentication credentials

Usually, login credentials are stored in databases in an encrypted format. If the stored credentials are exposed in plain text, without any security protocols or weak hashing algorithms, attackers are bound to discover them and make use of this vulnerability.

• Credential enumeration

During the authentication process, in case of an error, the application should not indicate which parameter is wrongly entered. Say if you provide the username correctly and mistype the password, the application should mention ‘Invalid Username or Password’ instead of just ‘Invalid Password’. This can give an attacker the required hint to proceed with bypassing the authentication.

• Exposed session IDs in the URL

If the session ID is exposed in the URL itself, then it can easily be rewritten or modified, and your session can be forged. This process is also known as URL rewriting.

• Session IDs vulnerable to session fixation attacks

Unencrypted or poorly managed session IDs are vulnerable, making it convenient for attackers to gain control of your valid session. This is known as a Session Fixation attack. You are then manipulated to use the session as per the purpose of the attacker.

• No timeout or invalidation of session value

If an inactive session does not time out or the session value fails to get invalidated after logout, the session ID can be compromised by lurking attackers.

• Brute Force login protection

You should enable account locking/disabling after a maximum number of invalid login attempts are made. In banking websites, the threshold is set to 3 attempts, while for a few other applications, the norm is 5 attempts. After the said threshold is reached, your account should be disabled for a certain time to put off a brute force attack.

How does a Broken Authentication Exploit Affect Your API Security?

An API (Application Programming Interface) is used to enable intercommunication between multiple applications. While configuring such API Security, it is not feasible to prompt users or systems for their login credentials. Implementing any authentication factor in an API would also require frequent manual intervention. Hence, authentication in APIs is usually done through access tokens that are integrated within each API call, for user authentication. This mechanism is what attackers prefer to target in advanced attacks. Publicly available APIs are the prime targets. 

Some APIs may not have any authentication mechanism, as developers overlook its requirements, especially if the API endpoints are intended for unauthorized direct application communication. This makes it fairly simple for attackers to leverage this risk factor and use such weak API keys to exploit your account.

6 Causes of Broken Authentication in APIs

1. Absent security mechanisms

Authentication specific APIs should regard access security with the highest priority, by stacking additional security layers with hardened authentication tokens to prevent any unauthorized access.

2. Inappropriate use case

Each API is designed to serve a specific purpose and system. Ignoring its intended mechanism and potential attack vectors might do more harm than good. 

There could be a number of technical factors causing broken authentication in APIs, a few of which are:

• Default/common/easy password
• Lack of high account lockout limit
• Exposed/unencrypted authentication info in URL and HTTP GET requests
• Inadequate entropy in authentication tokens
• Using deprecated digital signature algorithms or lack of signatures
• No access token validation (like JWT validation)
• Using broken/poor ciphers
• Insufficient encryption/hashing algorithm key sizes 
• Wrong algorithm use cases
• Lack of multi-factor authentication setup

APIs are primarily used for direct API communication or system communication. The authentication mechanism or session values in these APIs could be exploited to gain unauthorized access to your account. Similar attacks are also executed on cloud-native applications by compromising the workload authentication and API metadata services at the server-end.

Among the methods used by attackers, a few of the most common Broken Authentication attacks include

3. Default credentials

Whenever using any web application, you should always change the default credentials. Suppose you install a DevOps web app, integrate it with other services, and use it without bothering to change its default username and password. As soon as an attacker discovers which version of the application you are using, the first thing tried will be to use the default credentials to access the admin account. Once that is done all your sensitive data is compromised. System Administrators should take extra care in ensuring that the default credentials are always changed.

4. Credential stuffing

Similar to a brute force attack, in credential stuffing, attackers could have already gained access to your database through exploiting a vulnerability. Using that database, several credential combinations are attempted for user authentication, and they can eventually access your accounts. 

5. Missing authentication validation

At times, the credentials provided during the application authentication process are not properly cross-checked with the credential values in the application database. This lack of validation allows an attacker to bypass the authentication process completely.

6. Password Spraying

Common passwords can easily be guessed by an attacker and when combined with a Brute Force attack, the login can be bypassed to access your account. The same goes for default passwords. 

7. Session hijacking

In this technique, an attacker can gain control of your authenticated session by stealing, guessing or forging the session ID and thus impersonating your virtual identity.

How long does it take to find and what can you do about it?

After you log in to an application, the web server generates a unique session ID for your session, in the form of authentication tokens, URL parameters, or cookies. At times, if the proper parameters are not defined for session management during the development process, attackers discover vulnerabilities and hijack your session.

More often than not, a Broken Authentication vulnerability is discovered either during a testing/audit process or after an attack has already occurred. This is why it is always recommended for developers and security engineers to carry out periodic security audits and manual security testing of the web applications. Disciplined security checks are always better than dealing with the aftermath of an attack. Prevention is always better than cure. The first step would be to run tests to check if your web application has any vulnerabilities. If it does, define processes that can be implemented to mitigate those.

Securing web applications

Apart from these, you can also implement additional security checks to harden the web application.

1. Any webpage performing the login process should always have a valid SSL/TLS certificate to secure the connection.
2. If your web application displays other users’ names publicly as part of a forum or ranking, pseudo-names should be encouraged rather than login usernames.
3. In the HTTP GET method all sensitive user data is visible in the browser history, webpage source code, and web server logs. So, all authentication pages should especially be using the POST method with disabled cache tags.

Just like developers, QA testers and security engineers should follow the relevant security checklists to improve the safety of a web application.

• Verify if the HTTP POST method is being used for data exchange.
• Verify the authenticity of the SSL certificate used for web pages.
• Testing user accounts should be deleted. You should also try login attempts with wrong credentials a few times to check the user account locking mechanism. To unlock it, the user should receive a unique email link each time for unblocking or wait for a time period for account auto-unlock.
• You should use penetration testing procedures like URL rewriting or webpage modifications to attempt bypassing the authentication. You can do so by changing logged-in parameters from ‘no’ to ‘yes’, editing cookie values, forging a session ID, brute force attempt, and so on.
• After logging out from a session, if you click back on the webpage, you should not be directed back to a webpage with a logged-in session. 
• Any sensitive data should not be cached in the browser and the response headers should include cache-control headers, like Pragma: no-cache or Cache-Control: no-cache.
• The authentication token mechanism of API endpoints should also be validated.

Conclusion

Broken Authentication has been in the Top 10 list of OWASP for a long time because, despite growing security concerns in the industry, its significance and attack ramifications are often overlooked. Apart from developers, DevOps, and security engineers, end-users should also be instructed, trained, and made aware of authentication negligence associated risks. It is also the responsibility of engineering leaders to ensure proper cybersecurity and DevSecOps approaches are implemented. Automated tools and applications can be used to manage such attack vectors. 

Argon has managed to single out attack interfaces using Broken Authentication, ensuring its customers can evade exploits for business continuity and uninterrupted productivity. Argon is a DevSecOps solution that can protect the entire SDLC from cyberattacks. From open-source code libraries and repositories to cloud resources, all such attack targets are protected by Argon. Try Argon to manage cyber vulnerabilities while ensuring a fast-paced software development process remains unhampered.

The post What is Broken Authentication and How Can You Prevent it appeared first on Argon Security - Holistic Security For Your CI/CD Pipeline.