Menu

Introduction to PCI DSS (Payment Card Industry Data Security Standard)   Introduction to PCI DSS (Payment Card Industry Data Security Standard)   

Data Protection Act 1998   Data Protection Act 1998   

Secure HTML Practices   Secure HTML Practices   

SQL Injection Attack - Introduction and Mitigation Steps   SQL Injection Attack - Introduction and Mitigation Steps   

Cross Site Scripting (XSS) – Introduction and Mitigation Steps   Cross Site Scripting (XSS) – Introduction and Mitigation Steps   

Audit and Testing Tools for Web Application Security   Audit and Testing Tools for Web Application Security   

Threat Modeling for Web Application Security - Practice Guide   Threat Modeling for Web Application Security - Practice Guide   

Broken Authentication and Session Management – Introduction and Mitigation Steps

Published on: 8/17/2014
Topic: Web Application Security
Broken Authentication and Session Management – OWASP definition

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


Table of Contents

Common Reasons for Broken Authentication & Authorization

In most of web applications the user is authenticated with single stage or multi stage Login process and authentic user’s identity is maintained using sessions on server side or client side (mostly using a Session ID stored in client side cookie). The basic authentication & authorization features are always there but any weakness in User/Session management related features may lead to vulnerabilities as below:

- The user credentials like user name and/or password are stored on client side (cookie). Sometime because of usability features provided by browser like Autofill or Remember Me; These features are mostly depreciated by browsers on HTTPS/secure protocol.

- Not protecting user credentials on server side, especially if passwords are stored in database without using salted hash; Other common mistakes are using admin/root accounts for application authentication or storing user credentials in unprotected configuration files or hardcoding in source files.

- Incorrect algorithm used for generating Session IDs; Reuse of session IDs

- Weak username/passwords and lack of strong password policy implementation

- Username/passwords are not transferred on secure transport layer (Basic Authentication) hence interception is possible at multiple stages. If user name, passwords and other critical data is transfered on non secure channels that may be captured in unsecured log files by web server logging or due to monitoring tools in place.

- Session IDs passed in URLs that may be intercepted; Sometimes this design is used to support cookie less sessions;

- Maintaining very high session timeout value; This is especially critical if website is used from a shared computer like in internet cafe. An attacker may check the browsing history and may still get access to website if the earlier users did not logout.

- Incorrect design or assumptions – e.g. A website may protect admin access by not showing menu links for admin functions to normal user but if a normal user directly enter a admin interface URL, then the user role is not reverified assuming that only admin users has visibility of such interface.

- Unprotected Web Services that are meant to be consumed by only trusted consumers hence no authentication or authorization feature is implemented; Think about a webservice available on public IP that is provided for 3rd party integration for critical features like password reset, user/account creation etc. An attacker may easily understand the Web service structure and use this for creating new accounts;

- Critical features available in client side objects; e.g. A Java applet that is used to encrypt/decrypt user name/password or any other critical data that is stored on client side. You may have encrypted the account id/password stored in client side cookie but the attacker may simply decrypts it using public functions available in the Java Applet. Similarly example is using a client side cookie for controlling session timeout that an attacker may easily change to resume session before making next request to webserver.

- Usability issues especially hard to find Logout option. Users are tend to close browser if fail to notice Logout button upfront hance leaving behind valid sessions.

- Weakness in password recovery function. This particular feature may also lead to DOS attack, if the website may lock a user account or reset his password just because a valid user/account ID is provided on Forget/reset password interface. This is highly vulnerable if a fixed length/numeric value or email ID is used as user name that are easy to anticipate.

- Middle man attack, Cross Site Scripting (XSS), Cross-Site Request Forgery (CSRF) and phishing attacks that may be used by attacker to steal the session ID or client side data

- Other vulnerabilities like SQL Injection that may allow attacker to retrieve information from database, especially from Login screen that is the entry point for your application

The attacker can detect flaws in authentication process like guessing email based user names for pre-existing users,discovering user name passwords using brute force attacks. Even highly protected implementations have been victim of inappropriate design. Many times the flaws are unintentionally created in effort to improve the user experience. For example one of banking website I witnessed, stores the user id on client side (persistent cookie) that is mapped with the credit card number. The cookie can be stolen or manipulated. In another financial website I found a multi stage login authentication process implemented, where a correct customer ID is asked to enter and then only user is redirected to password screen. Hence the job is 50% less time consuming for attacker to first guess only the username. On top of that the customer id was a fixed length numeric value that makes it easier to detect. Thus the attacker can use your own defense to find attack surface.


Continue Reading: Guidelines to Prevent Broken Authentication and Session Management