What is Broken Authentication & How to Prevent it?

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.

Threat Agents	Attack Vectors	Security Weakness		Technical Impacts	Business Impacts
Application Specific	Exploitability AVERAGE	Prevalence WIDESPREAD	Detectability AVERAGE	Impact SEVERE	Application / Business Specific
Consider anonymous external attackers, as well as users with their own accounts, who may attempt to steal accounts from others. Also, consider insiders wanting to disguise their actions.	An attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users.	Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.		Such flaws may allow some or even all accounts to be attacked. Once successful, the attacker can do anything the victim could do. Privileged accounts are frequently targeted.	Consider the business value of the affected data or application functions. Also, consider the business impact of public exposure to the vulnerability.

Source: OWASP

What is Broken Authentication and Session Management Attack?

The Broken Authentication attack is one of the top 10 web vulnerabilities in the OWASP list. The broken authentication and session management consistently occupies the second position, witnessing that it is an area, which still requires significant improvement.

This attack intends that an anonymous user tries to retrieve user account credentials to get into the target website and exploit other flaws on the website or application. Hackers can manually find broken authentication and employ automated tools to manipulate this weakness.

Whenever a user login into his account, a new session id is being assigned and that id is for that particular account only. In case the application is not well protected in terms of authentication, the attackers can use various techniques to hijack that session and gain access to that account. The most common techniques used in broken authentication attack are:

• Unhashed Passwords
• Credential Stuffing
• Misconfigured Session Timeouts
• Bruteforcing

Impact of Broken Authentication and Session Management Vulnerability

Once your account is hijacked by exploiting broken authentication vulnerability, the hacker can do anything that you have permission to do that can lead to serious consequences influencing your company’s sustainability.

Even access to a single admin account is enough for the cybercriminals to comprise an entire web application. Based on the objective of the hacked application, the impact of session hijacking can range from data breaches, leakage of sensitive information, identity theft to administrative access.

EXAMPLE

For www.vulnerable-bank.com, imagine a typical username and password login page with session-id. The attacker can take advantage of server-side has broken authentication vulnerability misconfiguration by exploiting weak session management flaws.

BANK application supports URL rewriting, putting session IDs in the URL:

www.vulnerable-bank.com/username=victim&password=victim123&session=12345

An authenticated user of the site wants to let his friends know about the bank’s new policy. He e-mails the above link without knowing he is also giving away his session ID. When his friends use the link they will use his session and bank details.

Attacking Scenario:

www.vulnerable-bank.com/username=attacker&password=attacker123&session=12345

In the above scenario, an attacker can access victim’s bank account by replaying the session and login into his/her account with his/her own password (just having a session of the victim and replaying it with own credentials).

Are session management assets like user credentials and session IDs properly protected? You may be vulnerable to broken session management attacks if:

1. User authentication credentials aren’t protected when stored using hashing or encryption.
2. Credentials can be guessed or overwritten through weak account management functions (e.g., account creation, change the password, recover the password, weak session IDs).
3. Session IDs are exposed in the URL (e.g., URL rewriting).
4. Session IDs are vulnerable to session fixation attacks.
5. Session IDs don’t timeout, or user sessions or authentication tokens, particularly single sign-on (SSO) tokens, aren’t properly invalidated during logout.
6. Session IDs aren’t rotated after successful login.
7. Passwords, session IDs, and other credentials are sent over unencrypted connections.

How do I Prevent Broken Authentication attacks and Session Management attacks?

The primary recommendation for an organization is to make available to developers:

1. A single set of strong authentication and session management controls. Such controls should strive to:
   1. Meet all the authentication and session management requirements defined in OWASP’s Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management).
   2. Have a simple interface for developers. Consider the ESAPI Authenticator and User APIs as good examples to emulate, use, or build upon.
2. Strong efforts should also be made to avoid XSS flaws which can be used to steal session IDs.

How do WAF’s (Web Application Firewall) help in solving the above problems?

We can use a WAF to validate sessions and prevent broken authentication attack. A WAF does this by setting a collection of variables which store the session id and related information when it is created and sent to the client from the server. Every time the client sends a subsequent request, the WAF intercepts it and checks to see if a valid session id has been sent. Validity will depend on various factors including a time period. For instance, sessions are not allowed to go beyond a certain time period.

There are also session fixation rules that a WAF implements to safeguard against session hijacking. Session fixation happens when a client sends a cookie even when the cookie is not set by the server. This happens when a hacker steals a cookie/session id of another user and uses it to impersonate him.

Finally, WAF’s help implements sticky sessions — verifying that parameters such as User-Agent and IP address, which is meant to be constant/unchanged in a particular session stay unchanged.

The following example illustrates a way of implementing session id checks using modsecurity, an open-source WAF. It is taken from https://secure.jwall.org/blog/2009/01/08/1231374852674.html

This example is about a PHP application. The following rule sets some variables when the session id is set.

# Store session issued by the server

#

# We do this by extracting the cookie’s value from the SERVER and

# create a new session collection named by that value

#

SecRule RESPONSE_HEADERS:/Set-Cookie2?/ “PHPSESSID=([a-f0-9]+)\;\s?” \

“phase:3,capture,msg:’Captured session id from response cookie: %{TX.1}’,chain”

SecActionsetsid:%{TX.1},setvar:session.valid=1,expirevar:session.valid=1000, \

setvar:session.id=%{TX.1},expirevar:session.id

# If the client did send a session cookie we need to make ModSecurity load

# the corresponding session using “setsid”.

#

SecRule REQUEST_COOKIES:PHPSESSID !^$ “phase:1,log, \

msg:’Found cookie in request, initializing session!’, \

setsid:%{REQUEST_COOKIES.PHPSESSID},skip:1”

In the following rule, we enforce session management. That is, if the session is not valid, then we will drop the request.

# If the client did not pass a session cookie, e.g. in the first request,

# we do not check for session validity and skip the validity check-rule

#

SecAction phase:1,log,skip:1, \

msg:’No session transmitted, skipping session validity check!’

# If the session id is invalid then we drop the connection

#

SecRule&SESSION:VALID “@eq 0” phase:1,log,auditlog,deny,status:500, \

msg:’The requested session is not valid!!’

What is the possibility of false positives?

In the above context, while preventing session hijacking and broken authentication attack, a false positive would be if a WAF blocks a valid session id believing that it is not valid. This would be possible only if another user has the valid user’s session id naturally that is — without stealing it. Ordinarily, this would not be possible as the space of session ids is huge and the chances of two users getting the session id in a short time interval are nearly zero if the session id algorithm is implemented properly. Thus, this would, in fact, indicate that the session id implementation algorithm of the said website is weak. Thus, this would not be really a false positive but would indicate a different problem on the part of the website developers.

In the case of a false positive, the session would be declared invalid even if the user has got a legitimate session id. This would happen because the session id setting algorithm developed by the web developers was weak. This would then need to be strengthened.

Recommended Best Practices to Prevent Broken Authentication Attacks

• Implement multifactor authentication to bypass broken session management attacks
• Enforce input validation and limited login tries
• Limit session times
• Enforce high password complexity for user accounts
• Make frequent checks for weak passwords
• Set proper session timeouts

Conclusion

An organization can’t afford to handle the fallout from a broken authentication and session management breach, particularly if it marks in leakage of sensitive information. Following these best practices and using WAF to validate sessions and stop malicious entries, it is possible to prevent broken authentication attacks.

Stay tuned for more relevant and interesting security updates. Follow Indusface on Facebook, Twitter, and LinkedIn