This is the third article in the OWASP Top 10 Series
Overview
Broken Authentication and Session Management is the number 2 risk of the OWASP Top 10 (at time of this writing). As in the case of Injection, we are going to scope content and samples of this article to web applications developed under .NET technologies (ASP.NET MVC, ASP.NET WF, ASP.NET Core, WebAPI, WCF, EF, etc…). This risk includes all aspects of managing user authentication and handling active sessions. First of all we need to distinguish between Broken Authentication and Session Management, which are concepts that are closely related but not equals.
Authentication is a key component in web applications; even the best implementation can be bypassed due to flawed credential functions like remember my password, password change, etc…..On the other hand, we found a human factor: humans are terrible when creating passwords, and to make things worse, they tend to reuse them everywhere. At present, best authentication systems tends to implement anti-automation features, strong policies about password creation (which in turn has a negative impact into usability), and of course MFA (Multi-Factor Authentication). It´s also true that web developers usually underestimate the need of creating strong authentication systems and session management policies that properly protect user credentials.
Session Management risk is referred to the possibility of session hijacking; it´s another interesting topic for reviewing that worth to be aware of, let´s explore these risks in detail…
Broken Authentication and Session Management Explained
From the Session Management perspective, attacker can be anonymous external one as well as existing company users (insiders) with their own accounts trying to access info from other user’s accounts; On the other hand and from the Broken Authentication view, attackers can have access to millions of password combinations and specific tools for breaking authentication systems. Attackers will use flaws in the authentication o session management functions for user impersonation.
The prevalence and detectability are also notable which may be mainly due to legacy systems and developers that tend to build their own authentication systems instead of use the ones provided by .NET framework (which is not a silver bullet in turn) or even better, implement a commercial one (which can be prohibitive in terms of pricing); Once attackers have discovered a authentication breach they can use automated tools for exploit it. Technical impact is severe, and business one depends on the system and the sensitive level of info contained in it. From the OWASP document we see:
Session Management Risk
Moderns web applications needs to persist info between requests. As we know http is a stateless protocol so it is necessary to create the illusion of session concept for users. Reality is that each http connection is independent from the previous one, and in order to identify specific users across request, a manual mechanism has to be created. At this point it worth noting that in order to introduce the concept of session we need to implement session management capabilities that allows to link authentication with authorization
Sometimes “this illusion” consists into a cookie in web browser and some memory space at server machine. Technical sessions allow establishing variables like access rights, localization settings, etc…, that will apply to every user request in meantime the session is active. .NET applications create also session for keeping track of anonymous user’s activities.
From net perspective, Session is also a flexible container to store whatever needed info between requests. Once Session is established a SessionID is assigned to this session, in ASP.NET, this id is named: ASP.NET_SessionId, and is considered as strong token for identifying user, so, is a matter of fact, that prediction, capture, brute force, or fixation of the Session-ID can lead to session hijacking, in which an attacker is able to fully impersonate a user in the web application.
Note: According to Microsoft “the ASP .NET session identifier is a randomly generated number encoded into a 24-character string consisting of lowercase characters from a to z and numbers from 0 to 5”
Sources of Session Management Vulnerability
Let´s talk now about the main source of SM vulnerability which is session ID persistence. Once a session (for ASP.NET application) is created we can choose from four mechanisms for session ID persistence, more specifically:
- UseUri: Persist SessionID token into url without regarding of device
- UseCookies: Persist SessionID token into cookies without regarding of device
- UseDeviceProfile: ASP.NET detects if cookies are available in web browser, if this is the case then persist SessionID at cookies otherwise url will be used
- Autodected: ASP.NET detects if cookies are enabled in web browser, if this is the case then persist SessionID at cookies otherwise url will be used
As we can see, the first option is risky and it´s considered a vulnerable practice: as a general rule (not only for SessionID) you don´t must to store any sensitive information at url, and SessionID can be considered as “credential Token”, anyone who can see your url can potentially impersonate you by using this token.
The danger becomes more evident if you consider common user practices like
- URLs are usually shared by social media and email (facebook, twitter, etc…)
- URLs are accessible from browser history
- URLs are frequently logged by proxies, etc…
ASP.NET SessionID persistence mode defaults to cookies option
Sample of Session Management Vulnerability
We will see a very basic sample about this risk by configuring UseUri option into an ASP.NET MVC application with Forms Authentication:
This application is configured for use UseUri SessionID persistency option:
As soon as application is loaded, we observe the SessionID token at url (even before to login into web application), that corresponds to the anonymous user that loads the web application
Solution in this case is pretty simple (if web browser allows it), we only delete the UseUri option to restore ASP.NET default working mode, then SessionID will not appear anymore at url, more specifically
And the SessionID will be found at the cookie:
This way, nobody can hijack the session… unless they have access to request headers, right? (We will see at Insecure Transport Layer risk that we need to protect sensitive data and don´t transmit over insecure connection; in particular cookies can be sniffed and sessions can be hijacked)
Session Management: Reducing time surface
There is another quite relevant topic related to session when we talk about session management and broken authentication that is the timeouts.
Session timeout is about when the session will be automatically expired, which all sense has because the likelihood for session to be stolen is directly proportional to the size of time window used before session expiration. So, a proper balance has to be found between security and usability.
Forms timeout sets the size of time in minutes that authentication cookie will be valid, after that time the cookie will be invalid and the user will be redirected to login page when trying to use the application.
In ASP.NET the default session timeout is about 20 minutes and forms timeout is set about 30 minutes. The convenience of these (or another) values has to been evaluated in each case
Default forms authentication timeout for ASP.NET is sliding expiration which means that this time-window will be reset with every request. So, recommended action here is clear: change the Forms timeout mode to fixed by disabling sliding expiration whenever possible, this way you will reduce the time surface available for attacking your web application.
Broken Authentication Risk
So far, we have reviewed Session Management risk; now it´s time to talk about Broken Authentication. Authentication is mainly about providing credentials, logging users and gives them authorization for performing tasks into given system. When considering this risk one may wonder about where the problem really is: Is about humans? Or is about systems? Answer is clear: at time of this writing is more a human problem that a technology one. As we commented earlier humans are terrible when creating passwords, it´s really hard to change this mentality because humans tend to be lazy and commonly don´t have password management mindset. System can contribute to mitigate this by providing MFA (2FA) : Multifactor Authentication, Captcha, Password Policies, etc… but proper balance has also to be achieve between security and usability, in this line Invisible reCAPTCHA, is a good initiative in this direction.
You can check if you password has been pwned at https://haveibeenpwned.com/Passwords
Defences & Recommendations
From an operational perpective, Authentication can be a complex topic, so first recommendation is for developers: please, avoid creating your own authentication systems. Using the built-in .NET framework capabilities, but be careful here because .NET Membership Provider store passwords as salted SHA1 hash, which is insufficient by current standards and can be easily cracked, son consider using ASP.NET Identity which is considered sufficient stronger. So at this point we can also consider some commercial alternatives which can be expensive.
So from the technology view these are some of the recommendations:
- Use a robust commercial authentication framework or ASP.NET Identity for implementing Authentication
- Implement MFA o 2FA whenever possible into your systems
- Implement robust password minimum policy
- All Credentials should be stored in a cryptographically way (by default at Asp.NET Identity)
- Protect Session Ids in Cookies (don´t transmit sensitive data over insecure channel)
- Deactivate sliding forms authentication expiration whenever possible
Best Solution
Broken authentication and Session Management is a wide broad topic that is also closely related with other OWASP Top 10 risks that we will review in later articles. Implementing previous recommendations is the basis for defence in depth, but if you want to implement a robust solution for your systems you can use a RASP solution with coverage for Broken Auth. and Session Management. RASP stands for Runtime Application Self Protection which allows applications to protect themselves. I strongly recommend Hdiv RASP solution for integrating first level of protection.