Blog

Broken authentication remains at number two within the OWASP Top 10, and for very good reason; developers continue to have issues creating code that maintains a secure and consistent authentication schema. Among our clients, it’s often very common that we identify at least one issue in regards to a broken authentication schema and the severity will vary from trivial account takeover or information disclosure that could eventually lead to account takeover.

Broken authentication is not tested using automated scanners and requires thorough manual effort in understanding how the authentication schema confirms a user’s identify, session and authentication. Once determined, manual tests are conducted to determine if any attacks against the authentication are possible.

Broken authentication issues can vary in remediation effort and can include an entire re-work of the authentication schema, or a small one-line change. Modern authentication schemas are capable of and usually include secure deployments out of the box, but custom applications typically use solutions found online that are meant for ease of use and deployment, rather than security.

What is Broken Authentication

Broken authentication occurs when an applications authentication and session management are implemented incorrectly, which subsequently allows attackers to gain access to a user’s session either temporarily or permanently. These incorrect implementations could lead to the following attacks:

• Credential stuffing – where accounts from previous breaches are attempted against the application in hopes of obtaining a successful authentication.

• Bruteforcing – similar to credential stuffing except the attacker would try to guess user accounts and passwords.

• Unauthorized access due to the lack of multi-factor authentication.

• Session ID exposed in URLs – a session ID is used to associate and authorize you to conduct specific actions according to your account privileges. The session ID ties you, the individual, to the web application. By placing the session ID in the URL (e.g., https://website.com/accounts.php?sessionid=mysessionid), it gets sent across the network and can get logged by network appliances (such as proxies and event loggers). They can also be seen by attackers sitting on your network watching traffic. If the session ID is seen by an attacker and used, your account to that application will be fully compromised.

• Session ID does not rotate – if an attacker obtains your session ID through Cross-Site Scripting or through its exposure in the URL and the ID never changes when you log in or when you log out of the application, then it can be used to access your account indefinitely.

• Session ID is not invalidated upon rotation – when the session ID is rotated during a log out or log in, the ID being rotated out must be disabled on the server-side to prevent reuse.

• Session ID is easy to guess – if the randomness (or entropy) of the token being used isn’t strong, then an attacker can assume another user’s session by simply replacing their token with yours.

• Password requirements are insufficient:

  • Weak passwords allow for attackers to succeed in brute-forcing or credential stuffing. Some organizations have minimum and maximum lengths which also assist attackers in tuning their attacking tools to minimize the length of time needed to guess a password. If you’re curious about if password you use has been breached, check out 

  • Attackers use these breached passwords in their attacks; if a password you use has been breached, it should be changed immediately.

Weak password recovery due to knowledge-based answers. The name of your dog, or mother’s maiden name are easy to uncover and many organizations have gone away entirely from these recovery questions.

Impact and Risk

Many organizations feel that the authenticated portion (e.g., when a user logs in) is not as important to protect as the public portion given the public piece is constantly bombarded by attackers. However, if one account is compromised due to broken authentication and leads to an attacker gaining unauthorized access, that authenticated portion is now at risk and could lead to full server compromise. Also, depending on the purpose of the application and how the data at rest is being secured, you may run into legal issues with PIPEDA or GDPR.

Technical Trenches

Given three of the top issues around broken authentication are due to the improper handling of session IDs, the sections beyond this will solely focus on those areas.

A user’s session can be managed using two different implementations. One involves a custom header using JWT (Authorization: Bearer) and one involves a simple cookie. For this article, we’ll only discuss the most commonly used, which is a cookie. However, a second part will be posted that discusses attacks against the JWT tokens.

Each and every site has a cookie. If it’s not used for session handling, it’s used for tracking analytics. It consists of a name=value pair which is used on each request it is needed on. Below is an example of two cookies, one named sessionid and the other is analytics.

• Cookie: sessionid=eew32ff2d; analytics=trackingpacketlabs;

Knowing what a session token looks like in a request will assist in understanding where the underlying issues lead to broken authentication.

Attack Scenarios

Session ID exposed in URLs

If a user logs into your web application in an environment where an attacker is suitably positioned where the traffic is being logged and the session ID is in the URL, the attacker can assume that user’s session by replacing their session with the victims. In the example below, a user logs in and has their session id passed in the URL on each and every click on the web application.

https://website.com/accounts.php?sessionid=eew32ff2d

If the sessionid of eew32ff2d never expires and is seen by an attacker, the attacker can easily assume that user’s identify by modifying their cookie to that of the victim. Below is an extension called Cookie Editor that you can install on Firefox to do just that.

Figure 1: Setting a cookie

With the session set in Cookie Editor, the attacker only needs to refresh their browser to take over the victim’s session.

Session ID is easy to guess

The application sets the following cookie when a user authenticates.

• [TODO: MUST REPLACE - meta tag used in li]Set-Cookie: sessionid=146

The sessionid is within a cookie as it should be, but only has a length of 3 digits. The next user that logs in to the application receives a sessionid of 147. The session is only being incremented by 1 for each new session. An attacker will notice this and can use the Cookie Editor tool once again to replace their sessionid with the victims.

Session ID does not rotate

The user leaves the application for the day and returns a month later and receives the following cookie.

• Set-Cookie: sessionid=146

The sessionid did not rotate to another number allowing an attacker to easily assume the user’s session. To an attacker this tells them each user has a unique sessionid. As the attacker rotates through each sessionid, they may find the admin account using sessionid 001 or 100.

Session ID is not invalidated upon rotation

The user’s previous sessionid was 150, and upon return is now 151. The sessionid has rotated, but the previous sessionid of 150 can still be used to assume the user’s session. The user now has two sessionid that authenticate them to the application.

This issue is quite common amongst web applications today where the previous session is not invalidated for a specific amount of time, varying from minutes to days.

Remediation

To protect your application from broken authentication, the following security controls are recommended.

• Credential stuffing – enable multi-factor authentication and enforce for all user’s if possible.

• Bruteforcing – in addition to multi-factor, implement a CAPTCHA or rate limiting control to prevent guessing attacks.

• Session ID exposed in URLs – do not have session management tokens in the URL. Analytics or advertisement tokens are ok to have in URLs, as long as they are not the same as the token used to maintain sessions.

• Session ID does not rotate – issue a new session token each time a user logs in.

• Session ID is not invalidated upon rotation – remove the session token immediately upon logging out, or when the browser is closed.

• Session ID is easy to guess – ensure true randomness and entropy when issuing session tokens. For example, the token used above (eew32ff2d) is a poor example as seen by the character analysis conducted below when compared to a longer more random one (188c01d8502b51119e0c79650aea0a269a7881e1)

Entropy Analysis: eew32ff2d

Entropy Analysis: 188c01d8502b51119e0c79650aea0a269a7881e1

• Password requirements are insufficient – a password policy is always a controversial topic for each organization, but our recommendations are the following:[TODO: MUST REPLACE - ul tag used in li][TODO: MUST REPLACE - ul tag used in li][TODO: MUST REPLACE - ul tag used in li][TODO: MUST REPLACE - ul tag used in li]

How we can help

At Packetlabs we use a thorough methodology that assesses your organization against any broken authentication issues. Our methodology, when compared to other vendors has always been more robust which provides our clients with more thorough testing. Contact us to find out how we can assist your organization.