Introduction

Proper authentication and session management is critical to web application security.
Flaws in this area most frequently involve the failure to protect credentials and session tokens through their lifecycle. These flaws can lead to the hijacking of user or administrative accounts, undermine authorization and accountability controls, and cause privacy violations.


What isBroken Authentication and Session Management?

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.
Account credentials and sessions tokens are often not properly protected

  • A third party can access to anyone’s account
  • Attacker compromise password, keys or authentication token


Risks

  • Undermined authorization and accountability controls
  • Cause privacy violation
  • Identity Theft


Method of attack: Use weaknesses in authentication mechanism

  • Logout
  • Password Management
  • Timeout
  • Remember me
  • Secret question and account update

We will see some of the examples for broken authentication and session management.

Example1: 1)In the below screenshot, password is guessable, so it makes attacker to login easily.

2)The attacker logged in successfully, he is getting the admin privileges.

Example2: 1)If we click on forward button it is not asking for the credentials, directly it is goingto next page.

2) It came directly to home page of admin by pressing forward button.

In the 2nd example, there is noProper Session Management.

Example3: 1)It is displaying Session id which is vulnerable to many attacks.

Example 4: 1) Admin credentials are not properly encrypted, which makes the attacker to decrypt easily.


Impact: Severe

  • Brute Force
  • Replay Attack
  • Session Fixation Attack
  • Session Hijacking
  • Session timeout


Brute force:

A brute force attack is a trial-and-error method used to obtain information such as a user password or personal identification number (PIN).


Replay attack:

A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator or by an adversary who intercepts the data and retransmits it, possibly as part of a masquerade attack by IPpacket substitution (such as stream cipher attack).


Session Fixation Attack:

Session fixation attacks attempt to exploit the vulnerability of a system which allows one person to set another person’s session identifier (SID). Most session fixation attacks are web based, and most rely on session identifiers being accepted from URLs (query string) or POST data.


Session Hijacking:

 

Session hijacking is the exploitation of a valid computer session, It is also to gain unauthorized access to information or services in a computer system. It’s nothing but hijacking a session.


Session Timeout:

 

The Timeout property specifies the time-out period assigned to the Session object for the application, in minutes. If the user does not refresh or request a page within the time-out period, the session ends.

Environments Affected from ‘Broken Authentication and Session Management’

All known web servers, application servers, and web application environments are susceptible to broken authentication and session management issues.

Detection to find ‘Broken Authentication and Session Management’

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.


Prevention/Recommendation for ‘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.

Careful and proper use of the authentication and session management mechanisms should significantly reduce the problem in this area. Defining and documenting your site’s policy for securely managing users credentials is a good first step. Ensuring that your implementation consistently enforces this policy is key to having a secure and robust authentication and session management mechanism. Some critical areas include:

  • Password Strength – passwords should have restrictions that require a minimum size and complexity for the password. Complexity typically requires the use of minimum combinations of alphabetic, numeric, and/or non-alphanumeric characters in a user’s password (e.g., at least one of each). Users should be required to change their password periodically. Users should be prevented from reusing previous passwords.
  • Password Use – Users should be restricted to a defined number of login attempts per unit of time and repeated failed login attempts should be logged. Passwords provided during failed login attempts should not be recorded, as this may expose a user’s password to whoever can gain access to this log. The system should not indicate whether it was the username or password that was wrong if a login attempt fails. Users should be informed of the date/time of their last successful login and the number of failed access attempts to their account since that time.
  • Password Change Controls: A single password change mechanism should be used where ever users are allowed to change a password, regardless of the situation. Users should always be required to provide both their old and new password when changing their password (like all account information). If forgotten passwords are emailed to users, the system should require the user to reauthenticate whenever the user is changing their e-mail address, otherwise an attacker who temporarily has access to their session (e.g., by walking up to their computer while they are logged in) can simply change their e-mail address and request a ‘forgotten’ password be mailed to them.
  • Password Storage – All passwords must be stored in either hashed or encrypted form to protect them from exposure, regardless of where they are stored. Hashed form is preferred since it is not reversible. Encryption should be used when the plaintext password is needed, such as when using the password to login to another system. Passwords should never be hardcoded in any source code. Decryption keys must be strongly protected to ensure that they cannot be grabbed and used to decrypt the password file.
  • Protecting Credentials in Transit – The only effective technique is to encrypt the entire login transaction using something like SSL. Simple transformations of the password such as hashing it on the client prior to transmission provide little protection as the hashed version can simply be intercepted and retransmitted even though the actual plaintext password might not be known.
  • Session ID Protection – Ideally, a user’s entire session should be protected via SSL. If this is done, then the session ID (e.g., session cookie) cannot be grabbed off the network, which is the biggest risk of exposure for a session ID. If SSL is not viable for performance or other reasons then session IDs themselves must be protected in other ways. First, they should never be included in the URL as they can be cached by the browser, sent in the referrer header, or accidentally forwarded to a ‘friend’. Session IDs should be long, complicated, random numbers that cannot be easily guessed. Session IDs can also be changed frequently during a session to reduce how long a session ID is valid. Session IDs must be changed when switching to SSL, authenticating, or other major transitions. Session IDs chosen by a user should never be accepted.
  • Account Lists – Systems should be designed to avoid allowing users to gain access to a list of the account names on the site. If lists of users must be presented, it is recommended that some form of pseudonym (screen name) that maps to the actual account be listed instead. That way, the pseudonym cannot be used during a login attempt or some other hack that goes after a user’s account.
  • Browser Caching – Authentication and session data should never be submitted as part of a GET. Instead POST should be used. Authentication pages should be marked with all varieties of the no cache tag to prevent someone from using the back button in a user’s browser to backup to the login page and resubmit the previously typed in credentials. Many browsers now support the autocomplete=false flag to prevent storing of credentials in autocomplete caches.
  • Trust Relationships – Your site architecture should avoid implicit trust between components whenever possible. Each component should authenticate itself to any other component it is interacting with unless there is a strong reason not to (such as performance or lack of a usable mechanism). If trust relationships are required, strong procedural and architecture mechanisms should be in place to ensure that such trust cannot be abused as the site architecture evolves over time.
  • Token should be independent of the browser.
  • Session tokens should be expired on the server, and destroyed when a browser is closed.
  • Avoid writing your own routines to authenticate, end sessions, tokens, etc. Use a well-tested tool.
  • Test for when a “back browser” action is taken or use of an expiring timestamp.
  • Do not enumerate account lists.
  • If the web server is within a shared environment (multiple services on the same server), do not allow sharing of directories. Verify that permissions are set up correctly.
  • Remove all demo code, and guard against path traversal attacks.
  • Verify that the server configuration is proper for your environment. Do not accept the server defaults without analysis. Defaults are usually bad since they are often too open.


User account management:

  • Use best practices for user account management, i.e. annual account review using active personnel list or files. If a user has not logged in for a specified period of time, disable/deactivate.
  • Do not use generic user accounts.
  • You MUST not use generic administrator accounts.
  • Use different administrator accounts and passwords for each server.


Server security management:

  • Be careful about privileges and administrative interfaces. Do not use elevated privileges.
  • Limit access to administrators and only use “secure shell” or console privileges.
  • Authenticate for all levels.
  • Use audit trails and logging. Preferably log to a log server.