Post Comprise Abuse (Browser Defenses Part 6)

A Session’s Lifetime

A session is usually created when a user successfully authenticates with the application (but not sooner than that to avoid session fixation attacks). If users were diligent about logging out as soon as the we're done using the application, our discussion could end here. But they’re not. Because of this, site designers need to add additional controls. The first one is an idle session timeout, meaning that if a user doesn't do anything in the application for some period of time the application automatically invalidates their token.

An idle timeout would be good enough if attackers were dumb, but we're not that lucky. Clever attackers who have stolen a session token can create a small script that sends a request to the website just frequently enough to extend the token’s lifetime. Doing this can keep the session alive indefinitely or at least until the list of active sessions is reset. If the server keeps the session storage in memory this will happen when the application is restarted. If the server uses a database to store session data, it could be much, much longer.

To prevent a script from keeping the session alive forever, sites must also have an absolute session timeout after which a session will be invalidated no matter when the last request was received. For usability reasons, the absolute timeout is usually much longer than the idle timeout.

The “Correct” Session Lifetime

The obvious next question is “how long should your idle and absolute session timeouts be?”. And unfortunately the answer is, “it depends.” The “correct” session length is a compromise between the inconvenience of forcing the user to login again, and the risk of having an attacker use a session token they have obtained.

There are two spectrums that can be useful to consider when answering this question for ourselves, “how sensitive is the application” and “how long does an average user spend using it?”. The sensitivity of an application must include both the value of the data that an attacker would gain access to and the actions they could take within the application, even if users don't normally take the most impactful actions.

But how do all of these play out? For the consumer side of a banking application, a 10 or 15 minute idle timeout and an absolute timeout of an hour seem appropriate. On the other hand even though a bank teller would have access to more information, the realities of their job means that a longer idle timeout, perhaps as long as an hour might be ok, especially since physical access to the workstation is tightly controlled. The absolute timeout can match an eight hour shift, perhaps extending to 10 hours to account for overtime or perhaps only five hours assuming (and encouraging) that workers would log out for lunch at some point during their shift.

For a run of the mill web application, an idle timeout of an hour rarely presents a burden to users while still forcing an attacker to be prompt if they are going to abuse a stolen token. For the absolute time out, 12 or 16 hours would mean that users would have to log in once a day and few people are likely to object to that especially if they are taken back to their previous position in the site after logging in. If your application fits the usage pattern of “log in, perform a task, move on”, much shorter timeouts may be appropriate even if the sensitivity of your application is low. Any compromise of a session token is going to carry some negative impacts even if it is only the trust of your user base.

Offering a setting that allows the user to remain logged in for a longer period of time (a.k.a remember me) allows the user to trade some level of security for convenience and is usually well received, though we have to ask the question “does the user understand that trade-off?”

Finally we should consider the common practice of some applications, particularly email and messaging applications to allow users to remain logged in for weeks or even a month. If we're optimistic, we could convince ourselves that these services have strong methods of detecting session abuse to compensate for the long sessions, but having abused some of these session tokens myself, I am skeptical. This is of more concern when these email providers also act as single sign on (SSO) identity providers. There are many applications that have set conservative timeouts, but also integrated SSO relationships with the effect that as soon as my session in the application expires, I am redirected to the SSO provider which recognizes that my SSO session is still active (and will be for weeks), so it immediately authorizes me and redirects me back to the application which issues a fresh session token without me taking any action at all. This isn't all bad because the application session token that an attacker had hypothetically compromised is now invalid, but the security of the application is now bound to the security of the SSO provider’s session token. From a practical perspective this may be OK. An attacker that has access to a victim’s email probably has higher value targets to attack than a random web application, but there is risk here that needs to be considered when integrating SSO providers that maintain long sessions.

Browser Profiling

A lot of negative things can be done when companies use subtle features of a browser or user’s behavior to identify them across sites, but using some of those techniques to differentiate between a request coming from the authorized user and a request coming from an attacker utilizing a stolen token can be very valuable. Simple things like tracking the source IP address are quick to implement, but may lead to user frustration if their ISP assigns them a new address in the middle of a session. Characteristics such as the user-agent string are just as easy to implement, and although these can be forged by an attacker, there are usually a couple of failed attempts that could be flagged as security events that would occur before the attacker figures this out. Deeper attributes such as screen size, fonts installed, and even GPU capabilities could also be tracked to detect when one session token is used from a different browser which would be a solid indicator of compromise.

A last line of defense

There are a couple of additional features that can help reduce the length of time an attacker could make use of a stolen token. First, if a user is only allowed to have one active session at a time, then if an attacker is still using a stolen token when the user tries to log in again, the attacker’s session will be terminated. Realistically speaking though, allowing a single session is not practical for many applications where users may legitimately be connected from multiple devices. In these cases, at least providing the user with a list of active sessions, along with some details about the device using the session (source IP (geolocated), operating system, start time, and last activity), allows the user to recognize an unauthorized session and report their account as compromised. Both of these defenses are probably more useful in helping a user notice when their password has been compromised and a fresh session is being created, but they have a role to play in stolen session tokens as well.

A new player emerges

A new technology is starting to be included in browsers that is designed to completely block post compromise use, at least from anywhere outside the user’s own system. Device Bound Session Credentials use public-private key pairs and a devices trusted platform module (TPM) to ensure that only the computer that first receives (and in this case helps create) the session token can ever use it. Since there are a lot of issues to understand and explore here, that will be covered in its own article.

Errata

See a mistake? Disagree with something? This email address is being protected from spambots. You need JavaScript enabled to view it..