Email

 

 

 

 

 

 

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. 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 of the vulnerability.

Source: OWASP

EXAMPLE

For www.vulnerable-bank.com , imagine typical username and password login page with session-id. The attacker can take advantage of server side 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 above scenario, attacker can access victim’s bank account by replaying the session and login into his/her account with his/her own password (just having session of victim and replaying it with own credentials).

Are session management assets like user credentials and session IDs properly protected? You may be vulnerable 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 password, recover 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 and Session Management?

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. 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. 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 implement sticky sessions — verifying that parameters such as User-Agent and IP address, which are 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, 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 is 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.

Founder & Chief Marketing Officer, Indusface

Venky has played multiple roles within Indusface for the past 6 years. Prior to this, as the CTO @indusface, Venky built the product/service offering and technology team from scratch, and grew it from ideation to getting initial customers with a proven/validated business model poised for scale. Before joining Indusface, Venky had 10+ years of experience in security industry and had held various mgmt/leadership roles in Product Development, Professional Services and Sales @Entrust.