Secure Coding Practices – Broken Authentication & Session Management

Overview

Many application security attacks target user authentication and session management. A successful attack can lead to unauthorized access to user accounts. OWASP has placed authentication and session management related vulnerabilities in Top 10 list.

What is the Vulnerability

The root causes of broken authentication & session management vulnerabilities are –

  1. Improper authentication
  2. Weak password control
  3. Insecure session management

Improper Authentication – Authentication is a process of verifying a legitimate user. There are 3 types of information can be used to authenticate a user successfully –

  1. Something a user know (password)
  2. Something a user has (smart card, smart token)
  3. Something a user is (biometric details)

These details can be used individually or in combination. For example – combination of 1 and 2 or 1 and 3 is called multi-factor authentication.

Any weakness in implementation and usage of the above-mentioned authentication information can make authentication insecure. For example – application transmits login credentials to server in clear text format which can be sniffed by attacker.

Weak Password Control – Password is highly sensitive information of a user. Password compromise is considered as major data breach. Hence it is absolutely necessary to protect password from unauthorized disclosure.

Insecure Session Management – Session is created as a result of successful authentication. Session is used to verify authentication status of a user post-authentication; therefore, session identifiers are as sensitive as a password. Any weakness in session management can cause similar damage what a password compromise can.

Secure Coding Best Practices

Broken authentication and session management vulnerabilities can be prevented by applying following secure coding practices –

  1. Usernames/user ids should be case insensitive. ‘AFFLUX’ and ‘afflux’ should be same.
  2. Authentication functionality should be implemented in such a way that it cannot be abused to harvest usernames by attackers. For example – a login sequence where user enters the username in first page and password in next page after successful verification of username, can be used by an attacker to determine valid usernames.
  3. Login credentials should not be stored in application source code or perform client-side authentication.
  4. Implement CAPTCHA or account lockout on login page of the application. CAPTCHA should be unique for every successful or unsuccessful login attempts. Smart token based authentication can also be implemented to enable multi-factor authentication. Alternatively, user account can be restricted to login to the application after certain consecutive unsuccessful login attempts.
  5. Never store login credentials in cookie parameters. Any information stored in cookie will go to end user.
  6. In case of a failed authentication attempt, the application should respond with a generic error message regardless of whether the user id or password was incorrect. The error message should not give any indication to the status of the account.
  7. The application should re-authenticate the user before accessing any sensitive feature of the application.
  8. All authentication attempts, successful or failed, should be logged and reviewed periodically.
  9. Password should be transmitted over a secure channel. TLS forms an encrypted transmission channel and prevents password sniffing.
  10. The application should implement a strong password policy. For example – password should be 10 characters long and a combination of 1 uppercase letter, 1 lowercase letter, 1 number and 1 special character out of @#$%&.
  11. Password should be stored in hashed format in the database. A strong hashing algorithm such as – SHA512 should be used.
  12. The application should make use of built-in session management features such as – session id generation, of application development framework.
  13. In order to avoid active sniffing or passive disclosure from network traffic, session id should be transmitted over HTTPS.
  14. Session id should be stored in cookie. Storing session id in application source code is not a secure implementation since it can be vulnerable to XSS attack.
  15. ‘secure’, ‘HttpOnly’, ‘path’ and ‘domain’ cookie attributes should be enabled which enhances session security.
  16. Session fixation is an attack which exploits session id generation feature. An attacker accesses the application and generates a session id. Later attacker sends that session id to a legitimate application user who when logs in to the application, the same session id continues to be used but now it is tagged to an authenticated account. Attacker who has the session id now sends request to an internal application page with fixed session id and gains access to legitimate user account. To mitigate session fixation, the application should regenerate the session after successful login and invalidate the old one.
  17. Session id should be invalidated at server upon logout. If a user is logged in to the application and session is invalidated, then user should be directed to login/ home page of the application.
  18. The application should implement session timeout after certain period of user inactivity. A timed-out session id should be invalidated.

We offer training on secure coding practices customized as per developers’ skillsets and development methodologies. Please visit Application Security section in Service Offerings or Contact Us to hear more from us.