A2. Broken Authentication and Session Management

Broken Authentication and Session Management 

Introduction

Second on the list is Broken Authentication and Session Management. It involves all kinds of flaws that are caused by error in implementations of authentication and/or session management.

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. 

Broken Authentication and Session Management

In this attack, an attacker (who can be anonymous external attacker, a user with own account who may attempt to steal data from accounts, or an insider wanting to disguise his or her actions) uses leaks or flaws in the authentication or session management functions to impersonate other users.

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 

• Timeout

• Password Management

• Logout

• Remember me

• Secret question and account update

Example: 1

In the above screenshot, password is guessable, so it makes attacker to login easily. In above example

admin using default credential. Thats why it is easy to guess login credentials.

Example 2

If we click on forward button it is not asking for the credentials, directly it is going to next page. 

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

 In the 2nd example, there is no proper Session Management.

 Example 3: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 (also known as playback attack) is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed.

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. 

Prevention/Recommendation for 'Broken Authentication and Session Management'.

How to Protect Yourself

Careful and proper use of custom or off the shelf authentication and session management mechanisms should significantly reduce the likelihood of a problem in this area. Defining and documenting your site’s policy with respect to 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 wherever 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 can’t 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, POST should always be used instead. 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=OFF 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.

Note:Information showing on this blog is only use for educational purpose.